Didier Verna  committed 9baeea9

Concept Index.

ChangeLog entries:

2012-01-13 Didier Verna <>

* doc/patcher.texi: New macros for concept indexing.
* doc/patcher.texi (Top):
* doc/patcher.texi (Setting up Patcher):
* doc/patcher.texi (Calling Patcher):
* doc/patcher.texi (Project Descriptors):
* doc/patcher.texi (Themes):
* doc/patcher.texi (Project inheritance):
* doc/patcher.texi (Fallbacks):
* doc/patcher.texi (Retrieval):
* doc/patcher.texi (Mail Adaptation):
* doc/patcher.texi (Subprojects):
* doc/patcher.texi (Temporary Subprojects):
* doc/patcher.texi (Permanent Subprojects):
* doc/patcher.texi (Defining Subprojects):
* doc/patcher.texi (Project Naming):
* doc/patcher.texi (Command Directory):
* doc/patcher.texi (Submodules):
* doc/patcher.texi (Mail Methods):
* doc/patcher.texi (Standard Mail Methods):
* doc/patcher.texi (Other Mail Methods):
* doc/patcher.texi (Message Customization):
* doc/patcher.texi (Diff Command):
* doc/patcher.texi (Diff Headers):
* doc/patcher.texi (Diff Line Filter):
* doc/patcher.texi (Diff Prologue):
* doc/patcher.texi (ChangeLogs Naming):
* doc/patcher.texi (ChangeLogs Updating):
* doc/patcher.texi (Skeleton Generation):
* doc/patcher.texi (Skeleton Parameters):
* doc/patcher.texi (ChangeLog Files):
* doc/patcher.texi (ChangeLogs Appearance):
* doc/patcher.texi (ChangeLogs Prologue):
* doc/patcher.texi (ChangeLogs Status):
* doc/patcher.texi (Commit Command):
* doc/patcher.texi (Log Message Handling):
* doc/patcher.texi (Log Message Elements):
* doc/patcher.texi (Commit Operation):
* doc/patcher.texi (Before Sending):
* doc/patcher.texi (After Sending):
* doc/patcher.texi (Prefixing Commands):
* doc/patcher.texi (Error Handling):
* doc/patcher.texi (XEmacs Development):
* doc/patcher.texi (Indexes):
* doc/patcher.texi (Concept Index):
* doc/patcher.texi (Variable Index):
* doc/patcher.texi (Function Index): Add a bunch of concept index
entries (project options, themes, subprojects etc.).

  • Participants
  • Parent commits ce7a0dc

Comments (0)

Files changed (1)

File doc/patcher.texi

 @c Author:        Didier Verna <>
 @c Maintainer:    Didier Verna <>
 @c Created:       Sun Apr 21 21:34:06 2002
-@c Last Revision: Fri Jan 13 09:35:26 2012
+@c Last Revision: Fri Jan 13 11:23:03 2012
 @c This file is part of Patcher.
 @end macro
+@c Subproject options index
+@macro spoindex{name}
+@cindex Subproject Option, @t{:\name\}
+@cindex @t{:\name\} (subproject option)
+@end macro
+@c Project option index
+@macro poindex{name}
+@cindex Project Option, @t{:\name\}
+@cindex @t{:\name\} (project option)
+@end macro
+@c Fallbacked project option index
+@macro fpoindex{name}
+@vindex patcher-default-\name\
+@end macro
+@c Built-in theme index
+@macro bitindex{name}
+@cindex Built-in Theme, @t{\name\}
+@cindex Theme, Built-in, @t{\name\}
+@cindex @t{\name\} (built-in theme)
+@end macro
+@c Built-in RCS theme index
+@macro birtindex{name}
+@end macro
 @c ====================================================================
 * Quick Start::        For the brave and the impatient
 * User Manual::        A step-by-step guide to using Patcher
 * XEmacs Development:: An XEmacs specific sample setup
-* Variables Index::
-* Functions Index::
-* Keystrokes Index::
+* Indexes::            Concept, Variable, Function and Keystroke
 @end menu
 Patcher is developed by Didier Verna @email{}.
         :themes (git))))
 @end lisp
+@cindex Project Descriptor
+@cindex Descriptor, Project
 @vindex patcher-projects
 As you can imagine, @code{patcher-projects} is a user option in which
 you store information about the projects you want to manage with
 @email{}. In addition to that, this
 project is handled by Git.
