Fixed index references to modules.

Placed references closer to usage.

2 files changed, 16 insertions, 14 deletions

diff --git a/Doc/lib/libshelve.tex b/Doc/lib/libshelve.tex
index 05b3a93..25ced0e 100644
--- a/Doc/lib/libshelve.tex
+++ b/Doc/lib/libshelve.tex
@@ -1,9 +1,6 @@
 \section{Standard Module \sectcode{shelve}}
 \label{module-shelve}
 \stmodindex{shelve}
-\stmodindex{pickle}
-\bimodindex{dbm}
-\bimodindex{gdbm}
 
 A ``shelf'' is a persistent, dictionary-like object.  The difference
 with ``dbm'' databases is that the values (not the keys!) in a shelf
@@ -11,6 +8,7 @@ can be essentially arbitrary Python objects --- anything that the
 \code{pickle} module can handle.  This includes most class instances,
 recursive data types, and objects containing lots of shared
 sub-objects.  The keys are ordinary strings.
+\refstmodindex{pickle}
 
 To summarize the interface (\code{key} is a string, \code{data} is an
 arbitrary object):
@@ -37,20 +35,23 @@ Restrictions:
 \begin{itemize}
 
 \item
-The choice of which database package will be used (e.g. dbm or gdbm)
+The choice of which database package will be used (e.g. \code{dbm} or
+\code{gdbm})
 depends on which interface is available.  Therefore it isn't safe to
-open the database directly using dbm.  The database is also
-(unfortunately) subject to the limitations of dbm, if it is used ---
+open the database directly using \code{dbm}.  The database is also
+(unfortunately) subject to the limitations of \code{dbm}, if it is used ---
 this means that (the pickled representation of) the objects stored in
 the database should be fairly small, and in rare cases key collisions
 may cause the database to refuse updates.
+\refbimodindex{dbm}
+\refbimodindex{gdbm}
 
 \item
 Dependent on the implementation, closing a persistent dictionary may
 or may not be necessary to flush changes to disk.
 
 \item
-The \code{shelve} module does not support {\em concurrent} read/write
+The \code{shelve} module does not support \emph{concurrent} read/write
 access to shelved objects.  (Multiple simultaneous read accesses are
 safe.)  When a program has a shelf open for writing, no other program
 should have it open for reading or writing.  \UNIX{} file locking can
diff --git a/Doc/libshelve.tex b/Doc/libshelve.tex
index 05b3a93..25ced0e 100644
--- a/Doc/libshelve.tex
+++ b/Doc/libshelve.tex
@@ -1,9 +1,6 @@
 \section{Standard Module \sectcode{shelve}}
 \label{module-shelve}
 \stmodindex{shelve}
-\stmodindex{pickle}
-\bimodindex{dbm}
-\bimodindex{gdbm}
 
 A ``shelf'' is a persistent, dictionary-like object.  The difference
 with ``dbm'' databases is that the values (not the keys!) in a shelf
@@ -11,6 +8,7 @@ can be essentially arbitrary Python objects --- anything that the
 \code{pickle} module can handle.  This includes most class instances,
 recursive data types, and objects containing lots of shared
 sub-objects.  The keys are ordinary strings.
+\refstmodindex{pickle}
 
 To summarize the interface (\code{key} is a string, \code{data} is an
 arbitrary object):
@@ -37,20 +35,23 @@ Restrictions:
 \begin{itemize}
 
 \item
-The choice of which database package will be used (e.g. dbm or gdbm)
+The choice of which database package will be used (e.g. \code{dbm} or
+\code{gdbm})
 depends on which interface is available.  Therefore it isn't safe to
-open the database directly using dbm.  The database is also
-(unfortunately) subject to the limitations of dbm, if it is used ---
+open the database directly using \code{dbm}.  The database is also
+(unfortunately) subject to the limitations of \code{dbm}, if it is used ---
 this means that (the pickled representation of) the objects stored in
 the database should be fairly small, and in rare cases key collisions
 may cause the database to refuse updates.
+\refbimodindex{dbm}
+\refbimodindex{gdbm}
 
 \item
 Dependent on the implementation, closing a persistent dictionary may
 or may not be necessary to flush changes to disk.
 
 \item
-The \code{shelve} module does not support {\em concurrent} read/write
+The \code{shelve} module does not support \emph{concurrent} read/write
 access to shelved objects.  (Multiple simultaneous read accesses are
 safe.)  When a program has a shelf open for writing, no other program
 should have it open for reading or writing.  \UNIX{} file locking can