@c -*-texinfo-*-
@c This is part of the GNU Emacs Lisp Reference Manual.
@c Copyright (C) 1990, 1991, 1992, 1993, 1995, 1998, 1999
-@c Free Software Foundation, Inc.
+@c Free Software Foundation, Inc.
@c See the file elisp.texi for copying conditions.
@setfilename ../info/tips
@node Tips, GNU Emacs Internals, GPL, Top
If a user option variable records a true-or-false condition, give it a
name that ends in @samp{-flag}.
+@item
+If the purpose of a variable is to store a single function, give it a
+name that ends in @samp{-function}. If the purpose of a variable is
+to store a list of functions (i.e., the variable is a hook), please
+follow the naming conventions for hooks. @xref{Hooks}.
+
@item
@cindex reserved keys
@cindex keys, reserved
Please do not define @kbd{C-c @var{letter}} as a key in your major
-modes. These sequences are reserved for users; they are the
-@strong{only} sequences reserved for users, so do not block them.
+modes. Sequences consisting of @kbd{C-c} and a letter (either upper
+or lower case) are reserved for users; they are the @strong{only}
+sequences reserved for users, so do not block them.
-Instead, define sequences consisting of @kbd{C-c} followed by a control
-character, a digit, or certain punctuation characters. These sequences
-are reserved for major modes.
+Changing all the Emacs major modes to respect this convention was a
+lot of work; abandoning this convention would make that work go to
+waste, and inconvenience users. Please comply with it.
-Changing all the Emacs major modes to follow this convention was a lot
-of work. Abandoning this convention would make that work go to waste,
-and inconvenience users.
+@item
+Sequences consisting of @kbd{C-c} followed by a control character or a
+digit are reserved for major modes.
@item
Sequences consisting of @kbd{C-c} followed by @kbd{@{}, @kbd{@}},
@item
When a package provides a modification of ordinary Emacs behavior, it is
-good to include a command to enable and disable the feature, Provide a
+good to include a command to enable and disable the feature, provide a
command named @code{@var{whatever}-mode} which turns the feature on or
off, and make it autoload (@pxref{Autoload}). Design the package so
that simply loading it has no visible effect---that should not enable
the feature.@footnote{Consider that the package may be loaded
arbitrarily by Custom for instance.} Users will request the feature by
-invoking the command.
+invoking the command. It is a good idea to define this command
+as a minor mode.
+
+@cindex unloading packages
+If loading the file adds functions to hooks, define a function
+@code{@var{feature}-unload-hook}, where @var{feature} is the name of
+the feature the package provides, and make it undo any such changes.
+Using @code{unload-feature} to unload the file will run this function.
+@xref{Unloading}.
@item
It is a bad idea to define aliases for the Emacs primitives. Use the
say which functions are replaced, and how the behavior of the
replacements differs from that of the originals.
+@item
+Avoid using macros that define functions and variables with names that
+are constructed. It is best for maintenance wen the name of the
+function or variable being defined is given explicitly in the source
+code, as the second element of the list---as it is when you use
+@code{defun}, @code{defalias}, @code{defvar} and @code{defopt}.
+
@item
Please keep the names of your Emacs Lisp source files to 13 characters
or less. This way, if the files are compiled, the compiled files' names
@item
@cindex profiling
@cindex timing programs
-@cindex @file{profile.el}
@cindex @file{elp.el}
-Profile your program with the @file{profile} library or the @file{elp}
-library. See the files @file{profile.el} and @file{elp.el} for
-instructions.
+Profile your program with the @file{elp} library. See the file
+@file{elp.el} for instructions.
@item
Use iteration rather than recursion whenever possible.
search functions can be used.
@item
-Certain built-in functions are handled specially in byte-compiled code,
+Certain built-in functions are handled specially in byte-compiled code,
avoiding the need for an ordinary function call. It is a good idea to
use these functions rather than alternatives. To see whether a function
is handled specially by the compiler, examine its @code{byte-compile}
longer the case---documentation strings now take up very little space in
a running Emacs.
+@item
+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 should not be wider than 67 characters
+or it will look bad in the output of @code{apropos}.
+
+You can fill the text if that looks good. However, rather than blindly
+filling the entire documentation string, you can often make it much more
+readable by choosing certain line breaks with care. Use blank lines
+between topics if the documentation string is long.
+
@item
The first line of the documentation string should consist of one or two
complete sentences that stand on their own as a summary. @kbd{M-x
stand on their own, the result looks bad. In particular, start the
first line with a capital letter and end with a period.
-The documentation string is not limited to one line; use as many lines
-as you need to explain the details of how to use the function or
-variable. Please use complete sentences in the additional lines.
+For a function, the first line should briefly answer the question,
+``What does this function do?'' For a variable, the first line should
+briefly answer the question, ``What does this value mean?''
+
+Don't limit the documentation string to one line; use as many lines as
+you need to explain the details of how to use the function or
+variable. Please use complete sentences for the rest of the text too.
+
+@item
+The first line should mention all the important arguments of the
+function, and should mention them in the order that they are written
+in a function call. If the function has many arguments, then it is
+not feasible to mention them all in the first line; in that case, the
+first line should mention the first few arguments, including the most
+important arguments.
@item
For consistency, phrase the verb in the first sentence of a function's
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 each sentence
-has a proper subject.
+is indicative and has a proper subject.
@item
Write documentation strings in the active voice, not the passive, and in
@item
Do not start or end a documentation string with whitespace.
-@item
-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 should not be wider than 67 characters
-or it will look bad in the output of @code{apropos}.
-
-You can fill the text if that looks good. However, rather than blindly
-filling the entire documentation string, you can often make it much more
-readable by choosing certain line breaks with care. Use blank lines
-between topics if the documentation string is long.
-
@item
@strong{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
all non-@code{nil} values are equivalent and indicate explicitly what
@code{nil} and non-@code{nil} mean.
+@item
+The documentation string for a function that is a yes-or-no predicate
+should start with words such as ``Return t if @dots{}'', to indicate
+explicitly what constitutes ``truth''. The word ``return'' avoids
+starting the sentence with lower-case ``t'', which is somewhat
+distracting.
+
@item
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
have the form (KEY . VALUE). Here, KEY is ...
@end example
+@item
+Never change the case of a Lisp symbol when you mention it in a doc
+string. If the symbol's name is @code{foo}, write ``foo'', not
+``Foo'' (which is a different symbol).
+
+This might appear to contradict the policy of writing function
+argument values, but there is no real contradiction; the argument
+@emph{value} is not the same thing as the @emph{symbol} which the
+function uses to hold the value.
+
+If this puts a lower-case letter at the beginning of a sentence
+and that annoys you, rewrite the sentence so that the symbol
+is not at the start of it.
+
@item
If a line in a documentation string begins with an open-parenthesis,
write a backslash before the open-parenthesis, like this:
does not make a hyperlink to the documentation, irrelevant here, of the
function @code{list}.
+Normally, no hyperlink is made for a variable without variable
+documentation. You can force a hyperlink for such variables by
+preceding them with one of the words @samp{variable} or
+@samp{option}.
+
+Hyperlinks for faces are only made if the face name is preceded or
+followed by the word @samp{face}. In that case, only the face
+documentation will be shown, even if the symbol is also defined as a
+variable or as a function.
+
To make a hyperlink to Info documentation, write the name of the Info
node in single quotes, preceded by @samp{info node} or @samp{Info
node}. The Info file name defaults to @samp{emacs}. For example,
@end example
@noindent
-The description should be complete in one line.
+The description should be complete in one line. If the file
+needs a @samp{-*-} specification, put it after @var{description}.
After the copyright notice come several @dfn{header comment} lines,
each beginning with @samp{;; @var{header-name}:}. Here is a table of
text is used by the Finder package, so it should make sense in that
context.
-@item ;;; Documentation
-This has been used in some files in place of @samp{;;; Commentary:},
-but @samp{;;; Commentary:} is preferred.
+@item ;;; Documentation:
+This was used in some files in place of @samp{;;; Commentary:},
+but it is deprecated.
@item ;;; Change Log:
This begins change log information stored in the library file (if you
Its purpose is to enable people to detect truncated versions of the file
from the lack of a footer line.
@end table
+
+@ignore
+ arch-tag: 9ea911c2-6b1d-47dd-88b7-0a94e8b27c2e
+@end ignore