Here are some tips for the writing of documentation strings.
- Every command, function, or variable intended for users to know about
should have a documentation string.
- An internal variable or subroutine of a Lisp program might as well have
a documentation string. In earlier Emacs versions, you could save space
by using a comment instead of a documentation string, but that is no
longer the case.
- The first line of the documentation string should consist of one or two
complete sentences that stand on their own as a summary. M-x
apropos displays just the first line, and if it doesn’t stand on its
own, the result looks bad. In particular, start the first line with a
capital letter and end with a period.
The documentation string can have additional lines that expand on the
details of how to use the function or variable. The additional lines
should be made up of complete sentences also, but they may be filled if
that looks good.
- For consistency, phrase the verb in the first sentence of a
documentation string as an infinitive with “to” omitted. For
instance, use “Return the cons of A and B.” in preference to “Returns
the cons of A and B.” Usually it looks good to do likewise for the
rest of the first paragraph. Subsequent paragraphs usually look better
if they have proper subjects.
- Write documentation strings in the active voice, not the passive, and in
the present tense, not the future. For instance, use “Return a list
containing A and B.” instead of “A list containing A and B will be
returned.”
- Avoid using the word “cause” (or its equivalents) unnecessarily.
Instead of, “Cause Emacs to display text in boldface,” write just
“Display text in boldface.”
- Do not start or end a documentation string with whitespace.
- Format the documentation string so that it fits in an Emacs window on an
80-column screen. It is a good idea for most lines to be no wider than
60 characters. The first line can be wider if necessary to fit the
information that ought to be there.
However, rather than simply filling the entire documentation string, you
can make it much more readable by choosing line breaks with care.
Use blank lines between topics if the documentation string is long.
- Do not indent subsequent lines of a documentation string so
that the text is lined up in the source code with the text of the first
line. This looks nice in the source code, but looks bizarre when users
view the documentation. Remember that the indentation before the
starting double-quote is not part of the string!
- A variable’s documentation string should start with ‘*’ if the
variable is one that users would often want to set interactively. If
the value is a long list, or a function, or if the variable would be set
only in init files, then don’t start the documentation string with
‘*’. See Defining Variables.
- The documentation string for a variable that is a yes-or-no flag should
start with words such as “Non-nil means…”, to make it clear that
all non-
nil
values are equivalent and indicate explicitly what
nil
and non-nil
mean.
- When a function’s documentation string mentions the value of an argument
of the function, use the argument name in capital letters as if it were
a name for that value. Thus, the documentation string of the function
/
refers to its second argument as ‘DIVISOR’, because the
actual argument name is divisor
.
Also use all caps for meta-syntactic variables, such as when you show
the decomposition of a list or vector into subunits, some of which may
vary.
- Do not write key sequences directly in documentation strings. Instead,
use the ‘\\[…]’ construct to stand for them. For example,
instead of writing ‘C-f’, write ‘\\[forward-char]’. When
SXEmacs displays the documentation string, it substitutes whatever key
is currently bound to
forward-char
. This is normally ‘C-f’,
but it may be some other character if the user has moved key bindings.
See Keys in Documentation.
- In documentation strings for a major mode, you will want to refer to the
key bindings of that mode’s local map, rather than global ones.
Therefore, use the construct ‘\\<…>’ once in the
documentation string to specify which key map to use.
Do this before the first use of ‘\\[…]’. The text inside the
‘\\<…>’ should be the name of the variable containing the
local keymap for the major mode.
It is not practical to use ‘\\[…]’ very many times, because
display of the documentation string will become slow. So use this to
describe the most important commands in your major mode, and then use
‘\\{…}’ to display the rest of the mode’s keymap.