[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Emacs-diffs] Changes to tips.texi
|
From: |
Glenn Morris |
|
Subject: |
[Emacs-diffs] Changes to tips.texi |
|
Date: |
Thu, 06 Sep 2007 04:23:48 +0000 |
CVSROOT: /sources/emacs
Module name: emacs
Changes by: Glenn Morris <gm> 07/09/06 04:23:48
Index: tips.texi
===================================================================
RCS file: tips.texi
diff -N tips.texi
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ tips.texi 6 Sep 2007 04:23:48 -0000 1.1
@@ -0,0 +1,1130 @@
address@hidden -*-texinfo-*-
address@hidden This is part of the GNU Emacs Lisp Reference Manual.
address@hidden Copyright (C) 1990, 1991, 1992, 1993, 1995, 1998, 1999, 2001,
2002,
address@hidden 2003, 2004, 2005, 2006, 2007 Free Software Foundation, Inc.
address@hidden See the file elisp.texi for copying conditions.
address@hidden ../info/tips
address@hidden Tips, GNU Emacs Internals, GPL, Top
address@hidden Tips and Conventions
address@hidden tips for writing Lisp
address@hidden standards of coding style
address@hidden coding standards
+
+ This chapter describes no additional features of Emacs Lisp. Instead
+it gives advice on making effective use of the features described in the
+previous chapters, and describes conventions Emacs Lisp programmers
+should follow.
+
+ You can automatically check some of the conventions described below by
+running the command @kbd{M-x checkdoc RET} when visiting a Lisp file.
+It cannot check all of the conventions, and not all the warnings it
+gives necessarily correspond to problems, but it is worth examining them
+all.
+
address@hidden
+* Coding Conventions:: Conventions for clean and robust programs.
+* Key Binding Conventions:: Which keys should be bound by which programs.
+* Programming Tips:: Making Emacs code fit smoothly in Emacs.
+* Compilation Tips:: Making compiled code run fast.
+* Warning Tips:: Turning off compiler warnings.
+* Documentation Tips:: Writing readable documentation strings.
+* Comment Tips:: Conventions for writing comments.
+* Library Headers:: Standard headers for library packages.
address@hidden menu
+
address@hidden Coding Conventions
address@hidden Emacs Lisp Coding Conventions
+
address@hidden coding conventions in Emacs Lisp
+ Here are conventions that you should follow when writing Emacs Lisp
+code intended for widespread use:
+
address@hidden @bullet
address@hidden
+Simply loading the package should not change Emacs's editing behavior.
+Include a command or commands to enable and disable the feature,
+or to invoke it.
+
+This convention is mandatory for any file that includes custom
+definitions. If fixing such a file to follow this convention requires
+an incompatible change, go ahead and make the incompatible change;
+don't postpone it.
+
address@hidden
+Since all global variables share the same name space, and all
+functions share another name space, you should choose a short word to
+distinguish your program from other Lisp address@hidden
+benefits of a Common Lisp-style package system are considered not to
+outweigh the costs.}. Then take care to begin the names of all global
+variables, constants, and functions in your program with the chosen
+prefix. This helps avoid name conflicts.
+
+Occasionally, for a command name intended for users to use, it is more
+convenient if some words come before the package's name prefix. And
+constructs that define functions, variables, etc., work better if they
+start with @samp{defun} or @samp{defvar}, so put the name prefix later
+on in the name.
+
+This recommendation applies even to names for traditional Lisp
+primitives that are not primitives in Emacs Lisp---such as
address@hidden Believe it or not, there is more than one plausible
+way to define @code{copy-list}. Play it safe; append your name prefix
+to produce a name like @code{foo-copy-list} or @code{mylib-copy-list}
+instead.
+
+If you write a function that you think ought to be added to Emacs under
+a certain name, such as @code{twiddle-files}, don't call it by that name
+in your program. Call it @code{mylib-twiddle-files} in your program,
+and send mail to @samp{bug-gnu-emacs@@gnu.org} suggesting we add
+it to Emacs. If and when we do, we can change the name easily enough.
+
+If one prefix is insufficient, your package can use two or three
+alternative common prefixes, so long as they make sense.
+
+Separate the prefix from the rest of the symbol name with a hyphen,
address@hidden This will be consistent with Emacs itself and with most Emacs
+Lisp programs.
+
address@hidden
+Put a call to @code{provide} at the end of each separate Lisp file.
+
address@hidden
+If a file requires certain other Lisp programs to be loaded
+beforehand, then the comments at the beginning of the file should say
+so. Also, use @code{require} to make sure they are loaded.
+
address@hidden
+If one file @var{foo} uses a macro defined in another file @var{bar},
address@hidden should contain this expression before the first use of the
+macro:
+
address@hidden
+(eval-when-compile (require '@var{bar}))
address@hidden example
+
address@hidden
+(And the library @var{bar} should contain @code{(provide '@var{bar})},
+to make the @code{require} work.) This will cause @var{bar} to be
+loaded when you byte-compile @var{foo}. Otherwise, you risk compiling
address@hidden without the necessary macro loaded, and that would produce
+compiled code that won't work right. @xref{Compiling Macros}.
+
+Using @code{eval-when-compile} avoids loading @var{bar} when
+the compiled version of @var{foo} is @emph{used}.
+
address@hidden
+Please don't require the @code{cl} package of Common Lisp extensions at
+run time. Use of this package is optional, and it is not part of the
+standard Emacs namespace. If your package loads @code{cl} at run time,
+that could cause name clashes for users who don't use that package.
+
+However, there is no problem with using the @code{cl} package at
+compile time, with @code{(eval-when-compile (require 'cl))}. That's
+sufficient for using the macros in the @code{cl} package, because the
+compiler expands them before generating the byte-code.
+
address@hidden
+When defining a major mode, please follow the major mode
+conventions. @xref{Major Mode Conventions}.
+
address@hidden
+When defining a minor mode, please follow the minor mode
+conventions. @xref{Minor Mode Conventions}.
+
address@hidden
+If the purpose of a function is to tell you whether a certain condition
+is true or false, give the function a name that ends in @samp{p}. If
+the name is one word, add just @samp{p}; if the name is multiple words,
+add @samp{-p}. Examples are @code{framep} and @code{frame-live-p}.
+
address@hidden
+If a user option variable records a true-or-false condition, give it a
+name that ends in @samp{-flag}.
+
address@hidden
+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}.
+
address@hidden
address@hidden unloading packages, preparing for
+If loading the file adds functions to hooks, define a function
address@hidden@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.
address@hidden
+
address@hidden
+It is a bad idea to define aliases for the Emacs primitives. Normally
+you should use the standard names instead. The case where an alias
+may be useful is where it facilitates backwards compatibility or
+portability.
+
address@hidden
+If a package needs to define an alias or a new function for
+compatibility with some other version of Emacs, name it with the package
+prefix, not with the raw name with which it occurs in the other version.
+Here is an example from Gnus, which provides many examples of such
+compatibility issues.
+
address@hidden
+(defalias 'gnus-point-at-bol
+ (if (fboundp 'point-at-bol)
+ 'point-at-bol
+ 'line-beginning-position))
address@hidden example
+
address@hidden
+Redefining (or advising) an Emacs primitive is a bad idea. It may do
+the right thing for a particular program, but there is no telling what
+other programs might break as a result. In any case, it is a problem
+for debugging, because the advised function doesn't do what its source
+code says it does. If the programmer investigating the problem is
+unaware that there is advice on the function, the experience can be
+very frustrating.
+
+We hope to remove all the places in Emacs that advise primitives.
+In the mean time, please don't add any more.
+
address@hidden
+It is likewise a bad idea for one Lisp package to advise a function
+in another Lisp package.
+
address@hidden
+Likewise, avoid using @code{eval-after-load} (@pxref{Hooks for
+Loading}) in libraries and packages. This feature is meant for
+personal customizations; using it in a Lisp program is unclean,
+because it modifies the behavior of another Lisp file in a way that's
+not visible in that file. This is an obstacle for debugging, much
+like advising a function in the other package.
+
address@hidden
+If a file does replace any of the functions or library programs of
+standard Emacs, prominent comments at the beginning of the file should
+say which functions are replaced, and how the behavior of the
+replacements differs from that of the originals.
+
address@hidden
+Constructs that define a function or variable should be macros,
+not functions, and their names should start with @samp{def}.
+
address@hidden
+A macro that defines a function or variable should have a name that
+starts with @samp{define-}. The macro should receive the name to be
+defined as the first argument. That will help various tools find the
+definition automatically. Avoid constructing the names in the macro
+itself, since that would confuse these tools.
+
address@hidden
+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
+will be 14 characters or less, which is short enough to fit on all kinds
+of Unix systems.
+
address@hidden
+In some other systems there is a convention of choosing variable names
+that begin and end with @samp{*}. We don't use that convention in Emacs
+Lisp, so please don't use it in your programs. (Emacs uses such names
+only for special-purpose buffers.) The users will find Emacs more
+coherent if all libraries use the same conventions.
+
address@hidden
+If your program contains non-ASCII characters in string or character
+constants, you should make sure Emacs always decodes these characters
+the same way, regardless of the user's settings. There are two ways
+to do that:
+
address@hidden -
address@hidden
+Use coding system @code{emacs-mule}, and specify that for
address@hidden in the @samp{-*-} line or the local variables list.
+
address@hidden
+;; XXX.el -*- coding: emacs-mule; -*-
address@hidden example
+
address@hidden
+Use one of the coding systems based on ISO 2022 (such as
address@hidden and iso-2022-7bit), and specify it with @samp{!} at
+the end for @code{coding}. (The @samp{!} turns off any possible
+character translation.)
+
address@hidden
+;; XXX.el -*- coding: iso-latin-2!; -*-
address@hidden example
address@hidden itemize
+
address@hidden
+Indent each function with @kbd{C-M-q} (@code{indent-sexp}) using the
+default indentation parameters.
+
address@hidden
+Don't make a habit of putting close-parentheses on lines by themselves;
+Lisp programmers find this disconcerting. Once in a while, when there
+is a sequence of many consecutive close-parentheses, it may make sense
+to split the sequence in one or two significant places.
+
address@hidden
+Please put a copyright notice and copying permission notice on the
+file if you distribute copies. Use a notice like this one:
+
address@hidden
+;; Copyright (C) @var{year} @var{name}
+
+;; This program is free software; you can redistribute it and/or
+;; modify it under the terms of the GNU General Public License as
+;; published by the Free Software Foundation; either version 3 of
+;; the License, or (at your option) any later version.
+
+;; This program is distributed in the hope that it will be
+;; useful, but WITHOUT ANY WARRANTY; without even the implied
+;; warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR
+;; PURPOSE. See the GNU General Public License for more details.
+
+;; You should have received a copy of the GNU General Public
+;; License along with this program; if not, write to the Free
+;; Software Foundation, Inc., 51 Franklin Street, Fifth Floor,
+;; Boston, MA 02110-1301 USA
address@hidden smallexample
+
+If you have signed papers to assign the copyright to the Foundation,
+then use @samp{Free Software Foundation, Inc.} as @var{name}.
+Otherwise, use your name. See also @xref{Library Headers}.
address@hidden itemize
+
address@hidden Key Binding Conventions
address@hidden Key Binding Conventions
address@hidden key binding, conventions for
+
address@hidden @bullet
address@hidden
address@hidden mouse-2
address@hidden references, following
+Special major modes used for read-only text should usually redefine
address@hidden and @key{RET} to trace some sort of reference in the text.
+Modes such as Dired, Info, Compilation, and Occur redefine it in this
+way.
+
+In addition, they should mark the text as a kind of ``link'' so that
address@hidden will follow it also. @xref{Links and Mouse-1}.
+
address@hidden
address@hidden reserved keys
address@hidden keys, reserved
+Please do not define @kbd{C-c @var{letter}} as a key in Lisp programs.
+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.
+
+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.
+
address@hidden
+Function keys @key{F5} through @key{F9} without modifier keys are
+also reserved for users to define.
+
address@hidden
+Applications should not bind mouse events based on button 1 with the
+shift key held down. These events include @kbd{S-mouse-1},
address@hidden, @kbd{C-S-mouse-1}, and so on. They are reserved for
+users.
+
address@hidden
+Sequences consisting of @kbd{C-c} followed by a control character or a
+digit are reserved for major modes.
+
address@hidden
+Sequences consisting of @kbd{C-c} followed by @address@hidden, @address@hidden,
address@hidden<}, @kbd{>}, @kbd{:} or @kbd{;} are also reserved for major modes.
+
address@hidden
+Sequences consisting of @kbd{C-c} followed by any other punctuation
+character are allocated for minor modes. Using them in a major mode is
+not absolutely prohibited, but if you do that, the major mode binding
+may be shadowed from time to time by minor modes.
+
address@hidden
+Do not bind @kbd{C-h} following any prefix character (including
address@hidden). If you don't bind @kbd{C-h}, it is automatically available
+as a help character for listing the subcommands of the prefix character.
+
address@hidden
+Do not bind a key sequence ending in @key{ESC} except following
+another @key{ESC}. (That is, it is OK to bind a sequence ending in
address@hidden@key{ESC} @key{ESC}}.)
+
+The reason for this rule is that a non-prefix binding for @key{ESC} in
+any context prevents recognition of escape sequences as function keys in
+that context.
+
address@hidden
+Anything which acts like a temporary mode or state which the user can
+enter and leave should define @address@hidden @key{ESC}} or
address@hidden@key{ESC} @key{ESC} @key{ESC}} as a way to escape.
+
+For a state which accepts ordinary Emacs commands, or more generally any
+kind of state in which @key{ESC} followed by a function key or arrow key
+is potentially meaningful, then you must not define @address@hidden
address@hidden, since that would preclude recognizing an escape sequence
+after @key{ESC}. In these states, you should define @address@hidden
address@hidden @key{ESC}} as the way to escape. Otherwise, define
address@hidden@key{ESC} @key{ESC}} instead.
address@hidden itemize
+
address@hidden Programming Tips
address@hidden Emacs Programming Tips
address@hidden programming conventions
+
+ Following these conventions will make your program fit better
+into Emacs when it runs.
+
address@hidden @bullet
address@hidden
+Don't use @code{next-line} or @code{previous-line} in programs; nearly
+always, @code{forward-line} is more convenient as well as more
+predictable and robust. @xref{Text Lines}.
+
address@hidden
+Don't call functions that set the mark, unless setting the mark is one
+of the intended features of your program. The mark is a user-level
+feature, so it is incorrect to change the mark except to supply a value
+for the user's benefit. @xref{The Mark}.
+
+In particular, don't use any of these functions:
+
address@hidden @bullet
address@hidden
address@hidden, @code{end-of-buffer}
address@hidden
address@hidden, @code{replace-regexp}
address@hidden
address@hidden, @code{insert-buffer}
address@hidden itemize
+
+If you just want to move point, or replace a certain string, or insert
+a file or buffer's contents, without any of the other features
+intended for interactive users, you can replace these functions with
+one or two lines of simple Lisp code.
+
address@hidden
+Use lists rather than vectors, except when there is a particular reason
+to use a vector. Lisp has more facilities for manipulating lists than
+for vectors, and working with lists is usually more convenient.
+
+Vectors are advantageous for tables that are substantial in size and are
+accessed in random order (not searched front to back), provided there is
+no need to insert or delete elements (only lists allow that).
+
address@hidden
+The recommended way to show a message in the echo area is with
+the @code{message} function, not @code{princ}. @xref{The Echo Area}.
+
address@hidden
+When you encounter an error condition, call the function @code{error}
+(or @code{signal}). The function @code{error} does not return.
address@hidden Errors}.
+
+Do not use @code{message}, @code{throw}, @code{sleep-for},
+or @code{beep} to report errors.
+
address@hidden
+An error message should start with a capital letter but should not end
+with a period.
+
address@hidden
+A question asked in the minibuffer with @code{y-or-n-p} or
address@hidden should start with a capital letter and end with
address@hidden }.
+
address@hidden
+When you mention a default value in a minibuffer prompt,
+put it and the word @samp{default} inside parentheses.
+It should look like this:
+
address@hidden
+Enter the answer (default 42):
address@hidden example
+
address@hidden
+In @code{interactive}, if you use a Lisp expression to produce a list
+of arguments, don't try to provide the ``correct'' default values for
+region or position arguments. Instead, provide @code{nil} for those
+arguments if they were not specified, and have the function body
+compute the default value when the argument is @code{nil}. For
+instance, write this:
+
address@hidden
+(defun foo (pos)
+ (interactive
+ (list (if @var{specified} @var{specified-pos})))
+ (unless pos (setq pos @var{default-pos}))
+ ...)
address@hidden example
+
address@hidden
+rather than this:
+
address@hidden
+(defun foo (pos)
+ (interactive
+ (list (if @var{specified} @var{specified-pos}
+ @var{default-pos})))
+ ...)
address@hidden example
+
address@hidden
+This is so that repetition of the command will recompute
+these defaults based on the current circumstances.
+
+You do not need to take such precautions when you use interactive
+specs @samp{d}, @samp{m} and @samp{r}, because they make special
+arrangements to recompute the argument values on repetition of the
+command.
+
address@hidden
+Many commands that take a long time to execute display a message that
+says something like @samp{Operating...} when they start, and change it to
address@hidden when they finish. Please keep the style of
+these messages uniform: @emph{no} space around the ellipsis, and
address@hidden period after @samp{done}.
+
address@hidden
+Try to avoid using recursive edits. Instead, do what the Rmail @kbd{e}
+command does: use a new local keymap that contains one command defined
+to switch back to the old local keymap. Or do what the
address@hidden command does: switch to another buffer and let the
+user switch back at will. @xref{Recursive Editing}.
address@hidden itemize
+
address@hidden Compilation Tips
address@hidden Tips for Making Compiled Code Fast
address@hidden execution speed
address@hidden speedups
+
+ Here are ways of improving the execution speed of byte-compiled
+Lisp programs.
+
address@hidden @bullet
address@hidden
address@hidden profiling
address@hidden timing programs
address@hidden @file{elp.el}
+Profile your program with the @file{elp} library. See the file
address@hidden for instructions.
+
address@hidden
address@hidden @file{benchmark.el}
address@hidden benchmarking
+Check the speed of individual Emacs Lisp forms using the
address@hidden library. See the functions @code{benchmark-run} and
address@hidden in @file{benchmark.el}.
+
address@hidden
+Use iteration rather than recursion whenever possible.
+Function calls are slow in Emacs Lisp even when a compiled function
+is calling another compiled function.
+
address@hidden
+Using the primitive list-searching functions @code{memq}, @code{member},
address@hidden, or @code{assoc} is even faster than explicit iteration. It
+can be worth rearranging a data structure so that one of these primitive
+search functions can be used.
+
address@hidden
+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}
+property. If the property is address@hidden, then the function is
+handled specially.
+
+For example, the following input will show you that @code{aref} is
+compiled specially (@pxref{Array Functions}):
+
address@hidden
address@hidden
+(get 'aref 'byte-compile)
+ @result{} byte-compile-two-args
address@hidden group
address@hidden example
+
address@hidden
+If calling a small function accounts for a substantial part of your
+program's running time, make the function inline. This eliminates
+the function call overhead. Since making a function inline reduces
+the flexibility of changing the program, don't do it unless it gives
+a noticeable speedup in something slow enough that users care about
+the speed. @xref{Inline Functions}.
address@hidden itemize
+
address@hidden Warning Tips
address@hidden Tips for Avoiding Compiler Warnings
address@hidden byte compiler warnings, how to avoid
+
address@hidden @bullet
address@hidden
+Try to avoid compiler warnings about undefined free variables, by adding
+dummy @code{defvar} definitions for these variables, like this:
+
address@hidden
+(defvar foo)
address@hidden example
+
+Such a definition has no effect except to tell the compiler
+not to warn about uses of the variable @code{foo} in this file.
+
address@hidden
+If you use many functions and variables from a certain file, you can
+add a @code{require} for that package to avoid compilation warnings
+for them. For instance,
+
address@hidden
+(eval-when-compile
+ (require 'foo))
address@hidden example
+
address@hidden
+If you bind a variable in one function, and use it or set it in
+another function, the compiler warns about the latter function unless
+the variable has a definition. But adding a definition would be
+unclean if the variable has a short name, since Lisp packages should
+not define short variable names. The right thing to do is to rename
+this variable to start with the name prefix used for the other
+functions and variables in your package.
+
address@hidden
+The last resort for avoiding a warning, when you want to do something
+that usually is a mistake but it's not a mistake in this one case,
+is to put a call to @code{with-no-warnings} around it.
address@hidden itemize
+
address@hidden Documentation Tips
address@hidden Tips for Documentation Strings
address@hidden documentation strings, conventions and tips
+
address@hidden checkdoc-minor-mode
+ Here are some tips and conventions for the writing of documentation
+strings. You can check many of these conventions by running the command
address@hidden checkdoc-minor-mode}.
+
address@hidden @bullet
address@hidden
+Every command, function, or variable intended for users to know about
+should have a documentation string.
+
address@hidden
+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---documentation strings now take up very little space in
+a running Emacs.
+
address@hidden
+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.
+
address@hidden
+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
+apropos} displays just the first line, and if that line's contents don't
+stand on their own, the result looks bad. In particular, start the
+first line with a capital letter and end with a period.
+
+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.
+
address@hidden
+When the user tries to use a disabled command, Emacs displays just the
+first paragraph of its documentation string---everything through the
+first blank line. If you wish, you can choose which information to
+include before the first blank line so as to make this display useful.
+
address@hidden
+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.
+
address@hidden
+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
address@hidden refers to its second argument as @samp{FORM}, because the
+actual argument name is @code{form}:
+
address@hidden
+Evaluate FORM and return its value.
address@hidden example
+
+Also write metasyntactic variables in capital letters, such as when you
+show the decomposition of a list or vector into subunits, some of which
+may vary. @samp{KEY} and @samp{VALUE} in the following example
+illustrate this practice:
+
address@hidden
+The argument TABLE should be an alist whose elements
+have the form (KEY . VALUE). Here, KEY is ...
address@hidden example
+
address@hidden
+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
address@hidden 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.
+
address@hidden
+Do not start or end a documentation string with whitespace.
+
address@hidden
address@hidden 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!
+
address@hidden hyperlinks}
address@hidden
address@hidden
+When a documentation string refers to a Lisp symbol, write it as it
+would be printed (which usually means in lower case), with single-quotes
+around it. For example: @samp{`lambda'}. There are two exceptions:
+write @code{t} and @code{nil} without single-quotes.
address@hidden iftex
address@hidden
+When a documentation string refers to a Lisp symbol, write it as it
+would be printed (which usually means in lower case), with single-quotes
+around it. For example: @samp{lambda}. There are two exceptions: write
+t and nil without single-quotes. (In this manual, we use a different
+convention, with single-quotes for all symbols.)
address@hidden ifnottex
+
address@hidden hyperlinks in documentation strings
+Help mode automatically creates a hyperlink when a documentation string
+uses a symbol name inside single quotes, if the symbol has either a
+function or a variable definition. You do not need to do anything
+special to make use of this feature. However, when a symbol has both a
+function definition and a variable definition, and you want to refer to
+just one of them, you can specify which one by writing one of the words
address@hidden, @samp{option}, @samp{function}, or @samp{command},
+immediately before the symbol name. (Case makes no difference in
+recognizing these indicator words.) For example, if you write
+
address@hidden
+This function sets the variable `buffer-file-name'.
address@hidden example
+
address@hidden
+then the hyperlink will refer only to the variable documentation of
address@hidden, and not to its function documentation.
+
+If a symbol has a function definition and/or a variable definition, but
+those are irrelevant to the use of the symbol that you are documenting,
+you can write the words @samp{symbol} or @samp{program} before the
+symbol name to prevent making any hyperlink. For example,
+
address@hidden
+If the argument KIND-OF-RESULT is the symbol `list',
+this function returns a list of all the objects
+that satisfy the criterion.
address@hidden example
+
address@hidden
+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
address@hidden
+
+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 (or anchor) in single quotes, preceded by @samp{info node},
address@hidden node}, @samp{info anchor} or @samp{Info anchor}. The Info
+file name defaults to @samp{emacs}. For example,
+
address@hidden
+See Info node `Font Lock' and Info node `(elisp)Font Lock Basics'.
address@hidden smallexample
+
+Finally, to create a hyperlink to URLs, write the URL in single
+quotes, preceded by @samp{URL}. For example,
+
address@hidden
+The home page for the GNU project has more information (see URL
+`http://www.gnu.org/').
address@hidden smallexample
+
address@hidden
+Don't write key sequences directly in documentation strings. Instead,
+use the @address@hidden construct to stand for them. For example,
+instead of writing @samp{C-f}, write the construct
address@hidden When Emacs displays the documentation string,
+it substitutes whatever key is currently bound to @code{forward-char}.
+(This is normally @samp{C-f}, but it may be some other character if the
+user has moved key bindings.) @xref{Keys in Documentation}.
+
address@hidden
+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 @samp{\\<@dots{}>} once in the
+documentation string to specify which key map to use. Do this before
+the first use of @address@hidden The text inside the
address@hidden<@dots{}>} should be the name of the variable containing the
+local keymap for the major mode.
+
+It is not practical to use @address@hidden 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
address@hidden@address@hidden@}} to display the rest of the mode's keymap.
+
address@hidden
+For consistency, phrase the verb in the first sentence of a function's
+documentation string as an imperative---for instance, use ``Return the
+cons of A and B.'' in preference to ``Returns the cons of A and
address@hidden''
+Usually it looks good to do likewise for the rest of the first
+paragraph. Subsequent paragraphs usually look better if each sentence
+is indicative and has a proper subject.
+
address@hidden
+The documentation string for a function that is a yes-or-no predicate
+should start with words such as ``Return t if,'' to indicate
+explicitly what constitutes ``truth.'' The word ``return'' avoids
+starting the sentence with lower-case ``t,'' which could be somewhat
+distracting.
+
address@hidden
+If a line in a documentation string begins with an open-parenthesis,
+write a backslash before the open-parenthesis, like this:
+
address@hidden
+The argument FOO can be either a number
+\(a buffer position) or a string (a file name).
address@hidden example
+
+This prevents the open-parenthesis from being treated as the start of a
+defun (@pxref{Defuns,, Defuns, emacs, The GNU Emacs Manual}).
+
address@hidden
+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.''
+
address@hidden
+Avoid using the word ``cause'' (or its equivalents) unnecessarily.
+Instead of, ``Cause Emacs to display text in boldface,'' write just
+``Display text in boldface.''
+
address@hidden
+Avoid using ``iff'' (a mathematics term meaning ``if and only if''),
+since many people are unfamiliar with it and mistake it for a typo. In
+most cases, the meaning is clear with just ``if''. Otherwise, try to
+find an alternate phrasing that conveys the meaning.
+
address@hidden
+When a command is meaningful only in a certain mode or situation,
+do mention that in the documentation string. For example,
+the documentation of @code{dired-find-file} is:
+
address@hidden
+In Dired, visit the file or directory named on this line.
address@hidden example
+
address@hidden
+When you define a variable that users ought to set interactively, you
+normally should use @code{defcustom}. However, if for some reason you
+use @code{defvar} instead, start the doc string with a @samp{*}.
address@hidden Variables}.
+
address@hidden
+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 address@hidden values are equivalent and indicate explicitly what
address@hidden and address@hidden mean.
address@hidden itemize
+
address@hidden Comment Tips
address@hidden Tips on Writing Comments
address@hidden comments, Lisp convention for
+
+ We recommend these conventions for where to put comments and how to
+indent them:
+
address@hidden @samp
address@hidden ;
+Comments that start with a single semicolon, @samp{;}, should all be
+aligned to the same column on the right of the source code. Such
+comments usually explain how the code on the same line does its job. In
+Lisp mode and related modes, the @kbd{M-;} (@code{indent-for-comment})
+command automatically inserts such a @samp{;} in the right place, or
+aligns such a comment if it is already present.
+
+This and following examples are taken from the Emacs sources.
+
address@hidden
address@hidden
+(setq base-version-list ; there was a base
+ (assoc (substring fn 0 start-vn) ; version to which
+ file-version-assoc-list)) ; this looks like
+ ; a subversion
address@hidden group
address@hidden smallexample
+
address@hidden ;;
+Comments that start with two semicolons, @samp{;;}, should be aligned to
+the same level of indentation as the code. Such comments usually
+describe the purpose of the following lines or the state of the program
+at that point. For example:
+
address@hidden
address@hidden
+(prog1 (setq auto-fill-function
+ @dots{}
+ @dots{}
+ ;; update mode line
+ (force-mode-line-update)))
address@hidden group
address@hidden smallexample
+
+We also normally use two semicolons for comments outside functions.
+
address@hidden
address@hidden
+;; This Lisp code is run in Emacs
+;; when it is to operate as a server
+;; for other processes.
address@hidden group
address@hidden smallexample
+
+Every function that has no documentation string (presumably one that is
+used only internally within the package it belongs to), should instead
+have a two-semicolon comment right before the function, explaining what
+the function does and how to call it properly. Explain precisely what
+each argument means and how the function interprets its possible values.
+
address@hidden ;;;
+Comments that start with three semicolons, @samp{;;;}, should start at
+the left margin. These are used, occasionally, for comments within
+functions that should start at the margin. We also use them sometimes
+for comments that are between functions---whether to use two or three
+semicolons depends on whether the comment should be considered a
+``heading'' by Outline minor mode. By default, comments starting with
+at least three semicolons (followed by a single space and a
+non-whitespace character) are considered headings, comments starting
+with two or less are not.
+
+Another use for triple-semicolon comments is for commenting out lines
+within a function. We use three semicolons for this precisely so that
+they remain at the left margin. By default, Outline minor mode does
+not consider a comment to be a heading (even if it starts with at
+least three semicolons) if the semicolons are followed by at least two
+spaces. Thus, if you add an introductory comment to the commented out
+code, make sure to indent it by at least two spaces after the three
+semicolons.
+
address@hidden
+(defun foo (a)
+;;; This is no longer necessary.
+;;; (force-mode-line-update)
+ (message "Finished with %s" a))
address@hidden smallexample
+
+When commenting out entire functions, use two semicolons.
+
address@hidden ;;;;
+Comments that start with four semicolons, @samp{;;;;}, should be aligned
+to the left margin and are used for headings of major sections of a
+program. For example:
+
address@hidden
+;;;; The kill ring
address@hidden smallexample
address@hidden table
+
address@hidden
+The indentation commands of the Lisp modes in Emacs, such as @kbd{M-;}
+(@code{indent-for-comment}) and @key{TAB} (@code{lisp-indent-line}),
+automatically indent comments according to these conventions,
+depending on the number of semicolons. @xref{Comments,,
+Manipulating Comments, emacs, The GNU Emacs Manual}.
+
address@hidden Library Headers
address@hidden Conventional Headers for Emacs Libraries
address@hidden header comments
address@hidden library header comments
+
+ Emacs has conventions for using special comments in Lisp libraries
+to divide them into sections and give information such as who wrote
+them. This section explains these conventions.
+
+ We'll start with an example, a package that is included in the Emacs
+distribution.
+
+ Parts of this example reflect its status as part of Emacs; for
+example, the copyright notice lists the Free Software Foundation as the
+copyright holder, and the copying permission says the file is part of
+Emacs. When you write a package and post it, the copyright holder would
+be you (unless your employer claims to own it instead), and you should
+get the suggested copying permission from the end of the GNU General
+Public License itself. Don't say your file is part of Emacs
+if we haven't installed it in Emacs yet!
+
+ With that warning out of the way, on to the example:
+
address@hidden
address@hidden
+;;; lisp-mnt.el --- minor mode for Emacs Lisp maintainers
+
+;; Copyright (C) 1992 Free Software Foundation, Inc.
address@hidden group
+
+;; Author: Eric S. Raymond <esr@@snark.thyrsus.com>
+;; Maintainer: Eric S. Raymond <esr@@snark.thyrsus.com>
+;; Created: 14 Jul 1992
+;; Version: 1.2
address@hidden
+;; Keywords: docs
+
+;; This file is part of GNU Emacs.
address@hidden
+;; Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor,
+;; Boston, MA 02110-1301, USA.
address@hidden group
address@hidden smallexample
+
+ The very first line should have this format:
+
address@hidden
+;;; @var{filename} --- @var{description}
address@hidden example
+
address@hidden
+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
+the conventional possibilities for @var{header-name}:
+
address@hidden @samp
address@hidden Author
+This line states the name and net address of at least the principal
+author of the library.
+
+If there are multiple authors, you can list them on continuation lines
+led by @code{;;} and a tab character, like this:
+
address@hidden
address@hidden
+;; Author: Ashwin Ram <Ram-Ashwin@@cs.yale.edu>
+;; Dave Sill <de5@@ornl.gov>
+;; Dave Brennan <brennan@@hal.com>
+;; Eric Raymond <esr@@snark.thyrsus.com>
address@hidden group
address@hidden smallexample
+
address@hidden Maintainer
+This line should contain a single name/address as in the Author line, or
+an address only, or the string @samp{FSF}. If there is no maintainer
+line, the person(s) in the Author field are presumed to be the
+maintainers. The example above is mildly bogus because the maintainer
+line is redundant.
+
+The idea behind the @samp{Author} and @samp{Maintainer} lines is to make
+possible a Lisp function to ``send mail to the maintainer'' without
+having to mine the name out by hand.
+
+Be sure to surround the network address with @samp{<@dots{}>} if
+you include the person's full name as well as the network address.
+
address@hidden Created
+This optional line gives the original creation date of the
+file. For historical interest only.
+
address@hidden Version
+If you wish to record version numbers for the individual Lisp program, put
+them in this line.
+
address@hidden Adapted-By
+In this header line, place the name of the person who adapted the
+library for installation (to make it fit the style conventions, for
+example).
+
address@hidden Keywords
+This line lists keywords for the @code{finder-by-keyword} help command.
+Please use that command to see a list of the meaningful keywords.
+
+This field is important; it's how people will find your package when
+they're looking for things by topic area. To separate the keywords, you
+can use spaces, commas, or both.
address@hidden table
+
+ Just about every Lisp library ought to have the @samp{Author} and
address@hidden header comment lines. Use the others if they are
+appropriate. You can also put in header lines with other header
+names---they have no standard meanings, so they can't do any harm.
+
+ We use additional stylized comments to subdivide the contents of the
+library file. These should be separated by blank lines from anything
+else. Here is a table of them:
+
address@hidden @samp
address@hidden ;;; Commentary:
+This begins introductory comments that explain how the library works.
+It should come right after the copying permissions, terminated by a
address@hidden Log}, @samp{History} or @samp{Code} comment line. This
+text is used by the Finder package, so it should make sense in that
+context.
+
address@hidden ;;; Documentation:
+This was used in some files in place of @samp{;;; Commentary:},
+but it is deprecated.
+
address@hidden ;;; Change Log:
+This begins change log information stored in the library file (if you
+store the change history there). For Lisp files distributed with Emacs,
+the change history is kept in the file @file{ChangeLog} and not in the
+source file at all; these files generally do not have a @samp{;;; Change
+Log:} line. @samp{History} is an alternative to @samp{Change Log}.
+
address@hidden ;;; Code:
+This begins the actual code of the program.
+
address@hidden ;;; @var{filename} ends here
+This is the @dfn{footer line}; it appears at the very end of the file.
+Its purpose is to enable people to detect truncated versions of the file
+from the lack of a footer line.
address@hidden table
+
address@hidden
+ arch-tag: 9ea911c2-6b1d-47dd-88b7-0a94e8b27c2e
address@hidden ignore