| 1 | @c -*-texinfo-*- |
| 2 | @c This is part of the GNU Emacs Lisp Reference Manual. |
| 3 | @c Copyright (C) 1990, 1991, 1992, 1993 Free Software Foundation, Inc. |
| 4 | @c See the file elisp.texi for copying conditions. |
| 5 | @setfilename ../info/tips |
| 6 | @node Tips, GNU Emacs Internals, Calendar, Top |
| 7 | @appendix Tips and Conventions |
| 8 | @cindex tips |
| 9 | @cindex standards of coding style |
| 10 | @cindex coding standards |
| 11 | |
| 12 | This chapter describes no additional features of Emacs Lisp. Instead |
| 13 | it gives advice on making effective use of the features described in the |
| 14 | previous chapters, and describes conventions Emacs Lisp programmers |
| 15 | should follow. |
| 16 | |
| 17 | @menu |
| 18 | * Coding Conventions:: Conventions for clean and robust programs. |
| 19 | * Compilation Tips:: Making compiled code run fast. |
| 20 | * Documentation Tips:: Writing readable documentation strings. |
| 21 | * Comment Tips:: Conventions for writing comments. |
| 22 | * Library Headers:: Standard headers for library packages. |
| 23 | @end menu |
| 24 | |
| 25 | @node Coding Conventions |
| 26 | @section Emacs Lisp Coding Conventions |
| 27 | |
| 28 | Here are conventions that you should follow when writing Emacs Lisp |
| 29 | code intended for widespread use: |
| 30 | |
| 31 | @itemize @bullet |
| 32 | @item |
| 33 | Since all global variables share the same name space, and all functions |
| 34 | share another name space, you should choose a short word to distinguish |
| 35 | your program from other Lisp programs. Then take care to begin the |
| 36 | names of all global variables, constants, and functions with the chosen |
| 37 | prefix. This helps avoid name conflicts. |
| 38 | |
| 39 | This recommendation applies even to names for traditional Lisp |
| 40 | primitives that are not primitives in Emacs Lisp---even to @code{cadr}. |
| 41 | Believe it or not, there is more than one plausible way to define |
| 42 | @code{cadr}. Play it safe; append your name prefix to produce a name |
| 43 | like @code{foo-cadr} or @code{mylib-cadr} instead. |
| 44 | |
| 45 | If you write a function that you think ought to be added to Emacs under |
| 46 | a certain name, such as @code{twiddle-files}, don't call it by that name |
| 47 | in your program. Call it @code{mylib-twiddle-files} in your program, |
| 48 | and send mail to @samp{bug-gnu-emacs@@prep.ai.mit.edu} suggesting we add |
| 49 | it to Emacs. If and when we do, we can change the name easily enough. |
| 50 | |
| 51 | If one prefix is insufficient, your package may use two or three |
| 52 | alternative common prefixes, so long as they make sense. |
| 53 | |
| 54 | Separate the prefix from the rest of the symbol name with a hyphen, |
| 55 | @samp{-}. This will be consistent with Emacs itself and with most Emacs |
| 56 | Lisp programs. |
| 57 | |
| 58 | @item |
| 59 | It is often useful to put a call to @code{provide} in each separate |
| 60 | library program, at least if there is more than one entry point to the |
| 61 | program. |
| 62 | |
| 63 | @item |
| 64 | If a file requires certain other library programs to be loaded |
| 65 | beforehand, then the comments at the beginning of the file should say |
| 66 | so. Also, use @code{require} to make sure they are loaded. |
| 67 | |
| 68 | @item |
| 69 | If one file @var{foo} uses a macro defined in another file @var{bar}, |
| 70 | @var{foo} should contain this expression before the first use of the |
| 71 | macro: |
| 72 | |
| 73 | @example |
| 74 | (eval-when-compile (require '@var{bar})) |
| 75 | @end example |
| 76 | |
| 77 | @noindent |
| 78 | (And @var{bar} should contain @code{(provide '@var{bar})}, to make the |
| 79 | @code{require} work.) This will cause @var{bar} to be loaded when you |
| 80 | byte-compile @var{foo}. Otherwise, you risk compiling @var{foo} without |
| 81 | the necessary macro loaded, and that would produce compiled code that |
| 82 | won't work right. @xref{Compiling Macros}. |
| 83 | |
| 84 | Using @code{eval-when-compile} avoids loading @var{bar} when |
| 85 | the compiled version of @var{foo} is @emph{used}. |
| 86 | |
| 87 | @item |
| 88 | When defining a major mode, please follow the major mode |
| 89 | conventions. @xref{Major Mode Conventions}. |
| 90 | |
| 91 | @item |
| 92 | When defining a minor mode, please follow the minor mode |
| 93 | conventions. @xref{Minor Mode Conventions}. |
| 94 | |
| 95 | @item |
| 96 | If the purpose of a function is to tell you whether a certain condition |
| 97 | is true or false, give the function a name that ends in @samp{p}. If |
| 98 | the name is one word, add just @samp{p}; if the name is multiple words, |
| 99 | add @samp{-p}. Examples are @code{framep} and @code{frame-live-p}. |
| 100 | |
| 101 | @item |
| 102 | If a user option variable records a true-or-false condition, give it a |
| 103 | name that ends in @samp{-flag}. |
| 104 | |
| 105 | @item |
| 106 | Please do not define @kbd{C-c @var{letter}} as a key in your major |
| 107 | modes. These sequences are reserved for users; they are the |
| 108 | @strong{only} sequences reserved for users, so we cannot do without |
| 109 | them. |
| 110 | |
| 111 | Instead, define sequences consisting of @kbd{C-c} followed by a control |
| 112 | character, a digit, or certain punctuation characters. These sequences |
| 113 | are reserved for major modes. |
| 114 | |
| 115 | Changing all the major modes in Emacs 18 so they would follow this |
| 116 | convention was a lot of work. Abandoning this convention would make |
| 117 | that work go to waste, and inconvenience users. |
| 118 | |
| 119 | @item |
| 120 | Sequences consisting of @kbd{C-c} followed by @kbd{@{}, @kbd{@}}, |
| 121 | @kbd{<}, @kbd{>}, @kbd{:} or @kbd{;} are also reserved for major modes. |
| 122 | |
| 123 | @item |
| 124 | Sequences consisting of @kbd{C-c} followed by any other punctuation |
| 125 | character are allocated for minor modes. Using them in a major mode is |
| 126 | not absolutely prohibited, but if you do that, the major mode binding |
| 127 | may be shadowed from time to time by minor modes. |
| 128 | |
| 129 | @item |
| 130 | Function keys @key{F5} through @key{F9} without modifier keys are |
| 131 | reserved for users to define. |
| 132 | |
| 133 | @item |
| 134 | You should not bind @kbd{C-h} following any prefix character (including |
| 135 | @kbd{C-c}). If you don't bind @kbd{C-h}, it is automatically available |
| 136 | as a help character for listing the subcommands of the prefix character. |
| 137 | |
| 138 | @item |
| 139 | You should not bind a key sequence ending in @key{ESC} except following |
| 140 | another @key{ESC}. (That is, it is ok to bind a sequence ending in |
| 141 | @kbd{@key{ESC} @key{ESC}}.) |
| 142 | |
| 143 | The reason for this rule is that a non-prefix binding for @key{ESC} in |
| 144 | any context prevents recognition of escape sequences as function keys in |
| 145 | that context. |
| 146 | |
| 147 | @item |
| 148 | Applications should not bind mouse events based on button 1 with the |
| 149 | shift key held down. These events include @kbd{S-mouse-1}, |
| 150 | @kbd{M-S-mouse-1}, @kbd{C-S-mouse-1}, and so on. They are reserved for |
| 151 | users. |
| 152 | |
| 153 | @item |
| 154 | Modes should redefine @kbd{mouse-2} as a command to follow some sort of |
| 155 | reference in the text of a buffer, if users usually would not want to |
| 156 | alter the text in that buffer by hand. Modes such as Dired, Info, |
| 157 | Compilation, and Occur redefine it in this way. |
| 158 | |
| 159 | @item |
| 160 | When a package provides a modification of ordinary Emacs behavior, it is |
| 161 | good to include a command to enable and disable the feature, Provide a |
| 162 | command named @code{@var{whatever}-mode} which turns the feature on or |
| 163 | off, and make it autoload (@pxref{Autoload}). Design the package so |
| 164 | that simply loading it has no visible effect---that should not enable |
| 165 | the feature. Users will request the feature by invoking the command. |
| 166 | |
| 167 | @item |
| 168 | It is a bad idea to define aliases for the Emacs primitives. Use the |
| 169 | standard names instead. |
| 170 | |
| 171 | @item |
| 172 | Redefining (or advising) an Emacs primitive is discouraged. It may do |
| 173 | the right thing for a particular program, but there is no telling what |
| 174 | other programs might break as a result. |
| 175 | |
| 176 | @item |
| 177 | If a file does replace any of the functions or library programs of |
| 178 | standard Emacs, prominent comments at the beginning of the file should |
| 179 | say which functions are replaced, and how the behavior of the |
| 180 | replacements differs from that of the originals. |
| 181 | |
| 182 | @item |
| 183 | Please keep the names of your Emacs Lisp source files to 13 characters |
| 184 | or less. This way, if the files are compiled, the compiled files' names |
| 185 | will be 14 characters or less, which is short enough to fit on all kinds |
| 186 | of Unix systems. |
| 187 | |
| 188 | @item |
| 189 | Don't use @code{next-line} or @code{previous-line} in programs; nearly |
| 190 | always, @code{forward-line} is more convenient as well as more |
| 191 | predictable and robust. @xref{Text Lines}. |
| 192 | |
| 193 | @item |
| 194 | Don't call functions that set the mark, unless setting the mark is one |
| 195 | of the intended features of your program. The mark is a user-level |
| 196 | feature, so it is incorrect to change the mark except to supply a value |
| 197 | for the user's benefit. @xref{The Mark}. |
| 198 | |
| 199 | In particular, don't use these functions: |
| 200 | |
| 201 | @itemize @bullet |
| 202 | @item |
| 203 | @code{beginning-of-buffer}, @code{end-of-buffer} |
| 204 | @item |
| 205 | @code{replace-string}, @code{replace-regexp} |
| 206 | @end itemize |
| 207 | |
| 208 | If you just want to move point, or replace a certain string, without any |
| 209 | of the other features intended for interactive users, you can replace |
| 210 | these functions with one or two lines of simple Lisp code. |
| 211 | |
| 212 | @item |
| 213 | Use lists rather than vectors, except when there is a particular reason |
| 214 | to use a vector. Lisp has more facilities for manipulating lists than |
| 215 | for vectors, and working with lists is usually more convenient. |
| 216 | |
| 217 | Vectors are advantageous for tables that are substantial in size and are |
| 218 | accessed in random order (not searched front to back), provided there is |
| 219 | no need to insert or delete elements (only lists allow that). |
| 220 | |
| 221 | @item |
| 222 | The recommended way to print a message in the echo area is with |
| 223 | the @code{message} function, not @code{princ}. @xref{The Echo Area}. |
| 224 | |
| 225 | @item |
| 226 | When you encounter an error condition, call the function @code{error} |
| 227 | (or @code{signal}). The function @code{error} does not return. |
| 228 | @xref{Signaling Errors}. |
| 229 | |
| 230 | Do not use @code{message}, @code{throw}, @code{sleep-for}, |
| 231 | or @code{beep} to report errors. |
| 232 | |
| 233 | @item |
| 234 | An error message should start with a capital letter but should not end |
| 235 | with a period. |
| 236 | |
| 237 | @item |
| 238 | Many commands that take a long time to execute display a message that |
| 239 | says @samp{Operating...} when they start, and change it to |
| 240 | @samp{Operating...done} when they finish. Please keep the style of |
| 241 | these messages uniform: @emph{no} space around the ellipsis, and |
| 242 | @emph{no} period at the end. |
| 243 | |
| 244 | @item |
| 245 | Try to avoid using recursive edits. Instead, do what the Rmail @kbd{e} |
| 246 | command does: use a new local keymap that contains one command defined |
| 247 | to switch back to the old local keymap. Or do what the |
| 248 | @code{edit-options} command does: switch to another buffer and let the |
| 249 | user switch back at will. @xref{Recursive Editing}. |
| 250 | |
| 251 | @item |
| 252 | In some other systems there is a convention of choosing variable names |
| 253 | that begin and end with @samp{*}. We don't use that convention in Emacs |
| 254 | Lisp, so please don't use it in your programs. (Emacs uses such names |
| 255 | only for program-generated buffers.) The users will find Emacs more |
| 256 | coherent if all libraries use the same conventions. |
| 257 | |
| 258 | @item |
| 259 | Try to avoid compiler warnings about undefined free variables, by adding |
| 260 | @code{defvar} definitions for these variables. |
| 261 | |
| 262 | If you bind a variable in one function, and use it or set it in another |
| 263 | function, the compiler warns about the latter function unless the |
| 264 | variable has a definition. But often these variables have short names, |
| 265 | and it is not clean for Lisp packages to define such variables names. |
| 266 | Therefore, you should rename the variable to start with the name prefix |
| 267 | used for the other functions and variables in your package. |
| 268 | |
| 269 | @item |
| 270 | Indent each function with @kbd{C-M-q} (@code{indent-sexp}) using the |
| 271 | default indentation parameters. |
| 272 | |
| 273 | @item |
| 274 | Don't make a habit of putting close-parentheses on lines by themselves; |
| 275 | Lisp programmers find this disconcerting. Once in a while, when there |
| 276 | is a sequence of many consecutive close-parentheses, it may make sense |
| 277 | to split them in one or two significant places. |
| 278 | |
| 279 | @item |
| 280 | Please put a copyright notice on the file if you give copies to anyone. |
| 281 | Use the same lines that appear at the top of the Lisp files in Emacs |
| 282 | itself. If you have not signed papers to assign the copyright to the |
| 283 | Foundation, then place your name in the copyright notice in place of the |
| 284 | Foundation's name. |
| 285 | @end itemize |
| 286 | |
| 287 | @node Compilation Tips |
| 288 | @section Tips for Making Compiled Code Fast |
| 289 | @cindex execution speed |
| 290 | @cindex speedups |
| 291 | |
| 292 | Here are ways of improving the execution speed of byte-compiled |
| 293 | Lisp programs. |
| 294 | |
| 295 | @itemize @bullet |
| 296 | @item |
| 297 | @cindex profiling |
| 298 | @cindex timing programs |
| 299 | @cindex @file{profile.el} |
| 300 | Use the @file{profile} library to profile your program. See the file |
| 301 | @file{profile.el} for instructions. |
| 302 | |
| 303 | @item |
| 304 | Use iteration rather than recursion whenever possible. |
| 305 | Function calls are slow in Emacs Lisp even when a compiled function |
| 306 | is calling another compiled function. |
| 307 | |
| 308 | @item |
| 309 | Using the primitive list-searching functions @code{memq}, @code{member}, |
| 310 | @code{assq}, or @code{assoc} is even faster than explicit iteration. It |
| 311 | may be worth rearranging a data structure so that one of these primitive |
| 312 | search functions can be used. |
| 313 | |
| 314 | @item |
| 315 | Certain built-in functions are handled specially in byte-compiled code, |
| 316 | avoiding the need for an ordinary function call. It is a good idea to |
| 317 | use these functions rather than alternatives. To see whether a function |
| 318 | is handled specially by the compiler, examine its @code{byte-compile} |
| 319 | property. If the property is non-@code{nil}, then the function is |
| 320 | handled specially. |
| 321 | |
| 322 | For example, the following input will show you that @code{aref} is |
| 323 | compiled specially (@pxref{Array Functions}) while @code{elt} is not |
| 324 | (@pxref{Sequence Functions}): |
| 325 | |
| 326 | @example |
| 327 | @group |
| 328 | (get 'aref 'byte-compile) |
| 329 | @result{} byte-compile-two-args |
| 330 | @end group |
| 331 | |
| 332 | @group |
| 333 | (get 'elt 'byte-compile) |
| 334 | @result{} nil |
| 335 | @end group |
| 336 | @end example |
| 337 | |
| 338 | @item |
| 339 | If calling a small function accounts for a substantial part of your |
| 340 | program's running time, make the function inline. This eliminates |
| 341 | the function call overhead. Since making a function inline reduces |
| 342 | the flexibility of changing the program, don't do it unless it gives |
| 343 | a noticeable speedup in something slow enough that users care about |
| 344 | the speed. @xref{Inline Functions}. |
| 345 | @end itemize |
| 346 | |
| 347 | @node Documentation Tips |
| 348 | @section Tips for Documentation Strings |
| 349 | |
| 350 | Here are some tips for the writing of documentation strings. |
| 351 | |
| 352 | @itemize @bullet |
| 353 | @item |
| 354 | Every command, function, or variable intended for users to know about |
| 355 | should have a documentation string. |
| 356 | |
| 357 | @item |
| 358 | An internal variable or subroutine of a Lisp program might as well have |
| 359 | a documentation string. In earlier Emacs versions, you could save space |
| 360 | by using a comment instead of a documentation string, but that is no |
| 361 | longer the case. |
| 362 | |
| 363 | @item |
| 364 | The first line of the documentation string should consist of one or two |
| 365 | complete sentences that stand on their own as a summary. @kbd{M-x |
| 366 | apropos} displays just the first line, and if it doesn't stand on its |
| 367 | own, the result looks bad. In particular, start the first line with a |
| 368 | capital letter and end with a period. |
| 369 | |
| 370 | The documentation string can have additional lines that expand on the |
| 371 | details of how to use the function or variable. The additional lines |
| 372 | should be made up of complete sentences also, but they may be filled if |
| 373 | that looks good. |
| 374 | |
| 375 | @item |
| 376 | For consistency, phrase the verb in the first sentence of a |
| 377 | documentation string as an infinitive with ``to'' omitted. For |
| 378 | instance, use ``Return the cons of A and B.'' in preference to ``Returns |
| 379 | the cons of A and B@.'' Usually it looks good to do likewise for the |
| 380 | rest of the first paragraph. Subsequent paragraphs usually look better |
| 381 | if they have proper subjects. |
| 382 | |
| 383 | @item |
| 384 | Write documentation strings in the active voice, not the passive, and in |
| 385 | the present tense, not the future. For instance, use ``Return a list |
| 386 | containing A and B.'' instead of ``A list containing A and B will be |
| 387 | returned.'' |
| 388 | |
| 389 | @item |
| 390 | Avoid using the word ``cause'' (or its equivalents) unnecessarily. |
| 391 | Instead of, ``Cause Emacs to display text in boldface,'' write just |
| 392 | ``Display text in boldface.'' |
| 393 | |
| 394 | @item |
| 395 | Do not start or end a documentation string with whitespace. |
| 396 | |
| 397 | @item |
| 398 | Format the documentation string so that it fits in an Emacs window on an |
| 399 | 80-column screen. It is a good idea for most lines to be no wider than |
| 400 | 60 characters. The first line can be wider if necessary to fit the |
| 401 | information that ought to be there. |
| 402 | |
| 403 | However, rather than simply filling the entire documentation string, you |
| 404 | can make it much more readable by choosing line breaks with care. |
| 405 | Use blank lines between topics if the documentation string is long. |
| 406 | |
| 407 | @item |
| 408 | @strong{Do not} indent subsequent lines of a documentation string so |
| 409 | that the text is lined up in the source code with the text of the first |
| 410 | line. This looks nice in the source code, but looks bizarre when users |
| 411 | view the documentation. Remember that the indentation before the |
| 412 | starting double-quote is not part of the string! |
| 413 | |
| 414 | @item |
| 415 | When the user tries to use a disabled command, Emacs displays just the |
| 416 | first paragraph of its documentation string---everything through the |
| 417 | first blank line. If you wish, you can choose which information to |
| 418 | include before the first blank line so as to make this display useful. |
| 419 | |
| 420 | @item |
| 421 | A variable's documentation string should start with @samp{*} if the |
| 422 | variable is one that users would often want to set interactively. If |
| 423 | the value is a long list, or a function, or if the variable would be set |
| 424 | only in init files, then don't start the documentation string with |
| 425 | @samp{*}. @xref{Defining Variables}. |
| 426 | |
| 427 | @item |
| 428 | The documentation string for a variable that is a yes-or-no flag should |
| 429 | start with words such as ``Non-nil means@dots{}'', to make it clear that |
| 430 | all non-@code{nil} values are equivalent and indicate explicitly what |
| 431 | @code{nil} and non-@code{nil} mean. |
| 432 | |
| 433 | @item |
| 434 | When a function's documentation string mentions the value of an argument |
| 435 | of the function, use the argument name in capital letters as if it were |
| 436 | a name for that value. Thus, the documentation string of the function |
| 437 | @code{/} refers to its second argument as @samp{DIVISOR}, because the |
| 438 | actual argument name is @code{divisor}. |
| 439 | |
| 440 | Also use all caps for meta-syntactic variables, such as when you show |
| 441 | the decomposition of a list or vector into subunits, some of which may |
| 442 | vary. |
| 443 | |
| 444 | @item |
| 445 | @iftex |
| 446 | When a documentation string refers to a Lisp symbol, write it as it |
| 447 | would be printed (which usually means in lower case), with single-quotes |
| 448 | around it. For example: @samp{`lambda'}. There are two exceptions: |
| 449 | write @code{t} and @code{nil} without single-quotes. |
| 450 | @end iftex |
| 451 | @ifinfo |
| 452 | When a documentation string refers to a Lisp symbol, write it as it |
| 453 | would be printed (which usually means in lower case), with single-quotes |
| 454 | around it. For example: @samp{lambda}. There are two exceptions: write |
| 455 | t and nil without single-quotes. (In this manual, we normally do use |
| 456 | single-quotes for those symbols.) |
| 457 | @end ifinfo |
| 458 | |
| 459 | @item |
| 460 | Don't write key sequences directly in documentation strings. Instead, |
| 461 | use the @samp{\\[@dots{}]} construct to stand for them. For example, |
| 462 | instead of writing @samp{C-f}, write the construct |
| 463 | @samp{\\[forward-char]}. When Emacs displays the documentation string, |
| 464 | it substitutes whatever key is currently bound to @code{forward-char}. |
| 465 | (This is normally @samp{C-f}, but it may be some other character if the |
| 466 | user has moved key bindings.) @xref{Keys in Documentation}. |
| 467 | |
| 468 | @item |
| 469 | In documentation strings for a major mode, you will want to refer to the |
| 470 | key bindings of that mode's local map, rather than global ones. |
| 471 | Therefore, use the construct @samp{\\<@dots{}>} once in the |
| 472 | documentation string to specify which key map to use. Do this before |
| 473 | the first use of @samp{\\[@dots{}]}. The text inside the |
| 474 | @samp{\\<@dots{}>} should be the name of the variable containing the |
| 475 | local keymap for the major mode. |
| 476 | |
| 477 | It is not practical to use @samp{\\[@dots{}]} very many times, because |
| 478 | display of the documentation string will become slow. So use this to |
| 479 | describe the most important commands in your major mode, and then use |
| 480 | @samp{\\@{@dots{}@}} to display the rest of the mode's keymap. |
| 481 | @end itemize |
| 482 | |
| 483 | @node Comment Tips |
| 484 | @section Tips on Writing Comments |
| 485 | |
| 486 | We recommend these conventions for where to put comments and how to |
| 487 | indent them: |
| 488 | |
| 489 | @table @samp |
| 490 | @item ; |
| 491 | Comments that start with a single semicolon, @samp{;}, should all be |
| 492 | aligned to the same column on the right of the source code. Such |
| 493 | comments usually explain how the code on the same line does its job. In |
| 494 | Lisp mode and related modes, the @kbd{M-;} (@code{indent-for-comment}) |
| 495 | command automatically inserts such a @samp{;} in the right place, or |
| 496 | aligns such a comment if it is already present. |
| 497 | |
| 498 | This and following examples are taken from the Emacs sources. |
| 499 | |
| 500 | @smallexample |
| 501 | @group |
| 502 | (setq base-version-list ; there was a base |
| 503 | (assoc (substring fn 0 start-vn) ; version to which |
| 504 | file-version-assoc-list)) ; this looks like |
| 505 | ; a subversion |
| 506 | @end group |
| 507 | @end smallexample |
| 508 | |
| 509 | @item ;; |
| 510 | Comments that start with two semicolons, @samp{;;}, should be aligned to |
| 511 | the same level of indentation as the code. Such comments usually |
| 512 | describe the purpose of the following lines or the state of the program |
| 513 | at that point. For example: |
| 514 | |
| 515 | @smallexample |
| 516 | @group |
| 517 | (prog1 (setq auto-fill-function |
| 518 | @dots{} |
| 519 | @dots{} |
| 520 | ;; update mode line |
| 521 | (force-mode-line-update))) |
| 522 | @end group |
| 523 | @end smallexample |
| 524 | |
| 525 | Every function that has no documentation string (because it is use only |
| 526 | internally within the package it belongs to), should have instead a |
| 527 | two-semicolon comment right before the function, explaining what the |
| 528 | function does and how to call it properly. Explain precisely what each |
| 529 | argument means and how the function interprets its possible values. |
| 530 | |
| 531 | @item ;;; |
| 532 | Comments that start with three semicolons, @samp{;;;}, should start at |
| 533 | the left margin. Such comments are used outside function definitions to |
| 534 | make general statements explaining the design principles of the program. |
| 535 | For example: |
| 536 | |
| 537 | @smallexample |
| 538 | @group |
| 539 | ;;; This Lisp code is run in Emacs |
| 540 | ;;; when it is to operate as a server |
| 541 | ;;; for other processes. |
| 542 | @end group |
| 543 | @end smallexample |
| 544 | |
| 545 | Another use for triple-semicolon comments is for commenting out lines |
| 546 | within a function. We use triple-semicolons for this precisely so that |
| 547 | they remain at the left margin. |
| 548 | |
| 549 | @smallexample |
| 550 | (defun foo (a) |
| 551 | ;;; This is no longer necessary. |
| 552 | ;;; (force-mode-line-update) |
| 553 | (message "Finished with %s" a)) |
| 554 | @end smallexample |
| 555 | |
| 556 | @item ;;;; |
| 557 | Comments that start with four semicolons, @samp{;;;;}, should be aligned |
| 558 | to the left margin and are used for headings of major sections of a |
| 559 | program. For example: |
| 560 | |
| 561 | @smallexample |
| 562 | ;;;; The kill ring |
| 563 | @end smallexample |
| 564 | @end table |
| 565 | |
| 566 | @noindent |
| 567 | The indentation commands of the Lisp modes in Emacs, such as @kbd{M-;} |
| 568 | (@code{indent-for-comment}) and @key{TAB} (@code{lisp-indent-line}) |
| 569 | automatically indent comments according to these conventions, |
| 570 | depending on the number of semicolons. @xref{Comments,, |
| 571 | Manipulating Comments, emacs, The GNU Emacs Manual}. |
| 572 | |
| 573 | @node Library Headers |
| 574 | @section Conventional Headers for Emacs Libraries |
| 575 | @cindex header comments |
| 576 | @cindex library header comments |
| 577 | |
| 578 | Emacs 19 has conventions for using special comments in Lisp libraries |
| 579 | to divide them into sections and give information such as who wrote |
| 580 | them. This section explains these conventions. First, an example: |
| 581 | |
| 582 | @smallexample |
| 583 | @group |
| 584 | ;;; lisp-mnt.el --- minor mode for Emacs Lisp maintainers |
| 585 | |
| 586 | ;; Copyright (C) 1992 Free Software Foundation, Inc. |
| 587 | @end group |
| 588 | |
| 589 | ;; Author: Eric S. Raymond <esr@@snark.thyrsus.com> |
| 590 | ;; Maintainer: Eric S. Raymond <esr@@snark.thyrsus.com> |
| 591 | ;; Created: 14 Jul 1992 |
| 592 | ;; Version: 1.2 |
| 593 | @group |
| 594 | ;; Keywords: docs |
| 595 | |
| 596 | ;; This file is part of GNU Emacs. |
| 597 | @var{copying permissions}@dots{} |
| 598 | @end group |
| 599 | @end smallexample |
| 600 | |
| 601 | The very first line should have this format: |
| 602 | |
| 603 | @example |
| 604 | ;;; @var{filename} --- @var{description} |
| 605 | @end example |
| 606 | |
| 607 | @noindent |
| 608 | The description should be complete in one line. |
| 609 | |
| 610 | After the copyright notice come several @dfn{header comment} lines, |
| 611 | each beginning with @samp{;; @var{header-name}:}. Here is a table of |
| 612 | the conventional possibilities for @var{header-name}: |
| 613 | |
| 614 | @table @samp |
| 615 | @item Author |
| 616 | This line states the name and net address of at least the principal |
| 617 | author of the library. |
| 618 | |
| 619 | If there are multiple authors, you can list them on continuation lines |
| 620 | led by @code{;;} and a tab character, like this: |
| 621 | |
| 622 | @smallexample |
| 623 | @group |
| 624 | ;; Author: Ashwin Ram <Ram-Ashwin@@cs.yale.edu> |
| 625 | ;; Dave Sill <de5@@ornl.gov> |
| 626 | ;; Dave Brennan <brennan@@hal.com> |
| 627 | ;; Eric Raymond <esr@@snark.thyrsus.com> |
| 628 | @end group |
| 629 | @end smallexample |
| 630 | |
| 631 | @item Maintainer |
| 632 | This line should contain a single name/address as in the Author line, or |
| 633 | an address only, or the string @samp{FSF}. If there is no maintainer |
| 634 | line, the person(s) in the Author field are presumed to be the |
| 635 | maintainers. The example above is mildly bogus because the maintainer |
| 636 | line is redundant. |
| 637 | |
| 638 | The idea behind the @samp{Author} and @samp{Maintainer} lines is to make |
| 639 | possible a Lisp function to ``send mail to the maintainer'' without |
| 640 | having to mine the name out by hand. |
| 641 | |
| 642 | Be sure to surround the network address with @samp{<@dots{}>} if |
| 643 | you include the person's full name as well as the network address. |
| 644 | |
| 645 | @item Created |
| 646 | This optional line gives the original creation date of the |
| 647 | file. For historical interest only. |
| 648 | |
| 649 | @item Version |
| 650 | If you wish to record version numbers for the individual Lisp program, put |
| 651 | them in this line. |
| 652 | |
| 653 | @item Adapted-By |
| 654 | In this header line, place the name of the person who adapted the |
| 655 | library for installation (to make it fit the style conventions, for |
| 656 | example). |
| 657 | |
| 658 | @item Keywords |
| 659 | This line lists keywords for the @code{finder-by-keyword} help command. |
| 660 | This field is important; it's how people will find your package when |
| 661 | they're looking for things by topic area. To separate the keywords, you |
| 662 | can use spaces, commas, or both. |
| 663 | @end table |
| 664 | |
| 665 | Just about every Lisp library ought to have the @samp{Author} and |
| 666 | @samp{Keywords} header comment lines. Use the others if they are |
| 667 | appropriate. You can also put in header lines with other header |
| 668 | names---they have no standard meanings, so they can't do any harm. |
| 669 | |
| 670 | We use additional stylized comments to subdivide the contents of the |
| 671 | library file. Here is a table of them: |
| 672 | |
| 673 | @table @samp |
| 674 | @item ;;; Commentary: |
| 675 | This begins introductory comments that explain how the library works. |
| 676 | It should come right after the copying permissions. |
| 677 | |
| 678 | @item ;;; Change log: |
| 679 | This begins change log information stored in the library file (if you |
| 680 | store the change history there). For most of the Lisp |
| 681 | files distributed with Emacs, the change history is kept in the file |
| 682 | @file{ChangeLog} and not in the source file at all; these files do |
| 683 | not have a @samp{;;; Change log:} line. |
| 684 | |
| 685 | @item ;;; Code: |
| 686 | This begins the actual code of the program. |
| 687 | |
| 688 | @item ;;; @var{filename} ends here |
| 689 | This is the @dfn{footer line}; it appears at the very end of the file. |
| 690 | Its purpose is to enable people to detect truncated versions of the file |
| 691 | from the lack of a footer line. |
| 692 | @end table |