Fix ``

how.html

@@ -45,7 +45,7 @@ caller, which usually shuts down the system.
 
 <h4>The system event source.</h4>
 
-Liboop comes with a single ``reference'' implementation of an event source.
+Liboop comes with a single "reference" implementation of an event source.
 This event source uses select() to dispatch events.  Most programs built 
 around liboop will probably use the standard system event source; legacy 
 programs with their own event loop, or programs with specialized needs may 

index.html

@@ -8,8 +8,8 @@
 <p>
 Liboop is a low-level event loop management library for POSIX-based operating 
 systems.  It supports the development of modular, multiplexed applications 
-which may respond to events from several sources.  It replaces the ``select() 
-loop'' and allows the registration of event handlers for file and network I/O, 
+which may respond to events from several sources.  It replaces the "select() 
+loop" and allows the registration of event handlers for file and network I/O, 
 timers and signals.  Since processes use these mechanisms for almost all 
 external communication, liboop can be used as the basis for almost any 
 application.

oop_sys_run.html

@@ -29,7 +29,7 @@ events.<p>
 
 When one of the callbacks returns some other value, oop_sys_run returns this
 value.  You can use this technique to allow callbacks to return data to the 
-``owner'' of the event loop (the caller of oop_sys_run).  You may then decide 
+"owner" of the event loop (the caller of oop_sys_run).  You may then decide 
 whether to restart the event loop (by calling oop_sys_run again) or not.<p>
 
 If an error occurs waiting for events, oop_sys_run returns OOP_ERROR.

why.html

@@ -20,12 +20,12 @@ might want to maintain several active user interfaces at once.
 Furthermore, each of these interfaces may be quite complex, sufficiently so to
 merit shared code modules which specialize in managing the interface.
 Widget sets deal with the details of the X protocol and graphical user 
-interface management; ``curses'' deals with the arcana of character-based
+interface management; "curses" deals with the arcana of character-based
 terminals; WWW libraries offer high-level access to whole families of Internet 
 transfer protocols; standard I/O and database routines manage filesystem data.
 <p>
 However, the existing techniques available for multiplexing interface code are
-very poor.  Most of these libraries work in ``blocking'' fashion; once 
+very poor.  Most of these libraries work in "blocking" fashion; once 
 instructed to complete a task (such as downloading a file, or presenting a 
 dialog to the user), they do not return until the task is complete (or failed),
 even though this may mean waiting an arbitrary amount of time for some external
@@ -35,7 +35,7 @@ other components.
 <p>
 Developers are thus left with several unpalatable choices:
 <ol>
-<li>Accept ``blocking'' operation.  User interfaces stop functioning while the 
+<li>Accept "blocking" operation.  User interfaces stop functioning while the 
 application waits for the network; one network client's access is stalled 
 while another client performs a transaction.  As more data moves from local
 storage (where access is fast enough that blocking is acceptable) to 
@@ -45,23 +45,23 @@ some problems, developers who choose this route must struggle with relatively
 immature and unportable threading models, and deal with the many libraries 
 which are not thread-safe; furthermore, threaded programming requires 
 thought-intensive and error-prone synchronization.
-<li>Use multiple processes (``forking'') for concurrency.  This can also work, 
+<li>Use multiple processes ("forking") for concurrency.  This can also work, 
 but requires all communication between modules to use some form of 
 inter-process communication, which increases complexity and decreases 
 performance.  Forking itself is a slow operation, leading to complex
-``pre-forking'' schemes for better performance.  Worst of all, each process 
+"pre-forking" schemes for better performance.  Worst of all, each process 
 must somehow multiplex IPC from other processes with whatever I/O task it had 
 to accomplish in the first place; this brings back the very problem forking 
 was designed to address.
 <li>Attempt to multiplex each library's I/O operations directly in a master
-``select loop''.  This requires the developer to understand intimately the
+"select loop".  This requires the developer to understand intimately the
 exact details of each library's I/O interactions, thus breaking modularity,
 fostering unhealthy dependency and leading to a single central snarl through
 which all I/O must pass.
 </ol>
 The paucity of options is reflected in the quality of applications.  How many
 programs hang unpleasantly while performing simple network operations like
-hostname resolution?  How many user interfaces are unnecessarily ``modal''?  
+hostname resolution?  How many user interfaces are unnecessarily "modal"?  
 How many simple servers fork for no good reason?  How many network applications
 simply don't exist because it's so difficult to write them?
 
@@ -73,7 +73,7 @@ source</em>.  These callbacks may be tied to file-descriptor activity, the
 system time, or process signals.  Liboop is responsible for invoking these
 callbacks as appropriate.
 <p>
-With this system, each module ``owns'' its own I/O; it can perform arbitrarily
+With this system, each module "owns" its own I/O; it can perform arbitrarily
 complex operations without blocking anything else in the program.  But since
 callbacks are executed purely sequentially, there is no complex concurrent code
 to manage.  From the application developer's point of view, working with liboop