2 @c This is part of the GNU Emacs Lisp Reference Manual.
3 @c Copyright (C) 1990, 1991, 1992, 1993, 1995, 1998, 1999, 2002, 2003,
4 @c 2004, 2005, 2006 Free Software Foundation, Inc.
5 @c See the file elisp.texi for copying conditions.
6 @setfilename ../info/tips
7 @node Tips, GNU Emacs Internals, GPL, Top
8 @appendix Tips and Conventions
10 @cindex standards of coding style
11 @cindex coding standards
13 This chapter describes no additional features of Emacs Lisp. Instead
14 it gives advice on making effective use of the features described in the
15 previous chapters, and describes conventions Emacs Lisp programmers
18 You can automatically check some of the conventions described below by
19 running the command @kbd{M-x checkdoc RET} when visiting a Lisp file.
20 It cannot check all of the conventions, and not all the warnings it
21 gives necessarily correspond to problems, but it is worth examining them
25 * Coding Conventions:: Conventions for clean and robust programs.
26 * Key Binding Conventions:: Which keys should be bound by which programs.
27 * Programming Tips:: Making Emacs code fit smoothly in Emacs.
28 * Compilation Tips:: Making compiled code run fast.
29 * Warning Tips:: Turning off compiler warnings.
30 * Documentation Tips:: Writing readable documentation strings.
31 * Comment Tips:: Conventions for writing comments.
32 * Library Headers:: Standard headers for library packages.
35 @node Coding Conventions
36 @section Emacs Lisp Coding Conventions
38 Here are conventions that you should follow when writing Emacs Lisp
39 code intended for widespread use:
43 Simply loading the package should not change Emacs's editing behavior.
44 Include a command or commands to enable and disable the feature,
47 This convention is mandatory for any file that includes custom
48 definitions. If fixing such a file to follow this convention requires
49 an incompatible change, go ahead and make the incompatible change;
53 Since all global variables share the same name space, and all
54 functions share another name space, you should choose a short word to
55 distinguish your program from other Lisp programs.@footnote{The
56 benefits of a Common Lisp-style package system are considered not to
57 outweigh the costs.} Then take care to begin the names of all global
58 variables, constants, and functions in your program with the chosen
59 prefix. This helps avoid name conflicts.
61 Occasionally, for a command name intended for users to use, it is more
62 convenient if some words come before the package's name prefix. And
63 constructs that define functions, variables, etc., work better if they
64 start with @samp{defun} or @samp{defvar}, so put the name prefix later
67 This recommendation applies even to names for traditional Lisp
68 primitives that are not primitives in Emacs Lisp---such as
69 @code{copy-list}. Believe it or not, there is more than one plausible
70 way to define @code{copy-list}. Play it safe; append your name prefix
71 to produce a name like @code{foo-copy-list} or @code{mylib-copy-list}
74 If you write a function that you think ought to be added to Emacs under
75 a certain name, such as @code{twiddle-files}, don't call it by that name
76 in your program. Call it @code{mylib-twiddle-files} in your program,
77 and send mail to @samp{bug-gnu-emacs@@gnu.org} suggesting we add
78 it to Emacs. If and when we do, we can change the name easily enough.
80 If one prefix is insufficient, your package can use two or three
81 alternative common prefixes, so long as they make sense.
83 Separate the prefix from the rest of the symbol name with a hyphen,
84 @samp{-}. This will be consistent with Emacs itself and with most Emacs
88 Put a call to @code{provide} at the end of each separate Lisp file.
91 If a file requires certain other Lisp programs to be loaded
92 beforehand, then the comments at the beginning of the file should say
93 so. Also, use @code{require} to make sure they are loaded.
96 If one file @var{foo} uses a macro defined in another file @var{bar},
97 @var{foo} should contain this expression before the first use of the
101 (eval-when-compile (require '@var{bar}))
105 (And the library @var{bar} should contain @code{(provide '@var{bar})},
106 to make the @code{require} work.) This will cause @var{bar} to be
107 loaded when you byte-compile @var{foo}. Otherwise, you risk compiling
108 @var{foo} without the necessary macro loaded, and that would produce
109 compiled code that won't work right. @xref{Compiling Macros}.
111 Using @code{eval-when-compile} avoids loading @var{bar} when
112 the compiled version of @var{foo} is @emph{used}.
115 Please don't require the @code{cl} package of Common Lisp extensions at
116 run time. Use of this package is optional, and it is not part of the
117 standard Emacs namespace. If your package loads @code{cl} at run time,
118 that could cause name clashes for users who don't use that package.
120 However, there is no problem with using the @code{cl} package at compile
121 time, with @code{(eval-when-compile (require 'cl))}.
124 When defining a major mode, please follow the major mode
125 conventions. @xref{Major Mode Conventions}.
128 When defining a minor mode, please follow the minor mode
129 conventions. @xref{Minor Mode Conventions}.
132 If the purpose of a function is to tell you whether a certain condition
133 is true or false, give the function a name that ends in @samp{p}. If
134 the name is one word, add just @samp{p}; if the name is multiple words,
135 add @samp{-p}. Examples are @code{framep} and @code{frame-live-p}.
138 If a user option variable records a true-or-false condition, give it a
139 name that ends in @samp{-flag}.
142 If the purpose of a variable is to store a single function, give it a
143 name that ends in @samp{-function}. If the purpose of a variable is
144 to store a list of functions (i.e., the variable is a hook), please
145 follow the naming conventions for hooks. @xref{Hooks}.
148 @cindex unloading packages
149 If loading the file adds functions to hooks, define a function
150 @code{@var{feature}-unload-hook}, where @var{feature} is the name of
151 the feature the package provides, and make it undo any such changes.
152 Using @code{unload-feature} to unload the file will run this function.
156 It is a bad idea to define aliases for the Emacs primitives. Normally
157 you should use the standard names instead. The case where an alias
158 may be useful is where it facilitates backwards compatibility or
162 If a package needs to define an alias or a new function for
163 compatibility with some other version of Emacs, name it with the package
164 prefix, not with the raw name with which it occurs in the other version.
165 Here is an example from Gnus, which provides many examples of such
166 compatibility issues.
169 (defalias 'gnus-point-at-bol
170 (if (fboundp 'point-at-bol)
172 'line-beginning-position))
176 Redefining (or advising) an Emacs primitive is discouraged. It may do
177 the right thing for a particular program, but there is no telling what
178 other programs might break as a result.
181 If a file does replace any of the functions or library programs of
182 standard Emacs, prominent comments at the beginning of the file should
183 say which functions are replaced, and how the behavior of the
184 replacements differs from that of the originals.
187 Avoid using macros that define functions and variables with names that
188 are constructed. It is best for maintenance when the name of the
189 function or variable being defined is given explicitly in the source
190 code, as the second element of the list---as it is when you use
191 @code{defun}, @code{defalias}, @code{defvar} and @code{defcustom}.
194 Please keep the names of your Emacs Lisp source files to 13 characters
195 or less. This way, if the files are compiled, the compiled files' names
196 will be 14 characters or less, which is short enough to fit on all kinds
200 In some other systems there is a convention of choosing variable names
201 that begin and end with @samp{*}. We don't use that convention in Emacs
202 Lisp, so please don't use it in your programs. (Emacs uses such names
203 only for special-purpose buffers.) The users will find Emacs more
204 coherent if all libraries use the same conventions.
207 Indent each function with @kbd{C-M-q} (@code{indent-sexp}) using the
208 default indentation parameters.
211 Don't make a habit of putting close-parentheses on lines by themselves;
212 Lisp programmers find this disconcerting. Once in a while, when there
213 is a sequence of many consecutive close-parentheses, it may make sense
214 to split the sequence in one or two significant places.
217 Please put a copyright notice and copying permission notice on the
218 file if you distribute copies. Use a notice like this one:
221 ;; Copyright (C) @var{year} @var{name}
223 ;; This program is free software; you can redistribute it and/or
224 ;; modify it under the terms of the GNU General Public License as
225 ;; published by the Free Software Foundation; either version 2 of
226 ;; the License, or (at your option) any later version.
228 ;; This program is distributed in the hope that it will be
229 ;; useful, but WITHOUT ANY WARRANTY; without even the implied
230 ;; warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR
231 ;; PURPOSE. See the GNU General Public License for more details.
233 ;; You should have received a copy of the GNU General Public
234 ;; License along with this program; if not, write to the Free
235 ;; Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
239 If you have signed papers to assign the copyright to the Foundation,
240 then use @samp{Free Software Foundation, Inc.} as @var{name}.
241 Otherwise, use your name. See also @xref{Library Headers}.
244 @node Key Binding Conventions
245 @section Key Binding Conventions
250 @cindex references, following
251 Special major modes used for read-only text should usually redefine
252 @kbd{mouse-2} and @key{RET} to trace some sort of reference in the text.
253 Modes such as Dired, Info, Compilation, and Occur redefine it in this
256 In addition, they should mark the text as a kind of ``link'' so that
257 @kbd{mouse-1} will follow it also. @xref{Links and Mouse-1}.
260 @cindex reserved keys
261 @cindex keys, reserved
262 Please do not define @kbd{C-c @var{letter}} as a key in Lisp programs.
263 Sequences consisting of @kbd{C-c} and a letter (either upper or lower
264 case) are reserved for users; they are the @strong{only} sequences
265 reserved for users, so do not block them.
267 Changing all the Emacs major modes to respect this convention was a
268 lot of work; abandoning this convention would make that work go to
269 waste, and inconvenience users. Please comply with it.
272 Function keys @key{F5} through @key{F9} without modifier keys are
273 also reserved for users to define.
276 Applications should not bind mouse events based on button 1 with the
277 shift key held down. These events include @kbd{S-mouse-1},
278 @kbd{M-S-mouse-1}, @kbd{C-S-mouse-1}, and so on. They are reserved for
282 Sequences consisting of @kbd{C-c} followed by a control character or a
283 digit are reserved for major modes.
286 Sequences consisting of @kbd{C-c} followed by @kbd{@{}, @kbd{@}},
287 @kbd{<}, @kbd{>}, @kbd{:} or @kbd{;} are also reserved for major modes.
290 Sequences consisting of @kbd{C-c} followed by any other punctuation
291 character are allocated for minor modes. Using them in a major mode is
292 not absolutely prohibited, but if you do that, the major mode binding
293 may be shadowed from time to time by minor modes.
296 Do not bind @kbd{C-h} following any prefix character (including
297 @kbd{C-c}). If you don't bind @kbd{C-h}, it is automatically available
298 as a help character for listing the subcommands of the prefix character.
301 Do not bind a key sequence ending in @key{ESC} except following
302 another @key{ESC}. (That is, it is OK to bind a sequence ending in
303 @kbd{@key{ESC} @key{ESC}}.)
305 The reason for this rule is that a non-prefix binding for @key{ESC} in
306 any context prevents recognition of escape sequences as function keys in
310 Anything which acts like a temporary mode or state which the user can
311 enter and leave should define @kbd{@key{ESC} @key{ESC}} or
312 @kbd{@key{ESC} @key{ESC} @key{ESC}} as a way to escape.
314 For a state which accepts ordinary Emacs commands, or more generally any
315 kind of state in which @key{ESC} followed by a function key or arrow key
316 is potentially meaningful, then you must not define @kbd{@key{ESC}
317 @key{ESC}}, since that would preclude recognizing an escape sequence
318 after @key{ESC}. In these states, you should define @kbd{@key{ESC}
319 @key{ESC} @key{ESC}} as the way to escape. Otherwise, define
320 @kbd{@key{ESC} @key{ESC}} instead.
323 @node Programming Tips
324 @section Emacs Programming Tips
326 Following these conventions will make your program fit better
327 into Emacs when it runs.
331 Don't use @code{next-line} or @code{previous-line} in programs; nearly
332 always, @code{forward-line} is more convenient as well as more
333 predictable and robust. @xref{Text Lines}.
336 Don't call functions that set the mark, unless setting the mark is one
337 of the intended features of your program. The mark is a user-level
338 feature, so it is incorrect to change the mark except to supply a value
339 for the user's benefit. @xref{The Mark}.
341 In particular, don't use any of these functions:
345 @code{beginning-of-buffer}, @code{end-of-buffer}
347 @code{replace-string}, @code{replace-regexp}
349 @code{insert-file}, @code{insert-buffer}
352 If you just want to move point, or replace a certain string, or insert
353 a file or buffer's contents, without any of the other features
354 intended for interactive users, you can replace these functions with
355 one or two lines of simple Lisp code.
358 Use lists rather than vectors, except when there is a particular reason
359 to use a vector. Lisp has more facilities for manipulating lists than
360 for vectors, and working with lists is usually more convenient.
362 Vectors are advantageous for tables that are substantial in size and are
363 accessed in random order (not searched front to back), provided there is
364 no need to insert or delete elements (only lists allow that).
367 The recommended way to show a message in the echo area is with
368 the @code{message} function, not @code{princ}. @xref{The Echo Area}.
371 When you encounter an error condition, call the function @code{error}
372 (or @code{signal}). The function @code{error} does not return.
373 @xref{Signaling Errors}.
375 Do not use @code{message}, @code{throw}, @code{sleep-for},
376 or @code{beep} to report errors.
379 An error message should start with a capital letter but should not end
383 A question asked in the minibuffer with @code{y-or-n-p} or
384 @code{yes-or-no-p} should start with a capital letter and end with
388 When you mention a default value in a minibuffer prompt,
389 put it and the word @samp{default} inside parentheses.
390 It should look like this:
393 Enter the answer (default 42):
397 In @code{interactive}, if you use a Lisp expression to produce a list
398 of arguments, don't try to provide the ``correct'' default values for
399 region or position arguments. Instead, provide @code{nil} for those
400 arguments if they were not specified, and have the function body
401 compute the default value when the argument is @code{nil}. For
402 instance, write this:
407 (list (if @var{specified} @var{specified-pos})))
408 (unless pos (setq pos @var{default-pos}))
418 (list (if @var{specified} @var{specified-pos}
424 This is so that repetition of the command will recompute
425 these defaults based on the current circumstances.
427 You do not need to take such precautions when you use interactive
428 specs @samp{d}, @samp{m} and @samp{r}, because they make special
429 arrangements to recompute the argument values on repetition of the
433 Many commands that take a long time to execute display a message that
434 says something like @samp{Operating...} when they start, and change it to
435 @samp{Operating...done} when they finish. Please keep the style of
436 these messages uniform: @emph{no} space around the ellipsis, and
437 @emph{no} period after @samp{done}.
440 Try to avoid using recursive edits. Instead, do what the Rmail @kbd{e}
441 command does: use a new local keymap that contains one command defined
442 to switch back to the old local keymap. Or do what the
443 @code{edit-options} command does: switch to another buffer and let the
444 user switch back at will. @xref{Recursive Editing}.
447 @node Compilation Tips
448 @section Tips for Making Compiled Code Fast
449 @cindex execution speed
452 Here are ways of improving the execution speed of byte-compiled
458 @cindex timing programs
459 @cindex @file{elp.el}
460 Profile your program with the @file{elp} library. See the file
461 @file{elp.el} for instructions.
464 @cindex @file{benchmark.el}
466 Check the speed of individual Emacs Lisp forms using the
467 @file{benchmark} library. See the functions @code{benchmark-run} and
468 @code{benchmark-run-compiled} in @file{benchmark.el}.
471 Use iteration rather than recursion whenever possible.
472 Function calls are slow in Emacs Lisp even when a compiled function
473 is calling another compiled function.
476 Using the primitive list-searching functions @code{memq}, @code{member},
477 @code{assq}, or @code{assoc} is even faster than explicit iteration. It
478 can be worth rearranging a data structure so that one of these primitive
479 search functions can be used.
482 Certain built-in functions are handled specially in byte-compiled code,
483 avoiding the need for an ordinary function call. It is a good idea to
484 use these functions rather than alternatives. To see whether a function
485 is handled specially by the compiler, examine its @code{byte-compile}
486 property. If the property is non-@code{nil}, then the function is
489 For example, the following input will show you that @code{aref} is
490 compiled specially (@pxref{Array Functions}):
494 (get 'aref 'byte-compile)
495 @result{} byte-compile-two-args
500 If calling a small function accounts for a substantial part of your
501 program's running time, make the function inline. This eliminates
502 the function call overhead. Since making a function inline reduces
503 the flexibility of changing the program, don't do it unless it gives
504 a noticeable speedup in something slow enough that users care about
505 the speed. @xref{Inline Functions}.
509 @section Tips for Avoiding Compiler Warnings
513 Try to avoid compiler warnings about undefined free variables, by adding
514 dummy @code{defvar} definitions for these variables, like this:
520 Such a definition has no effect except to tell the compiler
521 not to warn about uses of the variable @code{foo} in this file.
524 If you use many functions and variables from a certain file, you can
525 add a @code{require} for that package to avoid compilation warnings
526 for them. For instance,
534 If you bind a variable in one function, and use it or set it in
535 another function, the compiler warns about the latter function unless
536 the variable has a definition. But adding a definition would be
537 unclean if the variable has a short name, since Lisp packages should
538 not define short variable names. The right thing to do is to rename
539 this variable to start with the name prefix used for the other
540 functions and variables in your package.
543 The last resort for avoiding a warning, when you want to do something
544 that usually is a mistake but it's not a mistake in this one case,
545 is to put a call to @code{with-no-warnings} around it.
548 @node Documentation Tips
549 @section Tips for Documentation Strings
551 @findex checkdoc-minor-mode
552 Here are some tips and conventions for the writing of documentation
553 strings. You can check many of these conventions by running the command
554 @kbd{M-x checkdoc-minor-mode}.
558 Every command, function, or variable intended for users to know about
559 should have a documentation string.
562 An internal variable or subroutine of a Lisp program might as well have
563 a documentation string. In earlier Emacs versions, you could save space
564 by using a comment instead of a documentation string, but that is no
565 longer the case---documentation strings now take up very little space in
569 Format the documentation string so that it fits in an Emacs window on an
570 80-column screen. It is a good idea for most lines to be no wider than
571 60 characters. The first line should not be wider than 67 characters
572 or it will look bad in the output of @code{apropos}.
574 You can fill the text if that looks good. However, rather than blindly
575 filling the entire documentation string, you can often make it much more
576 readable by choosing certain line breaks with care. Use blank lines
577 between topics if the documentation string is long.
580 The first line of the documentation string should consist of one or two
581 complete sentences that stand on their own as a summary. @kbd{M-x
582 apropos} displays just the first line, and if that line's contents don't
583 stand on their own, the result looks bad. In particular, start the
584 first line with a capital letter and end with a period.
586 For a function, the first line should briefly answer the question,
587 ``What does this function do?'' For a variable, the first line should
588 briefly answer the question, ``What does this value mean?''
590 Don't limit the documentation string to one line; use as many lines as
591 you need to explain the details of how to use the function or
592 variable. Please use complete sentences for the rest of the text too.
595 The first line should mention all the important arguments of the
596 function, and should mention them in the order that they are written
597 in a function call. If the function has many arguments, then it is
598 not feasible to mention them all in the first line; in that case, the
599 first line should mention the first few arguments, including the most
603 For consistency, phrase the verb in the first sentence of a function's
604 documentation string as an imperative---for instance, use ``Return the
605 cons of A and B.'' in preference to ``Returns the cons of A and B@.''
606 Usually it looks good to do likewise for the rest of the first
607 paragraph. Subsequent paragraphs usually look better if each sentence
608 is indicative and has a proper subject.
611 Write documentation strings in the active voice, not the passive, and in
612 the present tense, not the future. For instance, use ``Return a list
613 containing A and B.'' instead of ``A list containing A and B will be
617 Avoid using the word ``cause'' (or its equivalents) unnecessarily.
618 Instead of, ``Cause Emacs to display text in boldface,'' write just
619 ``Display text in boldface.''
622 When a command is meaningful only in a certain mode or situation,
623 do mention that in the documentation string. For example,
624 the documentation of @code{dired-find-file} is:
627 In Dired, visit the file or directory named on this line.
631 Do not start or end a documentation string with whitespace.
634 @strong{Do not} indent subsequent lines of a documentation string so
635 that the text is lined up in the source code with the text of the first
636 line. This looks nice in the source code, but looks bizarre when users
637 view the documentation. Remember that the indentation before the
638 starting double-quote is not part of the string!
641 When the user tries to use a disabled command, Emacs displays just the
642 first paragraph of its documentation string---everything through the
643 first blank line. If you wish, you can choose which information to
644 include before the first blank line so as to make this display useful.
647 When you define a variable that users ought to set interactively, you
648 normally should use @code{defcustom}. However, if for some reason you
649 use @code{defvar} instead, start the doc string with a @samp{*}.
650 @xref{Defining Variables}.
653 The documentation string for a variable that is a yes-or-no flag should
654 start with words such as ``Non-nil means@dots{}'', to make it clear that
655 all non-@code{nil} values are equivalent and indicate explicitly what
656 @code{nil} and non-@code{nil} mean.
659 The documentation string for a function that is a yes-or-no predicate
660 should start with words such as ``Return t if @dots{}'', to indicate
661 explicitly what constitutes ``truth''. The word ``return'' avoids
662 starting the sentence with lower-case ``t'', which is somewhat
666 When a function's documentation string mentions the value of an argument
667 of the function, use the argument name in capital letters as if it were
668 a name for that value. Thus, the documentation string of the function
669 @code{eval} refers to its second argument as @samp{FORM}, because the
670 actual argument name is @code{form}:
673 Evaluate FORM and return its value.
676 Also write metasyntactic variables in capital letters, such as when you
677 show the decomposition of a list or vector into subunits, some of which
678 may vary. @samp{KEY} and @samp{VALUE} in the following example
679 illustrate this practice:
682 The argument TABLE should be an alist whose elements
683 have the form (KEY . VALUE). Here, KEY is ...
687 Never change the case of a Lisp symbol when you mention it in a doc
688 string. If the symbol's name is @code{foo}, write ``foo'', not
689 ``Foo'' (which is a different symbol).
691 This might appear to contradict the policy of writing function
692 argument values, but there is no real contradiction; the argument
693 @emph{value} is not the same thing as the @emph{symbol} which the
694 function uses to hold the value.
696 If this puts a lower-case letter at the beginning of a sentence
697 and that annoys you, rewrite the sentence so that the symbol
698 is not at the start of it.
701 If a line in a documentation string begins with an open-parenthesis,
702 write a backslash before the open-parenthesis, like this:
705 The argument FOO can be either a number
706 \(a buffer position) or a string (a file name).
709 This prevents the open-parenthesis from being treated as the start of a
710 defun (@pxref{Defuns,, Defuns, emacs, The GNU Emacs Manual}).
712 @anchor{Docstring hyperlinks}
715 When a documentation string refers to a Lisp symbol, write it as it
716 would be printed (which usually means in lower case), with single-quotes
717 around it. For example: @samp{`lambda'}. There are two exceptions:
718 write @code{t} and @code{nil} without single-quotes.
721 When a documentation string refers to a Lisp symbol, write it as it
722 would be printed (which usually means in lower case), with single-quotes
723 around it. For example: @samp{lambda}. There are two exceptions: write
724 t and nil without single-quotes. (In this manual, we use a different
725 convention, with single-quotes for all symbols.)
728 Help mode automatically creates a hyperlink when a documentation string
729 uses a symbol name inside single quotes, if the symbol has either a
730 function or a variable definition. You do not need to do anything
731 special to make use of this feature. However, when a symbol has both a
732 function definition and a variable definition, and you want to refer to
733 just one of them, you can specify which one by writing one of the words
734 @samp{variable}, @samp{option}, @samp{function}, or @samp{command},
735 immediately before the symbol name. (Case makes no difference in
736 recognizing these indicator words.) For example, if you write
739 This function sets the variable `buffer-file-name'.
743 then the hyperlink will refer only to the variable documentation of
744 @code{buffer-file-name}, and not to its function documentation.
746 If a symbol has a function definition and/or a variable definition, but
747 those are irrelevant to the use of the symbol that you are documenting,
748 you can write the words @samp{symbol} or @samp{program} before the
749 symbol name to prevent making any hyperlink. For example,
752 If the argument KIND-OF-RESULT is the symbol `list',
753 this function returns a list of all the objects
754 that satisfy the criterion.
758 does not make a hyperlink to the documentation, irrelevant here, of the
759 function @code{list}.
761 Normally, no hyperlink is made for a variable without variable
762 documentation. You can force a hyperlink for such variables by
763 preceding them with one of the words @samp{variable} or
766 Hyperlinks for faces are only made if the face name is preceded or
767 followed by the word @samp{face}. In that case, only the face
768 documentation will be shown, even if the symbol is also defined as a
769 variable or as a function.
771 To make a hyperlink to Info documentation, write the name of the Info
772 node (or anchor) in single quotes, preceded by @samp{info node},
773 @samp{Info node}, @samp{info anchor} or @samp{Info anchor}. The Info
774 file name defaults to @samp{emacs}. For example,
777 See Info node `Font Lock' and Info node `(elisp)Font Lock Basics'.
780 Finally, to create a hyperlink to URLs, write the URL in single
781 quotes, preceded by @samp{URL}. For example,
784 The home page for the GNU project has more information (see URL
785 `http://www.gnu.org/').
789 Don't write key sequences directly in documentation strings. Instead,
790 use the @samp{\\[@dots{}]} construct to stand for them. For example,
791 instead of writing @samp{C-f}, write the construct
792 @samp{\\[forward-char]}. When Emacs displays the documentation string,
793 it substitutes whatever key is currently bound to @code{forward-char}.
794 (This is normally @samp{C-f}, but it may be some other character if the
795 user has moved key bindings.) @xref{Keys in Documentation}.
798 In documentation strings for a major mode, you will want to refer to the
799 key bindings of that mode's local map, rather than global ones.
800 Therefore, use the construct @samp{\\<@dots{}>} once in the
801 documentation string to specify which key map to use. Do this before
802 the first use of @samp{\\[@dots{}]}. The text inside the
803 @samp{\\<@dots{}>} should be the name of the variable containing the
804 local keymap for the major mode.
806 It is not practical to use @samp{\\[@dots{}]} very many times, because
807 display of the documentation string will become slow. So use this to
808 describe the most important commands in your major mode, and then use
809 @samp{\\@{@dots{}@}} to display the rest of the mode's keymap.
813 @section Tips on Writing Comments
815 We recommend these conventions for where to put comments and how to
820 Comments that start with a single semicolon, @samp{;}, should all be
821 aligned to the same column on the right of the source code. Such
822 comments usually explain how the code on the same line does its job. In
823 Lisp mode and related modes, the @kbd{M-;} (@code{indent-for-comment})
824 command automatically inserts such a @samp{;} in the right place, or
825 aligns such a comment if it is already present.
827 This and following examples are taken from the Emacs sources.
831 (setq base-version-list ; there was a base
832 (assoc (substring fn 0 start-vn) ; version to which
833 file-version-assoc-list)) ; this looks like
839 Comments that start with two semicolons, @samp{;;}, should be aligned to
840 the same level of indentation as the code. Such comments usually
841 describe the purpose of the following lines or the state of the program
842 at that point. For example:
846 (prog1 (setq auto-fill-function
850 (force-mode-line-update)))
854 We also normally use two semicolons for comments outside functions.
858 ;; This Lisp code is run in Emacs
859 ;; when it is to operate as a server
860 ;; for other processes.
864 Every function that has no documentation string (presumably one that is
865 used only internally within the package it belongs to), should instead
866 have a two-semicolon comment right before the function, explaining what
867 the function does and how to call it properly. Explain precisely what
868 each argument means and how the function interprets its possible values.
871 Comments that start with three semicolons, @samp{;;;}, should start at
872 the left margin. These are used, occasionally, for comments within
873 functions that should start at the margin. We also use them sometimes
874 for comments that are between functions---whether to use two or three
875 semicolons depends on whether the comment should be considered a
876 ``heading'' by Outline minor mode. By default, comments starting with
877 at least three semicolons (followed by a single space and a
878 non-whitespace character) are considered headings, comments starting
879 with two or less are not.
881 Another use for triple-semicolon comments is for commenting out lines
882 within a function. We use three semicolons for this precisely so that
883 they remain at the left margin. By default, Outline minor mode does
884 not consider a comment to be a heading (even if it starts with at
885 least three semicolons) if the semicolons are followed by at least two
886 spaces. Thus, if you add an introductory comment to the commented out
887 code, make sure to indent it by at least two spaces after the three
892 ;;; This is no longer necessary.
893 ;;; (force-mode-line-update)
894 (message "Finished with %s" a))
897 When commenting out entire functions, use two semicolons.
900 Comments that start with four semicolons, @samp{;;;;}, should be aligned
901 to the left margin and are used for headings of major sections of a
902 program. For example:
910 The indentation commands of the Lisp modes in Emacs, such as @kbd{M-;}
911 (@code{indent-for-comment}) and @key{TAB} (@code{lisp-indent-line}),
912 automatically indent comments according to these conventions,
913 depending on the number of semicolons. @xref{Comments,,
914 Manipulating Comments, emacs, The GNU Emacs Manual}.
916 @node Library Headers
917 @section Conventional Headers for Emacs Libraries
918 @cindex header comments
919 @cindex library header comments
921 Emacs has conventions for using special comments in Lisp libraries
922 to divide them into sections and give information such as who wrote
923 them. This section explains these conventions.
925 We'll start with an example, a package that is included in the Emacs
928 Parts of this example reflect its status as part of Emacs; for
929 example, the copyright notice lists the Free Software Foundation as the
930 copyright holder, and the copying permission says the file is part of
931 Emacs. When you write a package and post it, the copyright holder would
932 be you (unless your employer claims to own it instead), and you should
933 get the suggested copying permission from the end of the GNU General
934 Public License itself. Don't say your file is part of Emacs
935 if we haven't installed it in Emacs yet!
937 With that warning out of the way, on to the example:
941 ;;; lisp-mnt.el --- minor mode for Emacs Lisp maintainers
943 ;; Copyright (C) 1992 Free Software Foundation, Inc.
946 ;; Author: Eric S. Raymond <esr@@snark.thyrsus.com>
947 ;; Maintainer: Eric S. Raymond <esr@@snark.thyrsus.com>
948 ;; Created: 14 Jul 1992
953 ;; This file is part of GNU Emacs.
955 ;; Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor,
956 ;; Boston, MA 02110-1301, USA.
960 The very first line should have this format:
963 ;;; @var{filename} --- @var{description}
967 The description should be complete in one line. If the file
968 needs a @samp{-*-} specification, put it after @var{description}.
970 After the copyright notice come several @dfn{header comment} lines,
971 each beginning with @samp{;; @var{header-name}:}. Here is a table of
972 the conventional possibilities for @var{header-name}:
976 This line states the name and net address of at least the principal
977 author of the library.
979 If there are multiple authors, you can list them on continuation lines
980 led by @code{;;} and a tab character, like this:
984 ;; Author: Ashwin Ram <Ram-Ashwin@@cs.yale.edu>
985 ;; Dave Sill <de5@@ornl.gov>
986 ;; Dave Brennan <brennan@@hal.com>
987 ;; Eric Raymond <esr@@snark.thyrsus.com>
992 This line should contain a single name/address as in the Author line, or
993 an address only, or the string @samp{FSF}. If there is no maintainer
994 line, the person(s) in the Author field are presumed to be the
995 maintainers. The example above is mildly bogus because the maintainer
998 The idea behind the @samp{Author} and @samp{Maintainer} lines is to make
999 possible a Lisp function to ``send mail to the maintainer'' without
1000 having to mine the name out by hand.
1002 Be sure to surround the network address with @samp{<@dots{}>} if
1003 you include the person's full name as well as the network address.
1006 This optional line gives the original creation date of the
1007 file. For historical interest only.
1010 If you wish to record version numbers for the individual Lisp program, put
1014 In this header line, place the name of the person who adapted the
1015 library for installation (to make it fit the style conventions, for
1019 This line lists keywords for the @code{finder-by-keyword} help command.
1020 Please use that command to see a list of the meaningful keywords.
1022 This field is important; it's how people will find your package when
1023 they're looking for things by topic area. To separate the keywords, you
1024 can use spaces, commas, or both.
1027 Just about every Lisp library ought to have the @samp{Author} and
1028 @samp{Keywords} header comment lines. Use the others if they are
1029 appropriate. You can also put in header lines with other header
1030 names---they have no standard meanings, so they can't do any harm.
1032 We use additional stylized comments to subdivide the contents of the
1033 library file. These should be separated by blank lines from anything
1034 else. Here is a table of them:
1037 @item ;;; Commentary:
1038 This begins introductory comments that explain how the library works.
1039 It should come right after the copying permissions, terminated by a
1040 @samp{Change Log}, @samp{History} or @samp{Code} comment line. This
1041 text is used by the Finder package, so it should make sense in that
1044 @item ;;; Documentation:
1045 This was used in some files in place of @samp{;;; Commentary:},
1046 but it is deprecated.
1048 @item ;;; Change Log:
1049 This begins change log information stored in the library file (if you
1050 store the change history there). For Lisp files distributed with Emacs,
1051 the change history is kept in the file @file{ChangeLog} and not in the
1052 source file at all; these files generally do not have a @samp{;;; Change
1053 Log:} line. @samp{History} is an alternative to @samp{Change Log}.
1056 This begins the actual code of the program.
1058 @item ;;; @var{filename} ends here
1059 This is the @dfn{footer line}; it appears at the very end of the file.
1060 Its purpose is to enable people to detect truncated versions of the file
1061 from the lack of a footer line.
1065 arch-tag: 9ea911c2-6b1d-47dd-88b7-0a94e8b27c2e