+@cindex Project Option
+@cindex Theme
 Note the particular syntax for specifying the mailing address. This is
 what's called a @dfn{project option}. Contrary to the project's name and
 directory, which are mandatory and always appear as the first and second
-@vindex patcher-default-to-address
-@vindex :to-address
 Patcher prepares a mail buffer. The message will be sent to the address
 you specified with the @code{:to-address} project option, and the
 subject line now reads ``[PATCH] something sensible here''.
 @node Project Descriptors, Entry Points, Starting Up, Starting Up
 @subsection Project Descriptors
+@cindex Project Descriptor
+@cindex Descriptor, Project
 @vindex patcher-projects
 Projects specifications are stored in @code{patcher-projects}. This user
 option is actually a list of @dfn{project descriptors}. Each project
 several independent projects happen to share exactly the same set of
-@vindex patcher-default-to-address
-@vindex :to-address
+@cindex Project Option
 The remainder of a project descriptor is a sequence of zero or more
 option/value pairs that we call @dfn{project options}. All option names
 start with a colon. The type of a value depends on the corresponding
 @node Themes, Project inheritance, , Project Descriptors
 @subsubsection Themes
+@cindex Theme
 If you have several projects sharing the same option set, you might want
 to setup a theme. Themes are named collections of project options.
 a sequence of zero or more option/value pairs, just like in project
-@vindex patcher-default-themes
-@vindex :themes
 In order to use a theme in a given project, a @code{:themes} project
 option is provided. It is a list of theme names (symbols). Use this
 option in your project descriptor, and the project will implicitly
 @code{patcher-max-theme-depth} user option is provided. It represents
 the expected maximum theme nesting level and defaults to 8.
