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