Use TeX quotes -- ``foo'' -- as appropriate.

Remove whitespace around em-dashes.

Doc/lib/liboptparse.tex

@@ -33,7 +33,7 @@ parser.add_option("-q", "--quiet",
 \end{verbatim}
 
 With these few lines of code, users of your script can now do the
-"usual thing" on the command-line:
+``usual thing'' on the command-line:
 
 \begin{verbatim}
 $ <yourscript> -f outfile --quiet
@@ -188,7 +188,7 @@ execution of a program.  In case it wasn't clear, options are usually
 options whatsoever.  (Pick a random program from the \UNIX{} or GNU
 toolsets.  Can it run without any options at all and still make sense?
 The only exceptions I can think of are \program{find}, \program{tar},
-and \program{dd} --- all of which are mutant oddballs that have been
+and \program{dd}---all of which are mutant oddballs that have been
 rightly criticized for their non-standard syntax and confusing
 interfaces.)
 
@@ -228,18 +228,18 @@ positively requires to run.
 A good user interface should have as few absolute requirements as
 possible.  If your program requires 17 distinct pieces of information in
 order to run successfully, it doesn't much matter \emph{how} you get that
-information from the user --- most people will give up and walk away
+information from the user---most people will give up and walk away
 before they successfully run the program.  This applies whether the user
 interface is a command-line, a configuration file, a GUI, or whatever:
 if you make that many demands on your users, most of them will just give
 up.
 
 In short, try to minimize the amount of information that users are
-absolutely required to supply --- use sensible defaults whenever
+absolutely required to supply---use sensible defaults whenever
 possible.  Of course, you also want to make your programs reasonably
 flexible.  That's what options are for.  Again, it doesn't matter if
 they are entries in a config file, checkboxes in the ``Preferences''
-dialog of a GUI, or command-line options --- the more options you
+dialog of a GUI, or command-line options---the more options you
 implement, the more flexible your program is, and the more complicated
 its implementation becomes.  It's quite easy to overwhelm users (and
 yourself!) with too much flexibility, so be careful there.
@@ -281,7 +281,7 @@ strings.  In this document, we'll only cover four of the things you
 can put there: \var{action}, \var{type}, \var{dest} (destination), and
 \var{help}.
 
-\subsubsection{The "store" action\label{optparse-store-action}}
+\subsubsection{The \var{store} action\label{optparse-store-action}}
 
 The action tells \module{optparse} what to do when it sees one of the
 option strings for this option on the command-line.  For example, the
@@ -289,7 +289,7 @@ action \var{store} means: take the next argument (or the remainder of
 the current argument), ensure that it is of the correct type, and
 store it to your chosen destination.
 
-For example, let's fill in the "..." of that last option:
+For example, let's fill in the ``...'' of that last option:
 
 \begin{verbatim}
 parser.add_option("-f", "--file",
@@ -308,7 +308,7 @@ args = ["-f", "foo.txt"]
 \function{parse_args()}, it automatically uses \var{sys.argv[1:]}.)
 
 When \module{optparse} sees the \programopt{-f}, it sucks in the next
-argument --- ``foo.txt'' --- and stores it in the \var{filename}
+argument---\code{foo.txt}---and stores it in the \var{filename}
 attribute of a special object.  That object is the first return value
 from \function{parse_args()}, so:
 
@@ -316,20 +316,20 @@ from \function{parse_args()}, so:
 print options.filename
 \end{verbatim}
 
-will print ``foo.txt''.
+will print \code{foo.txt}.
 
-Other option types supported by \module{optparse} are ``int'' and
-``float''.  Here's an option that expects an integer argument:
+Other option types supported by \module{optparse} are \code{int} and
+\code{float}.  Here's an option that expects an integer argument:
 
 \begin{verbatim}
 parser.add_option("-n", type="int", dest="num")
 \end{verbatim}
 
 Note that I didn't supply a long option, which is perfectly acceptable.
-I also didn't specify the action --- it defaults to ``store''.
+I also didn't specify the action---it defaults to ``store''.
   
 Let's parse another fake command-line.  This time, we'll jam the
