2 @c This is part of the GNU Emacs Lisp Reference Manual.
3 @c Copyright (C) 1990, 1991, 1992, 1993, 1995, 1998, 1999
4 @c 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 * Compilation Tips:: Making compiled code run fast.
27 * Documentation Tips:: Writing readable documentation strings.
28 * Comment Tips:: Conventions for writing comments.
29 * Library Headers:: Standard headers for library packages.
32 @node Coding Conventions
33 @section Emacs Lisp Coding Conventions
35 Here are conventions that you should follow when writing Emacs Lisp
36 code intended for widespread use:
40 Since all global variables share the same name space, and all
41 functions share another name space, you should choose a short word to
42 distinguish your program from other Lisp programs.@footnote{The
43 benefits of a Common Lisp-style package system are considered not to
44 outweigh the costs.} Then take care to begin the names of all global
45 variables, constants, and functions in your program with the chosen
46 prefix. This helps avoid name conflicts.
48 This recommendation applies even to names for traditional Lisp
49 primitives that are not primitives in Emacs Lisp---even to
50 @code{copy-list}. Believe it or not, there is more than one plausible
51 way to define @code{copy-list}. Play it safe; append your name prefix
52 to produce a name like @code{foo-copy-list} or @code{mylib-copy-list}
55 If you write a function that you think ought to be added to Emacs under
56 a certain name, such as @code{twiddle-files}, don't call it by that name
57 in your program. Call it @code{mylib-twiddle-files} in your program,
58 and send mail to @samp{bug-gnu-emacs@@gnu.org} suggesting we add
59 it to Emacs. If and when we do, we can change the name easily enough.
61 If one prefix is insufficient, your package may use two or three
62 alternative common prefixes, so long as they make sense.
64 Separate the prefix from the rest of the symbol name with a hyphen,
65 @samp{-}. This will be consistent with Emacs itself and with most Emacs
69 It is often useful to put a call to @code{provide} in each separate
70 library program, at least if there is more than one entry point to the
74 If a file requires certain other library programs to be loaded
75 beforehand, then the comments at the beginning of the file should say
76 so. Also, use @code{require} to make sure they are loaded.
79 If one file @var{foo} uses a macro defined in another file @var{bar},
80 @var{foo} should contain this expression before the first use of the
84 (eval-when-compile (require '@var{bar}))
88 (And the library @var{bar} should contain @code{(provide '@var{bar})},
89 to make the @code{require} work.) This will cause @var{bar} to be
90 loaded when you byte-compile @var{foo}. Otherwise, you risk compiling
91 @var{foo} without the necessary macro loaded, and that would produce
92 compiled code that won't work right. @xref{Compiling Macros}.
94 Using @code{eval-when-compile} avoids loading @var{bar} when
95 the compiled version of @var{foo} is @emph{used}.
98 Please don't require the @code{cl} package of Common Lisp extensions at
99 run time. Use of this package is optional, and it is not part of the
100 standard Emacs namespace. If your package loads @code{cl} at run time,
101 that could cause name clashes for users who don't use that package.
103 However, there is no problem with using the @code{cl} package at compile
104 time, for the sake of macros. You do that like this:
107 (eval-when-compile (require 'cl))
111 When defining a major mode, please follow the major mode
112 conventions. @xref{Major Mode Conventions}.
115 When defining a minor mode, please follow the minor mode
116 conventions. @xref{Minor Mode Conventions}.
119 If the purpose of a function is to tell you whether a certain condition
120 is true or false, give the function a name that ends in @samp{p}. If
121 the name is one word, add just @samp{p}; if the name is multiple words,
122 add @samp{-p}. Examples are @code{framep} and @code{frame-live-p}.
125 If a user option variable records a true-or-false condition, give it a
126 name that ends in @samp{-flag}.
129 If the purpose of a variable is to store a single function, give it a
130 name that ends in @samp{-function}. If the purpose of a variable is
131 to store a list of functions (i.e., the variable is a hook), please
132 follow the naming conventions for hooks. @xref{Hooks}.
135 @cindex reserved keys
136 @cindex keys, reserved
137 Please do not define @kbd{C-c @var{letter}} as a key in your major
138 modes. Sequences consisting of @kbd{C-c} and a letter (either upper
139 or lower case) are reserved for users; they are the @strong{only}
140 sequences reserved for users, so do not block them.
142 Changing all the Emacs major modes to respect this convention was a
143 lot of work; abandoning this convention would make that work go to
144 waste, and inconvenience users. Please comply with it.
147 Sequences consisting of @kbd{C-c} followed by a control character or a
148 digit are reserved for major modes.
151 Sequences consisting of @kbd{C-c} followed by @kbd{@{}, @kbd{@}},
152 @kbd{<}, @kbd{>}, @kbd{:} or @kbd{;} are also reserved for major modes.
155 Sequences consisting of @kbd{C-c} followed by any other punctuation
156 character are allocated for minor modes. Using them in a major mode is
157 not absolutely prohibited, but if you do that, the major mode binding
158 may be shadowed from time to time by minor modes.
161 Function keys @key{F5} through @key{F9} without modifier keys are
162 reserved for users to define.
165 Do not bind @kbd{C-h} following any prefix character (including
166 @kbd{C-c}). If you don't bind @kbd{C-h}, it is automatically available
167 as a help character for listing the subcommands of the prefix character.
170 Do not bind a key sequence ending in @key{ESC} except following
171 another @key{ESC}. (That is, it is OK to bind a sequence ending in
172 @kbd{@key{ESC} @key{ESC}}.)
174 The reason for this rule is that a non-prefix binding for @key{ESC} in
175 any context prevents recognition of escape sequences as function keys in
179 Anything which acts like a temporary mode or state which the user can
180 enter and leave should define @kbd{@key{ESC} @key{ESC}} or
181 @kbd{@key{ESC} @key{ESC} @key{ESC}} as a way to escape.
183 For a state which accepts ordinary Emacs commands, or more generally any
184 kind of state in which @key{ESC} followed by a function key or arrow key
185 is potentially meaningful, then you must not define @kbd{@key{ESC}
186 @key{ESC}}, since that would preclude recognizing an escape sequence
187 after @key{ESC}. In these states, you should define @kbd{@key{ESC}
188 @key{ESC} @key{ESC}} as the way to escape. Otherwise, define
189 @kbd{@key{ESC} @key{ESC}} instead.
192 Applications should not bind mouse events based on button 1 with the
193 shift key held down. These events include @kbd{S-mouse-1},
194 @kbd{M-S-mouse-1}, @kbd{C-S-mouse-1}, and so on. They are reserved for
199 @cindex references, following
200 Special major modes used for read-only text should usually redefine
201 @kbd{mouse-2} and @key{RET} to trace some sort of reference in the text.
202 Modes such as Dired, Info, Compilation, and Occur redefine it in this
206 When a package provides a modification of ordinary Emacs behavior, it is
207 good to include a command to enable and disable the feature, provide a
208 command named @code{@var{whatever}-mode} which turns the feature on or
209 off, and make it autoload (@pxref{Autoload}). Design the package so
210 that simply loading it has no visible effect---that should not enable
211 the feature.@footnote{Consider that the package may be loaded
212 arbitrarily by Custom for instance.} Users will request the feature by
213 invoking the command.
216 It is a bad idea to define aliases for the Emacs primitives. Use the
217 standard names instead.
220 If a package needs to define an alias or a new function for
221 compatibility with some other version of Emacs, name it with the package
222 prefix, not with the raw name with which it occurs in the other version.
223 Here is an example from Gnus, which provides many examples of such
224 compatibility issues.
227 (defalias 'gnus-point-at-bol
228 (if (fboundp 'point-at-bol)
230 'line-beginning-position))
234 Redefining (or advising) an Emacs primitive is discouraged. It may do
235 the right thing for a particular program, but there is no telling what
236 other programs might break as a result.
239 If a file does replace any of the functions or library programs of
240 standard Emacs, prominent comments at the beginning of the file should
241 say which functions are replaced, and how the behavior of the
242 replacements differs from that of the originals.
245 Please keep the names of your Emacs Lisp source files to 13 characters
246 or less. This way, if the files are compiled, the compiled files' names
247 will be 14 characters or less, which is short enough to fit on all kinds
251 Don't use @code{next-line} or @code{previous-line} in programs; nearly
252 always, @code{forward-line} is more convenient as well as more
253 predictable and robust. @xref{Text Lines}.
256 Don't call functions that set the mark, unless setting the mark is one
257 of the intended features of your program. The mark is a user-level
258 feature, so it is incorrect to change the mark except to supply a value
259 for the user's benefit. @xref{The Mark}.
261 In particular, don't use any of these functions:
265 @code{beginning-of-buffer}, @code{end-of-buffer}
267 @code{replace-string}, @code{replace-regexp}
270 If you just want to move point, or replace a certain string, without any
271 of the other features intended for interactive users, you can replace
272 these functions with one or two lines of simple Lisp code.
275 Use lists rather than vectors, except when there is a particular reason
276 to use a vector. Lisp has more facilities for manipulating lists than
277 for vectors, and working with lists is usually more convenient.
279 Vectors are advantageous for tables that are substantial in size and are
280 accessed in random order (not searched front to back), provided there is
281 no need to insert or delete elements (only lists allow that).
284 The recommended way to print a message in the echo area is with
285 the @code{message} function, not @code{princ}. @xref{The Echo Area}.
288 When you encounter an error condition, call the function @code{error}
289 (or @code{signal}). The function @code{error} does not return.
290 @xref{Signaling Errors}.
292 Do not use @code{message}, @code{throw}, @code{sleep-for},
293 or @code{beep} to report errors.
296 An error message should start with a capital letter but should not end
300 In @code{interactive}, if you use a Lisp expression to produce a list
301 of arguments, don't try to provide the ``correct'' default values for
302 region or position arguments. Instead, provide @code{nil} for those
303 arguments if they were not specified, and have the function body
304 compute the default value when the argument is @code{nil}. For
305 instance, write this:
310 (list (if @var{specified} @var{specified-pos})))
311 (unless pos (setq pos @var{default-pos}))
321 (list (if @var{specified} @var{specified-pos}
327 This is so that repetition of the command will recompute
328 these defaults based on the current circumstances.
330 You do not need to take such precautions when you use interactive
331 specs @samp{d}, @samp{m} and @samp{r}, because they make special
332 arrangements to recompute the argument values on repetition of the
336 Many commands that take a long time to execute display a message that
337 says something like @samp{Operating...} when they start, and change it to
338 @samp{Operating...done} when they finish. Please keep the style of
339 these messages uniform: @emph{no} space around the ellipsis, and
340 @emph{no} period after @samp{done}.
343 Try to avoid using recursive edits. Instead, do what the Rmail @kbd{e}
344 command does: use a new local keymap that contains one command defined
345 to switch back to the old local keymap. Or do what the
346 @code{edit-options} command does: switch to another buffer and let the
347 user switch back at will. @xref{Recursive Editing}.
350 In some other systems there is a convention of choosing variable names
351 that begin and end with @samp{*}. We don't use that convention in Emacs
352 Lisp, so please don't use it in your programs. (Emacs uses such names
353 only for special-purpose buffers.) The users will find Emacs more
354 coherent if all libraries use the same conventions.
357 Try to avoid compiler warnings about undefined free variables, by adding
358 @code{defvar} definitions for these variables.
360 Sometimes adding a @code{require} for another package is useful to avoid
361 compilation warnings for variables and functions defined in that
362 package. If you do this, often it is better if the @code{require} acts
363 only at compile time. Here's how to do that:
371 If you bind a variable in one function, and use it or set it in another
372 function, the compiler warns about the latter function unless the
373 variable has a definition. But often these variables have short names,
374 and it is not clean for Lisp packages to define such variable names.
375 Therefore, you should rename the variable to start with the name prefix
376 used for the other functions and variables in your package.
379 Indent each function with @kbd{C-M-q} (@code{indent-sexp}) using the
380 default indentation parameters.
383 Don't make a habit of putting close-parentheses on lines by themselves;
384 Lisp programmers find this disconcerting. Once in a while, when there
385 is a sequence of many consecutive close-parentheses, it may make sense
386 to split the sequence in one or two significant places.
389 Please put a copyright notice on the file if you give copies to anyone.
390 Use a message like this one:
393 ;; Copyright (C) @var{year} @var{name}
395 ;; This program is free software; you can redistribute it and/or
396 ;; modify it under the terms of the GNU General Public License as
397 ;; published by the Free Software Foundation; either version 2 of
398 ;; the License, or (at your option) any later version.
400 ;; This program is distributed in the hope that it will be
401 ;; useful, but WITHOUT ANY WARRANTY; without even the implied
402 ;; warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR
403 ;; PURPOSE. See the GNU General Public License for more details.
405 ;; You should have received a copy of the GNU General Public
406 ;; License along with this program; if not, write to the Free
407 ;; Software Foundation, Inc., 59 Temple Place, Suite 330, Boston,
411 If you have signed papers to assign the copyright to the Foundation,
412 then use @samp{Free Software Foundation, Inc.} as @var{name}.
413 Otherwise, use your name.
416 @node Compilation Tips
417 @section Tips for Making Compiled Code Fast
418 @cindex execution speed
421 Here are ways of improving the execution speed of byte-compiled
427 @cindex timing programs
428 @cindex @file{elp.el}
429 Profile your program with the @file{elp} library. See the file
430 @file{elp.el} for instructions.
433 Use iteration rather than recursion whenever possible.
434 Function calls are slow in Emacs Lisp even when a compiled function
435 is calling another compiled function.
438 Using the primitive list-searching functions @code{memq}, @code{member},
439 @code{assq}, or @code{assoc} is even faster than explicit iteration. It
440 can be worth rearranging a data structure so that one of these primitive
441 search functions can be used.
444 Certain built-in functions are handled specially in byte-compiled code,
445 avoiding the need for an ordinary function call. It is a good idea to
446 use these functions rather than alternatives. To see whether a function
447 is handled specially by the compiler, examine its @code{byte-compile}
448 property. If the property is non-@code{nil}, then the function is
451 For example, the following input will show you that @code{aref} is
452 compiled specially (@pxref{Array Functions}):
456 (get 'aref 'byte-compile)
457 @result{} byte-compile-two-args
462 If calling a small function accounts for a substantial part of your
463 program's running time, make the function inline. This eliminates
464 the function call overhead. Since making a function inline reduces
465 the flexibility of changing the program, don't do it unless it gives
466 a noticeable speedup in something slow enough that users care about
467 the speed. @xref{Inline Functions}.
470 @node Documentation Tips
471 @section Tips for Documentation Strings
473 @findex checkdoc-minor-mode
474 Here are some tips and conventions for the writing of documentation
475 strings. You can check many of these conventions by running the command
476 @kbd{M-x checkdoc-minor-mode}.
480 Every command, function, or variable intended for users to know about
481 should have a documentation string.
484 An internal variable or subroutine of a Lisp program might as well have
485 a documentation string. In earlier Emacs versions, you could save space
486 by using a comment instead of a documentation string, but that is no
487 longer the case---documentation strings now take up very little space in
491 Format the documentation string so that it fits in an Emacs window on an
492 80-column screen. It is a good idea for most lines to be no wider than
493 60 characters. The first line should not be wider than 67 characters
494 or it will look bad in the output of @code{apropos}.
496 You can fill the text if that looks good. However, rather than blindly
497 filling the entire documentation string, you can often make it much more
498 readable by choosing certain line breaks with care. Use blank lines
499 between topics if the documentation string is long.
502 The first line of the documentation string should consist of one or two
503 complete sentences that stand on their own as a summary. @kbd{M-x
504 apropos} displays just the first line, and if that line's contents don't
505 stand on their own, the result looks bad. In particular, start the
506 first line with a capital letter and end with a period.
508 For a function, the first line should briefly answer the question,
509 ``What does this function do?'' For a variable, the first line should
510 briefly answer the question, ``What does this value mean?''
512 Don't limit the documentation string to one line; use as many lines as
513 you need to explain the details of how to use the function or
514 variable. Please use complete sentences for the rest of the text too.
517 The first line should mention all the important arguments of the
518 function, and should mention them in the order that they are written
519 in a function call. If the function has many arguments, then it is
520 not feasible to mention them all in the first line; in that case, the
521 first line should mention the first few arguments, including the most
525 For consistency, phrase the verb in the first sentence of a function's
526 documentation string as an imperative--for instance, use ``Return the
527 cons of A and B.'' in preference to ``Returns the cons of A and B@.''
528 Usually it looks good to do likewise for the rest of the first
529 paragraph. Subsequent paragraphs usually look better if each sentence
530 is indicative and has a proper subject.
533 Write documentation strings in the active voice, not the passive, and in
534 the present tense, not the future. For instance, use ``Return a list
535 containing A and B.'' instead of ``A list containing A and B will be
539 Avoid using the word ``cause'' (or its equivalents) unnecessarily.
540 Instead of, ``Cause Emacs to display text in boldface,'' write just
541 ``Display text in boldface.''
544 When a command is meaningful only in a certain mode or situation,
545 do mention that in the documentation string. For example,
546 the documentation of @code{dired-find-file} is:
549 In Dired, visit the file or directory named on this line.
553 Do not start or end a documentation string with whitespace.
556 @strong{Do not} indent subsequent lines of a documentation string so
557 that the text is lined up in the source code with the text of the first
558 line. This looks nice in the source code, but looks bizarre when users
559 view the documentation. Remember that the indentation before the
560 starting double-quote is not part of the string!
563 When the user tries to use a disabled command, Emacs displays just the
564 first paragraph of its documentation string---everything through the
565 first blank line. If you wish, you can choose which information to
566 include before the first blank line so as to make this display useful.
569 A variable's documentation string should start with @samp{*} if the
570 variable is one that users would often want to set interactively. If
571 the value is a long list, or a function, or if the variable would be set
572 only in init files, then don't start the documentation string with
573 @samp{*}. @xref{Defining Variables}.
576 The documentation string for a variable that is a yes-or-no flag should
577 start with words such as ``Non-nil means@dots{}'', to make it clear that
578 all non-@code{nil} values are equivalent and indicate explicitly what
579 @code{nil} and non-@code{nil} mean.
582 The documentation string for a function that is a yes-or-no predicate
583 should start with words such as ``Return t if @dots{}'', to indicate
584 explicitly what constitutes ``truth''. The word ``return'' avoids
585 starting the sentence with lower-case ``t'', which is somewhat
589 When a function's documentation string mentions the value of an argument
590 of the function, use the argument name in capital letters as if it were
591 a name for that value. Thus, the documentation string of the function
592 @code{eval} refers to its second argument as @samp{FORM}, because the
593 actual argument name is @code{form}:
596 Evaluate FORM and return its value.
599 Also write metasyntactic variables in capital letters, such as when you
600 show the decomposition of a list or vector into subunits, some of which
601 may vary. @samp{KEY} and @samp{VALUE} in the following example
602 illustrate this practice:
605 The argument TABLE should be an alist whose elements
606 have the form (KEY . VALUE). Here, KEY is ...
610 Never change the case of a Lisp symbol when you mention it in a doc
611 string. If the symbol's name is @code{foo}, write ``foo'', not
612 ``Foo'' (which is a different symbol).
614 This might appear to contradict the policy of writing function
615 argument values, but there is no real contradiction; the argument
616 @emph{value} is not the same thing as the @emph{symbol} which the
617 function uses to hold the value.
619 If this puts a lower-case letter at the beginning of a sentence
620 and that annoys you, rewrite the sentence so that the symbol
621 is not at the start of it.
624 If a line in a documentation string begins with an open-parenthesis,
625 write a backslash before the open-parenthesis, like this:
628 The argument FOO can be either a number
629 \(a buffer position) or a string (a file name).
632 This prevents the open-parenthesis from being treated as the start of a
633 defun (@pxref{Defuns,, Defuns, emacs, The GNU Emacs Manual}).
637 When a documentation string refers to a Lisp symbol, write it as it
638 would be printed (which usually means in lower case), with single-quotes
639 around it. For example: @samp{`lambda'}. There are two exceptions:
640 write @code{t} and @code{nil} without single-quotes.
643 When a documentation string refers to a Lisp symbol, write it as it
644 would be printed (which usually means in lower case), with single-quotes
645 around it. For example: @samp{lambda}. There are two exceptions: write
646 t and nil without single-quotes. (In this manual, we use a different
647 convention, with single-quotes for all symbols.)
650 Help mode automatically creates a hyperlink when a documentation string
651 uses a symbol name inside single quotes, if the symbol has either a
652 function or a variable definition. You do not need to do anything
653 special to make use of this feature. However, when a symbol has both a
654 function definition and a variable definition, and you want to refer to
655 just one of them, you can specify which one by writing one of the words
656 @samp{variable}, @samp{option}, @samp{function}, or @samp{command},
657 immediately before the symbol name. (Case makes no difference in
658 recognizing these indicator words.) For example, if you write
661 This function sets the variable `buffer-file-name'.
665 then the hyperlink will refer only to the variable documentation of
666 @code{buffer-file-name}, and not to its function documentation.
668 If a symbol has a function definition and/or a variable definition, but
669 those are irrelevant to the use of the symbol that you are documenting,
670 you can write the word @samp{symbol} before the symbol name to prevent
671 making any hyperlink. For example,
674 If the argument KIND-OF-RESULT is the symbol `list',
675 this function returns a list of all the objects
676 that satisfy the criterion.
680 does not make a hyperlink to the documentation, irrelevant here, of the
681 function @code{list}.
683 To make a hyperlink to Info documentation, write the name of the Info
684 node in single quotes, preceded by @samp{info node} or @samp{Info
685 node}. The Info file name defaults to @samp{emacs}. For example,
688 See Info node `Font Lock' and Info node `(elisp)Font Lock Basics'.
692 Don't write key sequences directly in documentation strings. Instead,
693 use the @samp{\\[@dots{}]} construct to stand for them. For example,
694 instead of writing @samp{C-f}, write the construct
695 @samp{\\[forward-char]}. When Emacs displays the documentation string,
696 it substitutes whatever key is currently bound to @code{forward-char}.
697 (This is normally @samp{C-f}, but it may be some other character if the
698 user has moved key bindings.) @xref{Keys in Documentation}.
701 In documentation strings for a major mode, you will want to refer to the
702 key bindings of that mode's local map, rather than global ones.
703 Therefore, use the construct @samp{\\<@dots{}>} once in the
704 documentation string to specify which key map to use. Do this before
705 the first use of @samp{\\[@dots{}]}. The text inside the
706 @samp{\\<@dots{}>} should be the name of the variable containing the
707 local keymap for the major mode.
709 It is not practical to use @samp{\\[@dots{}]} very many times, because
710 display of the documentation string will become slow. So use this to
711 describe the most important commands in your major mode, and then use
712 @samp{\\@{@dots{}@}} to display the rest of the mode's keymap.
716 @section Tips on Writing Comments
718 We recommend these conventions for where to put comments and how to
723 Comments that start with a single semicolon, @samp{;}, should all be
724 aligned to the same column on the right of the source code. Such
725 comments usually explain how the code on the same line does its job. In
726 Lisp mode and related modes, the @kbd{M-;} (@code{indent-for-comment})
727 command automatically inserts such a @samp{;} in the right place, or
728 aligns such a comment if it is already present.
730 This and following examples are taken from the Emacs sources.
734 (setq base-version-list ; there was a base
735 (assoc (substring fn 0 start-vn) ; version to which
736 file-version-assoc-list)) ; this looks like
742 Comments that start with two semicolons, @samp{;;}, should be aligned to
743 the same level of indentation as the code. Such comments usually
744 describe the purpose of the following lines or the state of the program
745 at that point. For example:
749 (prog1 (setq auto-fill-function
753 (force-mode-line-update)))
757 We also normally use two semicolons for comments outside functions.
761 ;; This Lisp code is run in Emacs
762 ;; when it is to operate as a server
763 ;; for other processes.
767 Every function that has no documentation string (presumably one that is
768 used only internally within the package it belongs to), should instead
769 have a two-semicolon comment right before the function, explaining what
770 the function does and how to call it properly. Explain precisely what
771 each argument means and how the function interprets its possible values.
774 Comments that start with three semicolons, @samp{;;;}, should start at
775 the left margin. These are used, occasionally, for comments within
776 functions that should start at the margin. We also use them sometimes
777 for comments that are between functions---whether to use two or three
778 semicolons there is a matter of style.
780 Another use for triple-semicolon comments is for commenting out lines
781 within a function. We use three semicolons for this precisely so that
782 they remain at the left margin.
786 ;;; This is no longer necessary.
787 ;;; (force-mode-line-update)
788 (message "Finished with %s" a))
792 Comments that start with four semicolons, @samp{;;;;}, should be aligned
793 to the left margin and are used for headings of major sections of a
794 program. For example:
802 The indentation commands of the Lisp modes in Emacs, such as @kbd{M-;}
803 (@code{indent-for-comment}) and @key{TAB} (@code{lisp-indent-line}),
804 automatically indent comments according to these conventions,
805 depending on the number of semicolons. @xref{Comments,,
806 Manipulating Comments, emacs, The GNU Emacs Manual}.
808 @node Library Headers
809 @section Conventional Headers for Emacs Libraries
810 @cindex header comments
811 @cindex library header comments
813 Emacs has conventions for using special comments in Lisp libraries
814 to divide them into sections and give information such as who wrote
815 them. This section explains these conventions.
817 We'll start with an example, a package that is included in the Emacs
820 Parts of this example reflect its status as part of Emacs; for
821 example, the copyright notice lists the Free Software Foundation as the
822 copyright holder, and the copying permission says the file is part of
823 Emacs. When you write a package and post it, the copyright holder would
824 be you (unless your employer claims to own it instead), and you should
825 get the suggested copying permission from the end of the GNU General
826 Public License itself. Don't say your file is part of Emacs
827 if we haven't installed it in Emacs yet!
829 With that warning out of the way, on to the example:
833 ;;; lisp-mnt.el --- minor mode for Emacs Lisp maintainers
835 ;; Copyright (C) 1992 Free Software Foundation, Inc.
838 ;; Author: Eric S. Raymond <esr@@snark.thyrsus.com>
839 ;; Maintainer: Eric S. Raymond <esr@@snark.thyrsus.com>
840 ;; Created: 14 Jul 1992
845 ;; This file is part of GNU Emacs.
847 ;; Free Software Foundation, Inc., 59 Temple Place - Suite 330,
848 ;; Boston, MA 02111-1307, USA.
852 The very first line should have this format:
855 ;;; @var{filename} --- @var{description}
859 The description should be complete in one line. If the file
860 needs a @samp{-*-} specification, put it after @var{description}.
862 After the copyright notice come several @dfn{header comment} lines,
863 each beginning with @samp{;; @var{header-name}:}. Here is a table of
864 the conventional possibilities for @var{header-name}:
868 This line states the name and net address of at least the principal
869 author of the library.
871 If there are multiple authors, you can list them on continuation lines
872 led by @code{;;} and a tab character, like this:
876 ;; Author: Ashwin Ram <Ram-Ashwin@@cs.yale.edu>
877 ;; Dave Sill <de5@@ornl.gov>
878 ;; Dave Brennan <brennan@@hal.com>
879 ;; Eric Raymond <esr@@snark.thyrsus.com>
884 This line should contain a single name/address as in the Author line, or
885 an address only, or the string @samp{FSF}. If there is no maintainer
886 line, the person(s) in the Author field are presumed to be the
887 maintainers. The example above is mildly bogus because the maintainer
890 The idea behind the @samp{Author} and @samp{Maintainer} lines is to make
891 possible a Lisp function to ``send mail to the maintainer'' without
892 having to mine the name out by hand.
894 Be sure to surround the network address with @samp{<@dots{}>} if
895 you include the person's full name as well as the network address.
898 This optional line gives the original creation date of the
899 file. For historical interest only.
902 If you wish to record version numbers for the individual Lisp program, put
906 In this header line, place the name of the person who adapted the
907 library for installation (to make it fit the style conventions, for
911 This line lists keywords for the @code{finder-by-keyword} help command.
912 Please use that command to see a list of the meaningful keywords.
914 This field is important; it's how people will find your package when
915 they're looking for things by topic area. To separate the keywords, you
916 can use spaces, commas, or both.
919 Just about every Lisp library ought to have the @samp{Author} and
920 @samp{Keywords} header comment lines. Use the others if they are
921 appropriate. You can also put in header lines with other header
922 names---they have no standard meanings, so they can't do any harm.
924 We use additional stylized comments to subdivide the contents of the
925 library file. These should be separated by blank lines from anything
926 else. Here is a table of them:
929 @item ;;; Commentary:
930 This begins introductory comments that explain how the library works.
931 It should come right after the copying permissions, terminated by a
932 @samp{Change Log}, @samp{History} or @samp{Code} comment line. This
933 text is used by the Finder package, so it should make sense in that
936 @item ;;; Documentation
937 This has been used in some files in place of @samp{;;; Commentary:},
938 but @samp{;;; Commentary:} is preferred.
940 @item ;;; Change Log:
941 This begins change log information stored in the library file (if you
942 store the change history there). For Lisp files distributed with Emacs,
943 the change history is kept in the file @file{ChangeLog} and not in the
944 source file at all; these files generally do not have a @samp{;;; Change
945 Log:} line. @samp{History} is an alternative to @samp{Change Log}.
948 This begins the actual code of the program.
950 @item ;;; @var{filename} ends here
951 This is the @dfn{footer line}; it appears at the very end of the file.
952 Its purpose is to enable people to detect truncated versions of the file
953 from the lack of a footer line.
957 arch-tag: 9ea911c2-6b1d-47dd-88b7-0a94e8b27c2e