diff options
Diffstat (limited to 'lispref/tips.texi')
| -rw-r--r-- | lispref/tips.texi | 1130 |
1 files changed, 0 insertions, 1130 deletions
diff --git a/lispref/tips.texi b/lispref/tips.texi deleted file mode 100644 index 765a4e2760d..00000000000 --- a/lispref/tips.texi +++ /dev/null @@ -1,1130 +0,0 @@ -@c -*-texinfo-*- -@c This is part of the GNU Emacs Lisp Reference Manual. -@c Copyright (C) 1990, 1991, 1992, 1993, 1995, 1998, 1999, 2001, 2002, -@c 2003, 2004, 2005, 2006, 2007, 2008 Free Software Foundation, Inc. -@c See the file elisp.texi for copying conditions. -@setfilename ../info/tips -@node Tips, GNU Emacs Internals, GPL, Top -@appendix Tips and Conventions -@cindex tips for writing Lisp -@cindex standards of coding style -@cindex 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. - -@menu -* 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. -@end menu - -@node Coding Conventions -@section Emacs Lisp Coding Conventions - -@cindex coding conventions in Emacs Lisp - Here are conventions that you should follow when writing Emacs Lisp -code intended for widespread use: - -@itemize @bullet -@item -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. - -@item -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 programs@footnote{The -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 -@code{copy-list}. 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, -@samp{-}. This will be consistent with Emacs itself and with most Emacs -Lisp programs. - -@item -Put a call to @code{provide} at the end of each separate Lisp file. - -@item -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. - -@item -If one file @var{foo} uses a macro defined in another file @var{bar}, -@var{foo} should contain this expression before the first use of the -macro: - -@example -(eval-when-compile (require '@var{bar})) -@end example - -@noindent -(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 -@var{foo} 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}. - -@item -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. - -@item -When defining a major mode, please follow the major mode -conventions. @xref{Major Mode Conventions}. - -@item -When defining a minor mode, please follow the minor mode -conventions. @xref{Minor Mode Conventions}. - -@item -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}. - -@item -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 unloading packages, preparing for -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. Normally -you should use the standard names instead. The case where an alias -may be useful is where it facilitates backwards compatibility or -portability. - -@item -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. - -@example -(defalias 'gnus-point-at-bol - (if (fboundp 'point-at-bol) - 'point-at-bol - 'line-beginning-position)) -@end example - -@item -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. - -@item -It is likewise a bad idea for one Lisp package to advise a function -in another Lisp package. - -@item -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. - -@item -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. - -@item -Constructs that define a function or variable should be macros, -not functions, and their names should start with @samp{def}. - -@item -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. - -@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 -will be 14 characters or less, which is short enough to fit on all kinds -of Unix systems. - -@item -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. - -@item -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: - -@itemize - -@item -Use coding system @code{emacs-mule}, and specify that for -@code{coding} in the @samp{-*-} line or the local variables list. - -@example -;; XXX.el -*- coding: emacs-mule; -*- -@end example - -@item -Use one of the coding systems based on ISO 2022 (such as -iso-8859-@var{n} and iso-2022-7bit), and specify it with @samp{!} at -the end for @code{coding}. (The @samp{!} turns off any possible -character translation.) - -@example -;; XXX.el -*- coding: iso-latin-2!; -*- -@end example -@end itemize - -@item -Indent each function with @kbd{C-M-q} (@code{indent-sexp}) using the -default indentation parameters. - -@item -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. - -@item -Please put a copyright notice and copying permission notice on the -file if you distribute copies. Use a notice like this one: - -@smallexample -;; 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 -@end 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}. -@end itemize - -@node Key Binding Conventions -@section Key Binding Conventions -@cindex key binding, conventions for - -@itemize @bullet -@item -@cindex mouse-2 -@cindex references, following -Special major modes used for read-only text should usually redefine -@kbd{mouse-2} 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 -@kbd{mouse-1} will follow it also. @xref{Links and Mouse-1}. - -@item -@cindex reserved keys -@cindex 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. - -@item -Function keys @key{F5} through @key{F9} without modifier keys are -also reserved for users to define. - -@item -Applications should not bind mouse events based on button 1 with the -shift key held down. These events include @kbd{S-mouse-1}, -@kbd{M-S-mouse-1}, @kbd{C-S-mouse-1}, and so on. They are reserved for -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{@}}, -@kbd{<}, @kbd{>}, @kbd{:} or @kbd{;} are also reserved for major modes. - -@item -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. - -@item -Do not bind @kbd{C-h} following any prefix character (including -@kbd{C-c}). If you don't bind @kbd{C-h}, it is automatically available -as a help character for listing the subcommands of the prefix character. - -@item -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 -@kbd{@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. - -@item -Anything which acts like a temporary mode or state which the user can -enter and leave should define @kbd{@key{ESC} @key{ESC}} or -@kbd{@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 @kbd{@key{ESC} -@key{ESC}}, since that would preclude recognizing an escape sequence -after @key{ESC}. In these states, you should define @kbd{@key{ESC} -@key{ESC} @key{ESC}} as the way to escape. Otherwise, define -@kbd{@key{ESC} @key{ESC}} instead. -@end itemize - -@node Programming Tips -@section Emacs Programming Tips -@cindex programming conventions - - Following these conventions will make your program fit better -into Emacs when it runs. - -@itemize @bullet -@item -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}. - -@item -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: - -@itemize @bullet -@item -@code{beginning-of-buffer}, @code{end-of-buffer} -@item -@code{replace-string}, @code{replace-regexp} -@item -@code{insert-file}, @code{insert-buffer} -@end 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. - -@item -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). - -@item -The recommended way to show a message in the echo area is with -the @code{message} function, not @code{princ}. @xref{The Echo Area}. - -@item -When you encounter an error condition, call the function @code{error} -(or @code{signal}). The function @code{error} does not return. -@xref{Signaling Errors}. - -Do not use @code{message}, @code{throw}, @code{sleep-for}, -or @code{beep} to report errors. - -@item -An error message should start with a capital letter but should not end -with a period. - -@item -A question asked in the minibuffer with @code{y-or-n-p} or -@code{yes-or-no-p} should start with a capital letter and end with -@samp{? }. - -@item -When you mention a default value in a minibuffer prompt, -put it and the word @samp{default} inside parentheses. -It should look like this: - -@example -Enter the answer (default 42): -@end example - -@item -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: - -@example -(defun foo (pos) - (interactive - (list (if @var{specified} @var{specified-pos}))) - (unless pos (setq pos @var{default-pos})) - ...) -@end example - -@noindent -rather than this: - -@example -(defun foo (pos) - (interactive - (list (if @var{specified} @var{specified-pos} - @var{default-pos}))) - ...) -@end example - -@noindent -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. - -@item -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 -@samp{Operating...done} when they finish. Please keep the style of -these messages uniform: @emph{no} space around the ellipsis, and -@emph{no} period after @samp{done}. - -@item -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 -@code{edit-options} command does: switch to another buffer and let the -user switch back at will. @xref{Recursive Editing}. -@end itemize - -@node Compilation Tips -@section Tips for Making Compiled Code Fast -@cindex execution speed -@cindex speedups - - Here are ways of improving the execution speed of byte-compiled -Lisp programs. - -@itemize @bullet -@item -@cindex profiling -@cindex timing programs -@cindex @file{elp.el} -Profile your program with the @file{elp} library. See the file -@file{elp.el} for instructions. - -@item -@cindex @file{benchmark.el} -@cindex benchmarking -Check the speed of individual Emacs Lisp forms using the -@file{benchmark} library. See the functions @code{benchmark-run} and -@code{benchmark-run-compiled} in @file{benchmark.el}. - -@item -Use iteration rather than recursion whenever possible. -Function calls are slow in Emacs Lisp even when a compiled function -is calling another compiled function. - -@item -Using the primitive list-searching functions @code{memq}, @code{member}, -@code{assq}, 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. - -@item -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 non-@code{nil}, then the function is -handled specially. - -For example, the following input will show you that @code{aref} is -compiled specially (@pxref{Array Functions}): - -@example -@group -(get 'aref 'byte-compile) - @result{} byte-compile-two-args -@end group -@end example - -@item -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}. -@end itemize - -@node Warning Tips -@section Tips for Avoiding Compiler Warnings -@cindex byte compiler warnings, how to avoid - -@itemize @bullet -@item -Try to avoid compiler warnings about undefined free variables, by adding -dummy @code{defvar} definitions for these variables, like this: - -@example -(defvar foo) -@end 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. - -@item -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, - -@example -(eval-when-compile - (require 'foo)) -@end example - -@item -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. - -@item -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. -@end itemize - -@node Documentation Tips -@section Tips for Documentation Strings -@cindex documentation strings, conventions and tips - -@findex 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 -@kbd{M-x checkdoc-minor-mode}. - -@itemize @bullet -@item -Every command, function, or variable intended for users to know about -should have a documentation string. - -@item -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. - -@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 -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. - -@item -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. - -@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 -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 -@code{eval} refers to its second argument as @samp{FORM}, because the -actual argument name is @code{form}: - -@example -Evaluate FORM and return its value. -@end 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: - -@example -The argument TABLE should be an alist whose elements -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 -Do not start or end a documentation string with whitespace. - -@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 -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! - -@anchor{Docstring hyperlinks} -@item -@iftex -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. -@end iftex -@ifnottex -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.) -@end ifnottex - -@cindex 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 -@samp{variable}, @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 - -@example -This function sets the variable `buffer-file-name'. -@end example - -@noindent -then the hyperlink will refer only to the variable documentation of -@code{buffer-file-name}, 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, - -@example -If the argument KIND-OF-RESULT is the symbol `list', -this function returns a list of all the objects -that satisfy the criterion. -@end example - -@noindent -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 (or anchor) in single quotes, preceded by @samp{info node}, -@samp{Info node}, @samp{info anchor} or @samp{Info anchor}. The Info -file name defaults to @samp{emacs}. For example, - -@smallexample -See Info node `Font Lock' and Info node `(elisp)Font Lock Basics'. -@end smallexample - -Finally, to create a hyperlink to URLs, write the URL in single -quotes, preceded by @samp{URL}. For example, - -@smallexample -The home page for the GNU project has more information (see URL -`http://www.gnu.org/'). -@end smallexample - -@item -Don't write key sequences directly in documentation strings. Instead, -use the @samp{\\[@dots{}]} construct to stand for them. For example, -instead of writing @samp{C-f}, write the construct -@samp{\\[forward-char]}. 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}. - -@item -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 @samp{\\[@dots{}]}. The text inside the -@samp{\\<@dots{}>} should be the name of the variable containing the -local keymap for the major mode. - -It is not practical to use @samp{\\[@dots{}]} 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 -@samp{\\@{@dots{}@}} to display the rest of the mode's keymap. - -@item -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 B@.'' -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. - -@item -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. - -@item -If a line in a documentation string begins with an open-parenthesis, -write a backslash before the open-parenthesis, like this: - -@example -The argument FOO can be either a number -\(a buffer position) or a string (a file name). -@end example - -This prevents the open-parenthesis from being treated as the start of a -defun (@pxref{Defuns,, Defuns, emacs, The GNU Emacs Manual}). - -@item -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.'' - -@item -Avoid using the word ``cause'' (or its equivalents) unnecessarily. -Instead of, ``Cause Emacs to display text in boldface,'' write just -``Display text in boldface.'' - -@item -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. - -@item -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: - -@example -In Dired, visit the file or directory named on this line. -@end example - -@item -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{*}. -@xref{Defining Variables}. - -@item -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-@code{nil} values are equivalent and indicate explicitly what -@code{nil} and non-@code{nil} mean. -@end itemize - -@node Comment Tips -@section Tips on Writing Comments -@cindex comments, Lisp convention for - - We recommend these conventions for where to put comments and how to -indent them: - -@table @samp -@item ; -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. - -@smallexample -@group -(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 -@end group -@end smallexample - -@item ;; -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: - -@smallexample -@group -(prog1 (setq auto-fill-function - @dots{} - @dots{} - ;; update mode line - (force-mode-line-update))) -@end group -@end smallexample - -We also normally use two semicolons for comments outside functions. - -@smallexample -@group -;; This Lisp code is run in Emacs -;; when it is to operate as a server -;; for other processes. -@end group -@end 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. - -@item ;;; -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. - -@smallexample -(defun foo (a) -;;; This is no longer necessary. -;;; (force-mode-line-update) - (message "Finished with %s" a)) -@end smallexample - -When commenting out entire functions, use two semicolons. - -@item ;;;; -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: - -@smallexample -;;;; The kill ring -@end smallexample -@end table - -@noindent -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}. - -@node Library Headers -@section Conventional Headers for Emacs Libraries -@cindex header comments -@cindex 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: - -@smallexample -@group -;;; lisp-mnt.el --- minor mode for Emacs Lisp maintainers - -;; Copyright (C) 1992 Free Software Foundation, Inc. -@end group - -;; Author: Eric S. Raymond <esr@@snark.thyrsus.com> -;; Maintainer: Eric S. Raymond <esr@@snark.thyrsus.com> -;; Created: 14 Jul 1992 -;; Version: 1.2 -@group -;; Keywords: docs - -;; This file is part of GNU Emacs. -@dots{} -;; Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, -;; Boston, MA 02110-1301, USA. -@end group -@end smallexample - - The very first line should have this format: - -@example -;;; @var{filename} --- @var{description} -@end example - -@noindent -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}: - -@table @samp -@item 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: - -@smallexample -@group -;; Author: Ashwin Ram <Ram-Ashwin@@cs.yale.edu> -;; Dave Sill <de5@@ornl.gov> -;; Dave Brennan <brennan@@hal.com> -;; Eric Raymond <esr@@snark.thyrsus.com> -@end group -@end smallexample - -@item 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. - -@item Created -This optional line gives the original creation date of the -file. For historical interest only. - -@item Version -If you wish to record version numbers for the individual Lisp program, put -them in this line. - -@item 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). - -@item 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. -@end table - - Just about every Lisp library ought to have the @samp{Author} and -@samp{Keywords} 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: - -@table @samp -@item ;;; Commentary: -This begins introductory comments that explain how the library works. -It should come right after the copying permissions, terminated by a -@samp{Change Log}, @samp{History} or @samp{Code} comment line. This -text is used by the Finder package, so it should make sense in that -context. - -@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 -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}. - -@item ;;; Code: -This begins the actual code of the program. - -@item ;;; @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. -@end table - -@ignore - arch-tag: 9ea911c2-6b1d-47dd-88b7-0a94e8b27c2e -@end ignore |