-option argument right up against the option --- \programopt{-n42} (one
+option argument right up against the option---\programopt{-n42} (one
 argument) is equivalent to \programopt{-n 42} (two arguments). :
 
 \begin{verbatim}
@@ -359,10 +359,10 @@ destination for \programopt{-f} is \var{f}.
 Adding types is fairly easy; please refer to
 section~\ref{optparse-adding-types}, ``Adding new types.''
 
-\subsubsection{Other "store_*" actions\label{optparse-other-store-actions}}
+\subsubsection{Other \var{store_*} actions\label{optparse-other-store-actions}}
 
-Flag options --- set a variable to true or false when a particular
-option is seen --- are quite common.  \module{optparse} supports them
+Flag options---set a variable to true or false when a particular
+option is seen---are quite common.  \module{optparse} supports them
 with two separate actions, ``store_true'' and ``store_false''.  For
 example, you might have a \var{verbose} flag that is turned on with
 \programopt{-v} and off with \programopt{-q}:
@@ -374,7 +374,7 @@ parser.add_option("-q", action="store_false", dest="verbose")
 
 Here we have two different options with the same destination, which is
 perfectly OK.  (It just means you have to be a bit careful when setting
-default values --- see below.)
+default values---see below.)
 
 When \module{optparse} sees \programopt{-v} on the command line, it
 sets the \var{verbose} attribute of the special {option values}
@@ -474,16 +474,16 @@ best possible help message:
 usage = "usage: %prog [options] arg1 arg2"
 \end{verbatim}
 
-\module{optparse} expands "\%prog" in the usage string to the name of the
+\module{optparse} expands \samp{\%prog} in the usage string to the name of the
 current script, ie. \code{os.path.basename(sys.argv[0])}.  The
 expanded string is then printed before the detailed option help.
 
 If you don't supply a usage string, \module{optparse} uses a bland but
-sensible default: ``usage: \%prog [options]'', which is fine if your
+sensible default: \code{"usage: \%prog [options]"}, which is fine if your
 script doesn't take any positional arguments.
 
 \item every option defines a help string, and doesn't worry about 
-line-wrapping --- \module{optparse} takes care of wrapping lines and 
+line-wrapping---\module{optparse} takes care of wrapping lines and 
 making the help output look good.
 
 \item options that take a value indicate this fact in their
@@ -497,7 +497,7 @@ Here, ``MODE'' is called the meta-variable: it stands for the argument
 that the user is expected to supply to
 \programopt{-m}/\longprogramopt{mode}.  By default, \module{optparse}
 converts the destination variable name to uppercase and uses that for
-the meta-variable.  Sometimes, that's not what you want --- for
+the meta-variable.  Sometimes, that's not what you want---for
 example, the \var{filename} option explicitly sets
 \code{metavar="FILE"}, resulting in this automatically-generated
 option description:
@@ -578,7 +578,7 @@ $
 
 The one thing you need to know for basic usage is how
 \module{optparse} behaves when it encounters an error on the
-command-line --- e.g. \programopt{-n4x} where \programopt{-n} is an
+command-line---e.g. \programopt{-n4x} where \programopt{-n} is an
 integer-valued option.  \module{optparse} prints your usage message to
 stderr, followed by a useful and human-readable error message.  Then
 it terminates (calls \function{sys.exit()}) with a non-zero exit
