Use TeX quotes -- ``foo'' -- as appropriate.
Remove whitespace around em-dashes.
diff --git a/Doc/lib/liboptparse.tex b/Doc/lib/liboptparse.tex
index 8b1b404..0cfbb9c 100644
--- a/Doc/lib/liboptparse.tex
+++ b/Doc/lib/liboptparse.tex
@@ -33,7 +33,7 @@
\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 @@
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 @@
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 @@
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 @@
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 @@
\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 @@
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 @@
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 @@
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 @@
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 @@
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 @@
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 @@
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 @@
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 @@
\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("-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 @@
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 @@
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 @@
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 @@
\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}