+@cindex Built-in Theme
+@cindex Theme, Built-in
 @vindex patcher-built-in-themes
 Patcher comes with a set of built-in themes for several revision control
 systems. These are Git, Mercurial (Hg), Darcs, Subversion (Svn), CVS and
 PRCS. Look at the value of @code{patcher-built-in-themes} to see what's
 when you let Patcher generate the ChangeLog entries (@pxref{ChangeLogs
+@vindex pather-themes
 While you can't modify the value of @code{patcher-built-in-themes},
 you're free to do whatever you want in @code{patcher-themes},
 including creating a theme with the same name as a built-in one. This
 @node Project inheritance, Fallbacks, Themes, Project Descriptors
 @subsubsection Project inheritance
+@cindex Project Inheritance
 When two projects are very similar, you might prefer to use the project
 inheritance mechanism described below over themes.
-@vindex :inheritance
 There is a special project option called @code{:inheritance}. This
 option must be a list of project names (strings). The inheritance of a
 project defines a list of projects from which to inherit options.
 @node Fallbacks, Retrieval, Project inheritance, Project Descriptors
 @subsubsection Fallbacks
-@vindex patcher-default-to-address
-@vindex :to-address
+@cindex Fallback
 For each existing project option, Patcher also has a @dfn{fallback} user
 option with a default value that would be shared among all projects not
 setting the option explicitly. The name of the fallback is obtained by
 is given.
-@vindex patcher-default-themes
-@vindex :themes
 @vindex patcher-themes
 If that fails, it next tries the given themes, if any. This involves
 recursively traversing the project's themes tree. Options successfully
 retrieved in themes are said to be @dfn{themed}.
-@vindex :inheritance
 If that still fails, it then tries the inherited projects, if any. This
 involves recursively traversing the project's inheritance tree. Options
 successfully retrieved in inherited projects are said to be
 diff of your project.
 @end defun
-@vindex patcher-default-subject-rewrite-format
-@vindex :subject-rewrite-format
 When adapting a message to Patcher, you are always prompted for a new
 subject line, although you can just hit @kbd{Return} to leave it empty.
 If there is indeed a subject change (that is, if there is both an old
 @node Subprojects, Submodules, Project Relocation, Starting Up
 @subsection Subprojects
+@cindex Subproject
 As mentioned before (@pxref{Entry Points}) the entry point functions all
 perform a global diff of your project just after having prepared the
 mail buffer. There might be times, however, when you want to work on a
 @node Temporary Subprojects, Permanent Subprojects, Subprojects, Subprojects
 @subsubsection Temporary Subprojects
+@cindex Temporary Subproject
+@cindex Subproject, Temporary
 In order to work on a temporary subproject, call any of the entry point
 functions (@pxref{Entry Points}) with a simple prefix argument
 (@key{C-u}). Patcher will then prompt you for an optional subdirectory
 @node Permanent Subprojects, , Temporary Subprojects, Subprojects
 @subsubsection Permanent Subprojects
+@cindex Permanent Subproject
+@cindex Subproject, Permanent
 If you happen to work more than once on the same project subset, it will
 quickly become annoying to have to specify explicitly the same
 subdirectory and/or files over and over again. Consequently, Patcher
 @node Defining Subprojects, Project Naming, , Permanent Subprojects
 @b{Defining Subprojects}
+@cindex Subproject Descriptor
+@cindex Descriptor, Subproject
 @vindex patcher-subprojects
 The user option @code{patcher-subprojects} stores a list of
 @dfn{subproject descriptors}. A subproject descriptor is almost the same
 is based on.
+@cindex Subproject Option
 In addition to the standard project options we've already seen, two
 subproject options are available:
 @table @code
 @item :subdirectory
-@vindex :subdirectory
 This lets you specify a subdirectory of the original project's directory
 in which the whole subproject resides. This subdirectory must be
 provided @emph{relative} to the original project's directory.
 @item :files
-@vindex :files
 This lets you specify a list of files or directories composing the
 subproject. Each file specification may be provided @emph{relative} to
 the subdirectory above, if any, or to the original project's directory.
 (that would be meaningless). They can't appear in a theme either.
-@vindex :inheritance
 Subprojects don't have an @code{:inheritance} mechanism. Instead, they
 implicitly inherit from their base project (which in turn can inherit
 from other projects).
 subprojects first, and then regular projects.
-@vindex :subdirectory
-@vindex :files
 A subproject with neither a @code{:subdirectory} nor a @code{:files}
 option is exactly the same as the base project, apart from project
 options that you would override. This can hence be seen as an elegant
 their commands. It would then be difficult to define project variants
 for the same directory but with different names.
-@vindex patcher-default-name
-@vindex :name
 To remedy this problem, patcher provides a @code{:name} project option.
 If set, it will be used by diff and commit commands instead of the
 project's name when necessary. See @ref{Diff Command} for details on how
 For example, PRCS (weird, did I mention it already?) can only work in
 the project's root directory.
-@vindex :command-directory
-@vindex patcher-default-command-directory
 If you want to define projects for which the revision control system can
 be executed in only one directory, Patcher provides you with the
 @code{:command-directory} project option (a string). This directory must
 @node Submodules, Patcher Instances, Subprojects, Starting Up
 @subsection Submodules
+@cindex Submodule
 Related to the notion of subproject is that of ``submodule'' (or
 ``subrepo'') as some RCSes would put it. A submodule is a standalone
 project that appears under another project (so it looks like a
 umbrella project automatically, with their own name and directory, so
 that you don't need to define them by hand.
-@vindex :submodule-detection-function
-@vindex patcher-default-submodule-detection-function
 @findex patcher-hg-detect-submodules
 @findex patcher-git-detect-submodules
 Automatic detection of submodules is controlled via the
 @code{:submodule-detection-function} project option. Its value is a
 symbol naming a function, or @code{nil} if you don't want autodetection.
-The built-in Mercurial and Git themes set this option to
+The built-in Git and Mercurial themes set this option to
 @code{patcher-hg-detect-submodules} and
 @code{patcher-git-detect-submodules} respectively.
 @node Mail Methods, Message Customization, Message Generation, Message Generation
 @subsection Mail Methods
-@vindex patcher-default-mail-method
-@vindex :mail-method
 Since there are different mail packages working in XEmacs, Patcher
 supports different methods for preparing messages. You can specify the
 method you prefer in the @code{:mail-method} project option. The value
 send with Patcher, most probably because they are sent to some
 mailing-list, such as @email{}.
-@vindex patcher-default-gnus-group
-@vindex :gnus-group
 This method uses a Gnus group name and acts as if you had type @samp{C-u
 a} on that group in the @code{*Group*} buffer, hence honoring the group
 parameters and posting-styles. If your project does not specify a Gnus
 @node Other Mail Methods, , Fake Mail Method, Mail Methods
 @subsubsection Other Mail Methods
-@vindex patcher-default-mail-method
-@vindex :mail-method
 If you're not satisfied with the provided mail methods (want a @code{vm}
 one?), you can provide your own, more or less (patches welcome if you do
 so). Here's what to do: set your @code{:mail-method} project option to,
 @table @code
 @item :user-name
-@vindex patcher-default-user-name
-@vindex :user-name
 The name (your name) to use when composing the message. It will affect
 the @code{From:} header. This option is used by all mail methods but
 @code{fake}. If not given, @code{user-full-name} is used.
 @item :user-mail
-@vindex patcher-default-user-mail
-@vindex :user-mail
 The mail (your mail) address to use when composing the message. It will
 affect the @code{From:} header. This option is used by all mail methods but
 @code{fake}. If not given, @code{user-mail-address} is used.
 @item :to-address
-@vindex patcher-default-to-address
-@vindex :to-address
 The address to send messages to (a string). This option is used by all
 mail methods but @code{gnus} and @code{fake}. If not given, it is
 prompted for when calling @code{patcher-mail}.
 @item :gnus-group
-@vindex patcher-default-gnus-group
-@vindex :gnus-group
 The Gnus group name to use for posting messages (a string). This option
 is used only by the @code{gnus} mail method. If not given, it is
 prompted for when calling @code{patcher-mail}.
 corresponding Patcher options.
 @item :subject-prefix
-@vindex patcher-default-subject-prefix
-@vindex :subject-prefix
 A prefix for the subject line of messages. It can be @code{nil} or a
 string. By default, ``[PATCH]'' is used. This part of subjects is never
 prompted for. The subject prefix understands @samp{%n} and @samp{%N}
 remainder of the subject, when appropriate.
 @item :subject
-@vindex patcher-default-subject
-@vindex :subject
 A default value for prompted subjects (a string). Please note that this
 is used @strong{only} to provide a default value for prompted subjects.
 Subjects are @strong{always} prompted for. The subject understands
 @node Diff Command, Diff Headers, Patch Generation, Patch Generation
 @subsection Diff Command
-@vindex patcher-default-diff-command
-@vindex :diff-command
 @findex patcher-mail
 The diff command used to generate the patch is specified by the
 @code{:diff-command} project option. You can also punctually change this
 @table @code
 @item %n
-@vindex patcher-default-name
-@vindex :name
 A @samp{%n} will be replaced with the project's name, that is, either
 the value of the @samp{:name} option (@pxref{Project Naming}) or the
 name of the project descriptor. This may be useful in commands with
 replaced by @samp{STR}.
 @end table
 Here is an example to clarify this: the default diff command for Git in
 the @samp{git} built-in theme (@pxref{Themes}) is the following:
 generate different diff outputs, making this association difficult to
-@vindex patcher-default-diff-header
-@vindex :diff-header
 Patcher provides a @code{:diff-header} project option to help. Its value
 is of the form @code{(REGEXP NUMBER1 NUMBER2)}. @code{REGEXP} is used to
 match the beginning of a diff output while NUMBER1 and NUMBER2 are the
 files present in your local copy but otherwise unknown to the server
 with a question mark in diff outputs.
-@vindex patcher-default-diff-line-filter
-@vindex :diff-line-filter
 Patcher has a project option named @code{:diff-line-filter} that lets
 filter out such unwanted lines. This must be a regular expression
 matching a whole line. Caution however: do not put beginning or end of
 the message in preparation. This prologue gives information such as the
 diff command used, the files affected and so on.
-@vindex patcher-default-diff-prologue-function
-@vindex :diff-prologue-function
 @findex patcher-default-diff-prologue
 The function used to generate this prologue can be specified with the
 @code{:diff-prologue-function} project option. A value of @code{nil}
 @node ChangeLogs Naming, ChangeLogs Updating, ChangeLogs Handling, ChangeLogs Handling
 @subsection ChangeLogs Naming
-@vindex patcher-default-change-log-file-name
-@vindex :change-log-file-name
 By default, Patcher thinks that ChangeLog files are named ``ChangeLog''.
 That is very clever, but if for some obscure reason that is not the case
 in your project, you can change this by setting the
 @node ChangeLogs Updating, ChangeLogs Navigation, ChangeLogs Naming, ChangeLogs Handling
 @subsection ChangeLogs Updating
-@vindex patcher-default-change-logs-updating
-@vindex :change-logs-updating
 The way Patcher deals with ChangeLogs is controlled via the
 @code{:change-logs-updating} project option. Its value (a symbol) must
 be one of @code{automatic} (the default), @code{manual} or @code{nil}.
 @node Skeleton Generation, Skeleton Parameters, Automatic ChangeLogs, Automatic ChangeLogs
 @findex patch-to-change-log
-@vindex patcher-default-diff-cleaner
 @findex patcher-default-diff-cleaner
-@vindex :diff-cleaner
 ChangeLog skeletons are not generated by Patcher directly, but rather by
 the function @code{patch-to-change-log} from the @code{add-log} library,
 itself from the @code{xemacs-base} package. This function supports only
 that will be used to ``cleanup'' the diff (so that it looks like a
 standard one, just before calling @code{patch-to-change-log}.
 Patcher comes with a generic cleaner function named
 @code{patcher-default-diff-cleaner} which is used by default and works
 correctly with Git, Mercurial, Darcs and PRCS, as long as you use the
 @node Skeleton Parameters, ChangeLog Files, Skeleton Generation, Automatic ChangeLogs
-@vindex patcher-default-change-logs-user-name
-@vindex :change-logs-user-name
-@vindex patcher-default-user-name
-@vindex :user-name
-@vindex patcher-default-change-logs-user-mail
-@vindex :change-logs-user-mail
-@vindex patcher-default-user-mail
-@vindex :user-mail
 @findex patch-to-change-log
 @vindex user-full-name
 @vindex user-mail-address
 @itemize @bullet
 @item @code{:link-change-log-hook}
-@vindex patcher-default-link-change-log
-@vindex :link-change-log-hook
 This hook is run every time Patcher ``links'' a ChangeLog file to a
 project. Linking a ChangeLog file in this context means figuring out
 that it is involved in the current patch. Every function in this hook
 run, the current directory (in whatever the current buffer is) is set to
 the project's directory.
 @item @code{:after-save-change-log-hook}
-@vindex patcher-default-after-save-change-log-hook
-@vindex :after-save-change-log-hook
 This hook is run every time you save a ChangeLog file. The functions in
 this hook are executed in the ChangeLog's buffer. To be honest with you,
 I didn't invent anything here, and I must confess that this is not a
 fact, their existence comes from my desire to support Git projects by
 @vindex patcher-built-in-themes
 If you look at @code{patcher-built-in-themes}, you will find two themes
 for Git (along with their their whitespace-cleaning counterpart):
 on what's in the Git staging area. This is cool as long as ChangeLog
 files are written by hand @pxref{Manual ChangeLogs}. However, in
 automatic mode, we need a way to add them to the index once the
-skeletons are filled in. This is done by another theme that you must add
-explicitly to your project, called
+skeletons are filled in. This is done by another built-in theme that you
+must add explicitly to your project, called
 @code{git-index-automatic-change-logs}. This theme uses the two options
 described above to automatically add ChangeLog entries to the staging
 @node ChangeLogs Appearance,  ChangeLogs Prologue, ChangeLogs Navigation, ChangeLogs Handling
 @subsection ChangeLogs Appearance
-@vindex patcher-default-change-logs-appearance
-@vindex :change-logs-appearance
 The appearance of ChangeLog entries in the message is controlled by the
 @code{:change-logs-appearance} project option. Its value must be a
 symbol from the following:
 The ChangeLog entries don't appear in the message at all.
 @end table
-@vindex patcher-default-change-logs-diff-command
-@vindex :change-logs-diff-command
 When the ChangeLogs appearance is either @code{pack} or @code{patch},
 the diff command used to generate the patch is controlled by the
 @code{:change-logs-diff-command} project option. The value can be
 contexts from the diff, because otherwise, ChangeLog patches often fail
 to apply correctly.
-@vindex patcher-default-diff-command
-@vindex :diff-command
 The @code{:change-logs-diff-command} project option supports the same
 substitution constructs as the @code{:diff-command} one (@pxref{Diff
 Command}). For example, here is the ChangeLogs diff command used in the
 ChangeLog prologues are small pieces of informative text that Patcher
 adds above each ChangeLog insertion in the mail buffer.
-@vindex patcher-default-change-logs-prologue
-@vindex :change-logs-prologue
 When the ChangeLogs appearance is @code{verbatim}, Patcher inserts one
 prologue per ChangeLog file. The prologue's contents is controlled by
 the @code{:change-logs-prologue} project option (a string). A @samp{%f}
 The default value for @code{patcher-default-change-logs-prologue} is
 @code{"%f addition:"}.
-@vindex patcher-default-diff-prologue-function
-@vindex :diff-prologue-function
 @findex patcher-default-diff-prologue
 When the ChangeLogs appearance is @code{pack}, Patcher inserts only one
 prologue for the whole ChangeLogs patch. When @code{patch}, there is a
 how nice would it be to continue manipulating ChangeLog entries, as
 usual, but just not store them into files?
-@vindex patcher-default-change-logs-status
-@vindex :default-change-logs-status
 Patcher can do that. It has a project option named
 @code{:change-logs-status} which can have two values (symbols). A value
 of @code{persistent} (the default) is in fact what we have assumed so
 far: there are ChangeLog files and they are part of the project. This is
 the traditional approach.
-@vindex patcher-default-change-log-file-name
-@vindex :change-log-file-name
 A value of @code{ephemeral} on the other hand means that your ChangeLog
 entries exist only temporarily, to be used in the commit log message
 and/or inserted verbatim in the mail. Patcher does this by creating a
 files (old ChangeLog files may for example be renamed to
 Because there's only one, virtual, ephemeral ChangeLog file located at
 the project's base directory, the default value for the ChangeLogs
 prologue doesn't work very well in the ephemeral case. It doesn't make
 both set the ChangeLog status to @samp{ephemeral} and modify the
 prologue at the same time.
 One final note: if you use the @code{git-index} built-in theme with
 ephemeral ChangeLogs, don't use it in conjunction with
 @code{git-index-automatic-change-logs}, even if the ChangeLogs entries
 @subsection Commit Command
 @findex patcher-mail-commit
-@vindex patcher-default-commit-command
-@vindex :commit-command
 The command used to to commit a patch is specified by the
 @code{:commit-command} project option (a string). You can also
 temporarily change the command in question by calling
 your archival software does not support log messages. I'm not actually
 sure such a beast exists.
 As an example, here is the commit command for the Git built-in theme
 (@pxref{Themes}): @samp{git commit %!f@{-a @}-F %s%?f@{ -- @}%f}
 message}: a short yet informative message that accompany the commit
 operation, which is also stored in the repository.
-@vindex patcher-default-edit-log-message
-@vindex :edit-log-message
 Before a commit operation, Patcher always builds an initial log message,
 based on certain elements under your control. What happens next is
 controlled the @code{:edit-log-message} project option: if @code{t} (the
 @node Log Message Elements, Log Message Editing, Log Message Handling, Log Message Handling
 @subsubsection Log Message Elements
-@vindex patcher-default-log-message-items
-@vindex :log-message-items
 Patcher has the ability to initialize the log message with different
 elements. These elements are specified with the
 @code{:log-message-items} project option. Its value is either
 The raw ChangeLog entries.
 @end table
-@vindex patcher-default-change-logs-separator
-@vindex :change-logs-separator
 By default, only the message's subject is used. When using more than one
 item, they appear in the order specified above. If anything appears
 before the raw ChangeLog entries, a separator string is used. This
 buffer if you have not required log message editing, or after typing
 @kbd{C-c C-p c} or @kbd{C-c C-c} from the log message buffer otherwise.
-@vindex patcher-default-edit-commit-command
-@vindex :edit-commit-command
 At that point, Patcher has constructed a proper commit command. What
 happens next depends on the value of the @code{:edit-commit-command}
 project option: if @code{nil}, Patcher performs the commit operation
 @itemize @bullet
-@vindex patcher-default-subject-committed-prefix
-@vindex :subject-committed-prefix
 The subject prefix is changed to that specified by the
 @code{:subject-committed-prefix} project option (a string), unless it is
 @code{nil}. By default, ``[COMMIT]'' is used.
-@vindex patcher-default-committed-notice
-@vindex :committed-notice
 A commit notice is added at the very beginning of the message's body.
 This notice is specified by the @code{:committed-notice} project option.
 It can be @code{nil} or a string. By default, it reads ``NOTE: this
 @itemize @bullet
 @item ChangeLogs insertion
-@vindex patcher-default-check-change-logs-insertion
-@vindex :check-change-logs-insertion
 In case of manual ChangeLog insertion (@pxref{ChangeLogs Appearance}),
 Patcher can check that you have indeed inserted the ChangeLog entries
 before sending the message. This behavior is controlled by the
 @item Commit Operation
-@vindex patcher-default-commit-privilege
-@vindex :commit-privilege
 Patcher has a @code{:commit-privilege} project option; a Boolean
 specifying whether you're likely to commit your changes by yourself.
-@vindex patcher-default-check-commit
-@vindex :check-commit
 In case of commit privilege, Patcher can check that you have indeed
 committed your changes before sending the message. This behavior is
 controlled by the @code{:check-commit} user option. A value of
 @table @code
 @item :kill-sources-after-sending
-@vindex patcher-default-kill-sources-after-sending
-@vindex :kill-sources-after-sending
 Whether to kill source files after sending the message. If @code{nil},
 the source files will remain visited.
 @item :kill-change-logs-after-sending
-@vindex patcher-default-kill-change-logs-after-sending
-@vindex :kill-change-logs-after-sending
 Whether to kill ChangeLog files after sending the message. If
 @code{nil}, the ChangeLog files will remain visited.
 @end table
 @code{runsocks}. Of course, this can be done manually in all your
 command settings, but Patcher offers you a simpler way to do it.
-@vindex patcher-default-pre-command
-@vindex :pre-command
 There is a project option named @code{:pre-command} which can be used
 for this kind of thing. It must be a string that will be prepended to
 all operations performed by Patcher.
 From time to time, commands may fail for different reasons. Patcher
 tracks command failures and lets you know when that happens.
-@vindex patcher-default-ignore-diff-status
-@vindex :ignore-diff-status
 The first thing Patcher does is to check the external processes exit
 codes. A non-zero exit code will normally trigger a Patcher error. There
 is however one notable exception: @code{cvs diff} has this incredibly
 @code{:ignore-diff-status} that is set to @code{t} in the CVS theme.
 There should be no reason to use it in any other context.
-@vindex patcher-default-failed-command-regexp
-@vindex :failed-command-regexp
 Next, Patcher looks for specific strings in process output. The
 @code{:failed-command-regexp} project option lets you specify a regular
 expression to match with the output of an aborted command. In the CVS
 @c ====================================================================
 @c XEmacs Development
 @c ====================================================================
-@node XEmacs Development, Variables Index, User Manual, Top
+@node XEmacs Development, Indexes, User Manual, Top
 @appendix XEmacs Development
 XEmacs development occurs on a Mercurial repository. Patches are
 @c ====================================================================
-@c Variables Index
+@c Indexes
 @c ====================================================================
-@node Variables Index, Functions Index, XEmacs Development, Top
-@unnumbered Variables Index
+@node Indexes, , XEmacs Development, Top
+@appendix Indexes
+* Concept Index::
+* Variable Index::
+* Function Index::
+* Keystroke Index::
+@end menu
+@c -------------
+@c Concept Index
+@c -------------
+@node Concept Index, Variable Index, Indexes, Indexes
+@section Concepts
+@printindex cp
+@c --------------
+@c Variable Index
+@c --------------
+@node Variable Index, Function Index, Concept Index, Indexes
+@section Variables
 @printindex vr
-@c ====================================================================
-@c Functions Index
-@c ====================================================================
-@node Functions Index,  Keystrokes Index, Variables Index, Top
-@unnumbered Functions Index
+@c --------------
+@c Function Index
+@c --------------
+@node Function Index,  Keystroke Index, Variable Index, Indexes
+@section Functions
 @printindex fn
-@c ====================================================================
-@c Keystrokes Index
-@c ====================================================================
-@node Keystrokes Index,  , Functions Index, Top
-@unnumbered Keystrokes Index
+@c ---------------
+@c Keystroke Index
+@c ---------------
+@node Keystroke Index,  , Function Index, Indexes
+@section Keystrokes
 @printindex ky