@@ -673,7 +673,7 @@ parser.add_option("-q", "--quiet",
 
 This method makes it easier to track down exceptions raised by the
 \class{Option} constructor, which are common because of the complicated
-interdependencies among the various keyword arguments --- if you get it
+interdependencies among the various keyword arguments---if you get it
 wrong, \module{optparse} raises \exception{OptionError}.
 
 \method{add_option()} can be called in one of two ways:
@@ -1084,7 +1084,7 @@ parser.add_option("-n", "--noisy", ...)
 On the assumption that this is usually a mistake, \module{optparse}
 raises an exception (\exception{OptionConflictError}) by default when
 this happens.  Since this is an easily-fixed programming error, you
-shouldn't try to catch this exception --- fix your mistake and get on
+shouldn't try to catch this exception---fix your mistake and get on
 with life.
 
 Sometimes, you want newer options to deliberately replace the option
@@ -1185,7 +1185,7 @@ to call:
 parser.add_option("-c", callback=my_callback)
 \end{verbatim}
 
-Note that you supply a function object here --- so you must have
+Note that you supply a function object here---so you must have
 already defined a function \function{my_callback()} when you define
 the callback option.  In this simple case, \module{optparse} knows
 nothing about the arguments the \programopt{-c} option expects to
@@ -1237,7 +1237,7 @@ is the \class{Option} instance that's calling the callback.
 \term{opt}
 is the option string seen on the command-line that's triggering the
 callback.  (If an abbreviated long option was used, \var{opt} will be
-the full, canonical option string --- e.g. if the user puts
+the full, canonical option string---e.g. if the user puts
 \longprogramopt{foo} on the command-line as an abbreviation for
 \longprogramopt{foobar}, then \var{opt} will be
 \longprogramopt{foobar}.)
@@ -1348,7 +1348,7 @@ parser.add_option("-b", action="store_true", dest="b")
 parser.add_option("-c", action="callback", callback=check_order, dest='c')
 \end{verbatim}
 
-Of course, you could put any condition in there --- you're not limited
+Of course, you could put any condition in there---you're not limited
 to checking the values of already-defined options.  For example, if
 you have options that should not be called when the moon is full, all
 you have to do is this:
@@ -1363,7 +1363,7 @@ parser.add_option("--foo",
                   action="callback", callback=check_moon, dest="foo")
 \end{verbatim}
 
-(The definition of is_full_moon() is left as an exercise for the
+(The definition of \code{is_full_moon()} is left as an exercise for the
 reader.)
 
 \strong{Fixed arguments}
@@ -1567,20 +1567,20 @@ Adding new actions is a bit trickier, because you have to understand
 that \module{optparse} has a couple of classifications for actions:
 
 \begin{definitions}
-\term{"store" actions}
+\term{``store'' actions}
     actions that result in \module{optparse} storing a value to an attribute
-    of the OptionValues instance; these options require a 'dest'
+    of the OptionValues instance; these options require a \var{dest}
     attribute to be supplied to the Option constructor
-\term{"typed" actions}
+\term{``typed'' actions}
     actions that take a value from the command line and expect it to be
     of a certain type; or rather, a string that can be converted to a
-    certain type.  These options require a 'type' attribute to the
+    certain type.  These options require a \var{type} attribute to the
     Option constructor.
 \end{definitions}
 
-Some default ``store'' actions are ``store'', ``store_const'',
-``append'', and ``count''. The default ``typed'' actions are
-``store'', ``append'', and ``callback''.
+Some default ``store'' actions are \var{store}, \var{store_const},
+\var{append}, and \var{count}. The default ``typed'' actions are
+\var{store}, \var{append}, and \var{callback}.
 
 When you add an action, you need to decide if it's a ``store'' action,
 a ``typed'', neither, or both.  Three class attributes of
@@ -1590,10 +1590,10 @@ a ``typed'', neither, or both.  Three class attributes of
     All actions must be listed as strings in ACTIONS.
 \end{memberdesc}
 \begin{memberdesc}{STORE_ACTIONS}
-    "store" actions are additionally listed here.
+    ``store'' actions are additionally listed here.
 \end{memberdesc}
 \begin{memberdesc}{TYPED_ACTIONS}
-    "typed" actions are additionally listed here.
+    ``typed'' actions are additionally listed here.
 \end{memberdesc}
 
 In order to actually implement your new action, you must override
@@ -1688,8 +1688,8 @@ You'll have to
 
 \begin{enumerate}
 \item subclass OptionParser and override the error() method
-\item subclass Option and override the take_action() method --- you'll
-      need to provide your own handling of the "help" action that
+\item subclass Option and override the take_action() method---you'll
+      need to provide your own handling of the ``help'' action that
       doesn't call sys.exit()
 \end{enumerate}