Commit | Line | Data |
---|---|---|
b8d4c8d0 GM |
1 | @c -*-texinfo-*- |
2 | @c This is part of the GNU Emacs Lisp Reference Manual. | |
3 | @c Copyright (C) 1990, 1991, 1992, 1993, 1995, 1998, 1999, 2001, 2002, | |
57ebf0be | 4 | @c 2003, 2004, 2005, 2006, 2007, 2008 Free Software Foundation, Inc. |
b8d4c8d0 | 5 | @c See the file elisp.texi for copying conditions. |
6336d8c3 | 6 | @setfilename ../../info/tips |
b8d4c8d0 GM |
7 | @node Tips, GNU Emacs Internals, GPL, Top |
8 | @appendix Tips and Conventions | |
9 | @cindex tips for writing Lisp | |
10 | @cindex standards of coding style | |
11 | @cindex coding standards | |
12 | ||
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 | |
16 | should follow. | |
17 | ||
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 | |
22 | all. | |
23 | ||
24 | @menu | |
25 | * Coding Conventions:: Conventions for clean and robust programs. | |
26 | * Key Binding Conventions:: Which keys should be bound by which programs. | |
27 | * Programming Tips:: Making Emacs code fit smoothly in Emacs. | |
28 | * Compilation Tips:: Making compiled code run fast. | |
29 | * Warning Tips:: Turning off compiler warnings. | |
30 | * Documentation Tips:: Writing readable documentation strings. | |
31 | * Comment Tips:: Conventions for writing comments. | |
32 | * Library Headers:: Standard headers for library packages. | |
33 | @end menu | |
34 | ||
35 | @node Coding Conventions | |
36 | @section Emacs Lisp Coding Conventions | |
37 | ||
38 | @cindex coding conventions in Emacs Lisp | |
39 | Here are conventions that you should follow when writing Emacs Lisp | |
40 | code intended for widespread use: | |
41 | ||
42 | @itemize @bullet | |
43 | @item | |
44 | Simply loading the package should not change Emacs's editing behavior. | |
45 | Include a command or commands to enable and disable the feature, | |
46 | or to invoke it. | |
47 | ||
48 | This convention is mandatory for any file that includes custom | |
49 | definitions. If fixing such a file to follow this convention requires | |
50 | an incompatible change, go ahead and make the incompatible change; | |
51 | don't postpone it. | |
52 | ||
53 | @item | |
54 | Since all global variables share the same name space, and all | |
55 | functions share another name space, you should choose a short word to | |
56 | distinguish your program from other Lisp programs@footnote{The | |
57 | benefits of a Common Lisp-style package system are considered not to | |
58 | outweigh the costs.}. Then take care to begin the names of all global | |
59 | variables, constants, and functions in your program with the chosen | |
60 | prefix. This helps avoid name conflicts. | |
61 | ||
62 | Occasionally, for a command name intended for users to use, it is more | |
63 | convenient if some words come before the package's name prefix. And | |
64 | constructs that define functions, variables, etc., work better if they | |
65 | start with @samp{defun} or @samp{defvar}, so put the name prefix later | |
66 | on in the name. | |
67 | ||
68 | This recommendation applies even to names for traditional Lisp | |
69 | primitives that are not primitives in Emacs Lisp---such as | |
70 | @code{copy-list}. Believe it or not, there is more than one plausible | |
71 | way to define @code{copy-list}. Play it safe; append your name prefix | |
72 | to produce a name like @code{foo-copy-list} or @code{mylib-copy-list} | |
73 | instead. | |
74 | ||
75 | If you write a function that you think ought to be added to Emacs under | |
76 | a certain name, such as @code{twiddle-files}, don't call it by that name | |
77 | in your program. Call it @code{mylib-twiddle-files} in your program, | |
78 | and send mail to @samp{bug-gnu-emacs@@gnu.org} suggesting we add | |
79 | it to Emacs. If and when we do, we can change the name easily enough. | |
80 | ||
81 | If one prefix is insufficient, your package can use two or three | |
82 | alternative common prefixes, so long as they make sense. | |
83 | ||
84 | Separate the prefix from the rest of the symbol name with a hyphen, | |
85 | @samp{-}. This will be consistent with Emacs itself and with most Emacs | |
86 | Lisp programs. | |
87 | ||
88 | @item | |
89 | Put a call to @code{provide} at the end of each separate Lisp file. | |
90 | ||
91 | @item | |
92 | If a file requires certain other Lisp programs to be loaded | |
93 | beforehand, then the comments at the beginning of the file should say | |
94 | so. Also, use @code{require} to make sure they are loaded. | |
95 | ||
96 | @item | |
97 | If one file @var{foo} uses a macro defined in another file @var{bar}, | |
98 | @var{foo} should contain this expression before the first use of the | |
99 | macro: | |
100 | ||
101 | @example | |
102 | (eval-when-compile (require '@var{bar})) | |
103 | @end example | |
104 | ||
105 | @noindent | |
106 | (And the library @var{bar} should contain @code{(provide '@var{bar})}, | |
107 | to make the @code{require} work.) This will cause @var{bar} to be | |
108 | loaded when you byte-compile @var{foo}. Otherwise, you risk compiling | |
109 | @var{foo} without the necessary macro loaded, and that would produce | |
110 | compiled code that won't work right. @xref{Compiling Macros}. | |
111 | ||
112 | Using @code{eval-when-compile} avoids loading @var{bar} when | |
113 | the compiled version of @var{foo} is @emph{used}. | |
114 | ||
115 | @item | |
116 | Please don't require the @code{cl} package of Common Lisp extensions at | |
117 | run time. Use of this package is optional, and it is not part of the | |
118 | standard Emacs namespace. If your package loads @code{cl} at run time, | |
119 | that could cause name clashes for users who don't use that package. | |
120 | ||
121 | However, there is no problem with using the @code{cl} package at | |
122 | compile time, with @code{(eval-when-compile (require 'cl))}. That's | |
123 | sufficient for using the macros in the @code{cl} package, because the | |
124 | compiler expands them before generating the byte-code. | |
125 | ||
126 | @item | |
127 | When defining a major mode, please follow the major mode | |
128 | conventions. @xref{Major Mode Conventions}. | |
129 | ||
130 | @item | |
131 | When defining a minor mode, please follow the minor mode | |
132 | conventions. @xref{Minor Mode Conventions}. | |
133 | ||
134 | @item | |
135 | If the purpose of a function is to tell you whether a certain condition | |
136 | is true or false, give the function a name that ends in @samp{p}. If | |
137 | the name is one word, add just @samp{p}; if the name is multiple words, | |
138 | add @samp{-p}. Examples are @code{framep} and @code{frame-live-p}. | |
139 | ||
b8d4c8d0 GM |
140 | @item |
141 | If the purpose of a variable is to store a single function, give it a | |
142 | name that ends in @samp{-function}. If the purpose of a variable is | |
143 | to store a list of functions (i.e., the variable is a hook), please | |
144 | follow the naming conventions for hooks. @xref{Hooks}. | |
145 | ||
146 | @item | |
147 | @cindex unloading packages, preparing for | |
148 | If loading the file adds functions to hooks, define a function | |
149 | @code{@var{feature}-unload-hook}, where @var{feature} is the name of | |
150 | the feature the package provides, and make it undo any such changes. | |
151 | Using @code{unload-feature} to unload the file will run this function. | |
152 | @xref{Unloading}. | |
153 | ||
154 | @item | |
155 | It is a bad idea to define aliases for the Emacs primitives. Normally | |
156 | you should use the standard names instead. The case where an alias | |
157 | may be useful is where it facilitates backwards compatibility or | |
158 | portability. | |
159 | ||
160 | @item | |
161 | If a package needs to define an alias or a new function for | |
162 | compatibility with some other version of Emacs, name it with the package | |
163 | prefix, not with the raw name with which it occurs in the other version. | |
164 | Here is an example from Gnus, which provides many examples of such | |
165 | compatibility issues. | |
166 | ||
167 | @example | |
168 | (defalias 'gnus-point-at-bol | |
169 | (if (fboundp 'point-at-bol) | |
170 | 'point-at-bol | |
171 | 'line-beginning-position)) | |
172 | @end example | |
173 | ||
174 | @item | |
175 | Redefining (or advising) an Emacs primitive is a bad idea. It may do | |
176 | the right thing for a particular program, but there is no telling what | |
177 | other programs might break as a result. In any case, it is a problem | |
178 | for debugging, because the advised function doesn't do what its source | |
179 | code says it does. If the programmer investigating the problem is | |
180 | unaware that there is advice on the function, the experience can be | |
181 | very frustrating. | |
182 | ||
183 | We hope to remove all the places in Emacs that advise primitives. | |
184 | In the mean time, please don't add any more. | |
185 | ||
186 | @item | |
187 | It is likewise a bad idea for one Lisp package to advise a function | |
188 | in another Lisp package. | |
189 | ||
190 | @item | |
191 | Likewise, avoid using @code{eval-after-load} (@pxref{Hooks for | |
192 | Loading}) in libraries and packages. This feature is meant for | |
193 | personal customizations; using it in a Lisp program is unclean, | |
194 | because it modifies the behavior of another Lisp file in a way that's | |
195 | not visible in that file. This is an obstacle for debugging, much | |
196 | like advising a function in the other package. | |
197 | ||
198 | @item | |
199 | If a file does replace any of the functions or library programs of | |
200 | standard Emacs, prominent comments at the beginning of the file should | |
201 | say which functions are replaced, and how the behavior of the | |
202 | replacements differs from that of the originals. | |
203 | ||
204 | @item | |
205 | Constructs that define a function or variable should be macros, | |
206 | not functions, and their names should start with @samp{def}. | |
207 | ||
208 | @item | |
209 | A macro that defines a function or variable should have a name that | |
210 | starts with @samp{define-}. The macro should receive the name to be | |
211 | defined as the first argument. That will help various tools find the | |
212 | definition automatically. Avoid constructing the names in the macro | |
213 | itself, since that would confuse these tools. | |
214 | ||
215 | @item | |
216 | Please keep the names of your Emacs Lisp source files to 13 characters | |
217 | or less. This way, if the files are compiled, the compiled files' names | |
218 | will be 14 characters or less, which is short enough to fit on all kinds | |
219 | of Unix systems. | |
220 | ||
221 | @item | |
222 | In some other systems there is a convention of choosing variable names | |
223 | that begin and end with @samp{*}. We don't use that convention in Emacs | |
224 | Lisp, so please don't use it in your programs. (Emacs uses such names | |
225 | only for special-purpose buffers.) The users will find Emacs more | |
226 | coherent if all libraries use the same conventions. | |
227 | ||
228 | @item | |
229 | If your program contains non-ASCII characters in string or character | |
230 | constants, you should make sure Emacs always decodes these characters | |
231 | the same way, regardless of the user's settings. There are two ways | |
232 | to do that: | |
233 | ||
234 | @itemize - | |
235 | @item | |
236 | Use coding system @code{emacs-mule}, and specify that for | |
237 | @code{coding} in the @samp{-*-} line or the local variables list. | |
238 | ||
239 | @example | |
240 | ;; XXX.el -*- coding: emacs-mule; -*- | |
241 | @end example | |
242 | ||
243 | @item | |
244 | Use one of the coding systems based on ISO 2022 (such as | |
245 | iso-8859-@var{n} and iso-2022-7bit), and specify it with @samp{!} at | |
246 | the end for @code{coding}. (The @samp{!} turns off any possible | |
247 | character translation.) | |
248 | ||
249 | @example | |
250 | ;; XXX.el -*- coding: iso-latin-2!; -*- | |
251 | @end example | |
252 | @end itemize | |
253 | ||
254 | @item | |
255 | Indent each function with @kbd{C-M-q} (@code{indent-sexp}) using the | |
256 | default indentation parameters. | |
257 | ||
258 | @item | |
259 | Don't make a habit of putting close-parentheses on lines by themselves; | |
260 | Lisp programmers find this disconcerting. Once in a while, when there | |
261 | is a sequence of many consecutive close-parentheses, it may make sense | |
262 | to split the sequence in one or two significant places. | |
263 | ||
264 | @item | |
265 | Please put a copyright notice and copying permission notice on the | |
266 | file if you distribute copies. Use a notice like this one: | |
267 | ||
268 | @smallexample | |
269 | ;; Copyright (C) @var{year} @var{name} | |
270 | ||
352c8b4a GM |
271 | ;; This program is free software: you can redistribute it and/or modify |
272 | ;; it under the terms of the GNU General Public License as published by | |
273 | ;; the Free Software Foundation, either version 3 of the License, or | |
274 | ;; (at your option) any later version. | |
275 | ||
276 | ;; This program is distributed in the hope that it will be useful, | |
277 | ;; but WITHOUT ANY WARRANTY; without even the implied warranty of | |
278 | ;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the | |
279 | ;; GNU General Public License for more details. | |
280 | ||
281 | ;; You should have received a copy of the GNU General Public License | |
282 | ;; along with this program. If not, see <http://www.gnu.org/licenses/>. | |
b8d4c8d0 GM |
283 | @end smallexample |
284 | ||
285 | If you have signed papers to assign the copyright to the Foundation, | |
286 | then use @samp{Free Software Foundation, Inc.} as @var{name}. | |
287 | Otherwise, use your name. See also @xref{Library Headers}. | |
288 | @end itemize | |
289 | ||
290 | @node Key Binding Conventions | |
291 | @section Key Binding Conventions | |
292 | @cindex key binding, conventions for | |
293 | ||
294 | @itemize @bullet | |
295 | @item | |
296 | @cindex mouse-2 | |
297 | @cindex references, following | |
298 | Special major modes used for read-only text should usually redefine | |
299 | @kbd{mouse-2} and @key{RET} to trace some sort of reference in the text. | |
300 | Modes such as Dired, Info, Compilation, and Occur redefine it in this | |
301 | way. | |
302 | ||
303 | In addition, they should mark the text as a kind of ``link'' so that | |
304 | @kbd{mouse-1} will follow it also. @xref{Links and Mouse-1}. | |
305 | ||
306 | @item | |
307 | @cindex reserved keys | |
308 | @cindex keys, reserved | |
309 | Please do not define @kbd{C-c @var{letter}} as a key in Lisp programs. | |
310 | Sequences consisting of @kbd{C-c} and a letter (either upper or lower | |
311 | case) are reserved for users; they are the @strong{only} sequences | |
312 | reserved for users, so do not block them. | |
313 | ||
314 | Changing all the Emacs major modes to respect this convention was a | |
315 | lot of work; abandoning this convention would make that work go to | |
316 | waste, and inconvenience users. Please comply with it. | |
317 | ||
318 | @item | |
319 | Function keys @key{F5} through @key{F9} without modifier keys are | |
320 | also reserved for users to define. | |
321 | ||
322 | @item | |
323 | Applications should not bind mouse events based on button 1 with the | |
324 | shift key held down. These events include @kbd{S-mouse-1}, | |
325 | @kbd{M-S-mouse-1}, @kbd{C-S-mouse-1}, and so on. They are reserved for | |
326 | users. | |
327 | ||
328 | @item | |
329 | Sequences consisting of @kbd{C-c} followed by a control character or a | |
330 | digit are reserved for major modes. | |
331 | ||
332 | @item | |
333 | Sequences consisting of @kbd{C-c} followed by @kbd{@{}, @kbd{@}}, | |
334 | @kbd{<}, @kbd{>}, @kbd{:} or @kbd{;} are also reserved for major modes. | |
335 | ||
336 | @item | |
337 | Sequences consisting of @kbd{C-c} followed by any other punctuation | |
338 | character are allocated for minor modes. Using them in a major mode is | |
339 | not absolutely prohibited, but if you do that, the major mode binding | |
340 | may be shadowed from time to time by minor modes. | |
341 | ||
342 | @item | |
343 | Do not bind @kbd{C-h} following any prefix character (including | |
344 | @kbd{C-c}). If you don't bind @kbd{C-h}, it is automatically available | |
345 | as a help character for listing the subcommands of the prefix character. | |
346 | ||
347 | @item | |
348 | Do not bind a key sequence ending in @key{ESC} except following | |
349 | another @key{ESC}. (That is, it is OK to bind a sequence ending in | |
350 | @kbd{@key{ESC} @key{ESC}}.) | |
351 | ||
352 | The reason for this rule is that a non-prefix binding for @key{ESC} in | |
353 | any context prevents recognition of escape sequences as function keys in | |
354 | that context. | |
355 | ||
356 | @item | |
357 | Anything which acts like a temporary mode or state which the user can | |
358 | enter and leave should define @kbd{@key{ESC} @key{ESC}} or | |
359 | @kbd{@key{ESC} @key{ESC} @key{ESC}} as a way to escape. | |
360 | ||
361 | For a state which accepts ordinary Emacs commands, or more generally any | |
362 | kind of state in which @key{ESC} followed by a function key or arrow key | |
363 | is potentially meaningful, then you must not define @kbd{@key{ESC} | |
364 | @key{ESC}}, since that would preclude recognizing an escape sequence | |
365 | after @key{ESC}. In these states, you should define @kbd{@key{ESC} | |
366 | @key{ESC} @key{ESC}} as the way to escape. Otherwise, define | |
367 | @kbd{@key{ESC} @key{ESC}} instead. | |
368 | @end itemize | |
369 | ||
370 | @node Programming Tips | |
371 | @section Emacs Programming Tips | |
372 | @cindex programming conventions | |
373 | ||
374 | Following these conventions will make your program fit better | |
375 | into Emacs when it runs. | |
376 | ||
377 | @itemize @bullet | |
378 | @item | |
379 | Don't use @code{next-line} or @code{previous-line} in programs; nearly | |
380 | always, @code{forward-line} is more convenient as well as more | |
381 | predictable and robust. @xref{Text Lines}. | |
382 | ||
383 | @item | |
384 | Don't call functions that set the mark, unless setting the mark is one | |
385 | of the intended features of your program. The mark is a user-level | |
386 | feature, so it is incorrect to change the mark except to supply a value | |
387 | for the user's benefit. @xref{The Mark}. | |
388 | ||
389 | In particular, don't use any of these functions: | |
390 | ||
391 | @itemize @bullet | |
392 | @item | |
393 | @code{beginning-of-buffer}, @code{end-of-buffer} | |
394 | @item | |
395 | @code{replace-string}, @code{replace-regexp} | |
396 | @item | |
397 | @code{insert-file}, @code{insert-buffer} | |
398 | @end itemize | |
399 | ||
400 | If you just want to move point, or replace a certain string, or insert | |
401 | a file or buffer's contents, without any of the other features | |
402 | intended for interactive users, you can replace these functions with | |
403 | one or two lines of simple Lisp code. | |
404 | ||
405 | @item | |
406 | Use lists rather than vectors, except when there is a particular reason | |
407 | to use a vector. Lisp has more facilities for manipulating lists than | |
408 | for vectors, and working with lists is usually more convenient. | |
409 | ||
410 | Vectors are advantageous for tables that are substantial in size and are | |
411 | accessed in random order (not searched front to back), provided there is | |
412 | no need to insert or delete elements (only lists allow that). | |
413 | ||
414 | @item | |
415 | The recommended way to show a message in the echo area is with | |
416 | the @code{message} function, not @code{princ}. @xref{The Echo Area}. | |
417 | ||
418 | @item | |
419 | When you encounter an error condition, call the function @code{error} | |
420 | (or @code{signal}). The function @code{error} does not return. | |
421 | @xref{Signaling Errors}. | |
422 | ||
423 | Do not use @code{message}, @code{throw}, @code{sleep-for}, | |
424 | or @code{beep} to report errors. | |
425 | ||
426 | @item | |
427 | An error message should start with a capital letter but should not end | |
428 | with a period. | |
429 | ||
430 | @item | |
431 | A question asked in the minibuffer with @code{y-or-n-p} or | |
432 | @code{yes-or-no-p} should start with a capital letter and end with | |
433 | @samp{? }. | |
434 | ||
435 | @item | |
436 | When you mention a default value in a minibuffer prompt, | |
437 | put it and the word @samp{default} inside parentheses. | |
438 | It should look like this: | |
439 | ||
440 | @example | |
441 | Enter the answer (default 42): | |
442 | @end example | |
443 | ||
444 | @item | |
445 | In @code{interactive}, if you use a Lisp expression to produce a list | |
446 | of arguments, don't try to provide the ``correct'' default values for | |
447 | region or position arguments. Instead, provide @code{nil} for those | |
448 | arguments if they were not specified, and have the function body | |
449 | compute the default value when the argument is @code{nil}. For | |
450 | instance, write this: | |
451 | ||
452 | @example | |
453 | (defun foo (pos) | |
454 | (interactive | |
455 | (list (if @var{specified} @var{specified-pos}))) | |
456 | (unless pos (setq pos @var{default-pos})) | |
457 | ...) | |
458 | @end example | |
459 | ||
460 | @noindent | |
461 | rather than this: | |
462 | ||
463 | @example | |
464 | (defun foo (pos) | |
465 | (interactive | |
466 | (list (if @var{specified} @var{specified-pos} | |
467 | @var{default-pos}))) | |
468 | ...) | |
469 | @end example | |
470 | ||
471 | @noindent | |
472 | This is so that repetition of the command will recompute | |
473 | these defaults based on the current circumstances. | |
474 | ||
475 | You do not need to take such precautions when you use interactive | |
476 | specs @samp{d}, @samp{m} and @samp{r}, because they make special | |
477 | arrangements to recompute the argument values on repetition of the | |
478 | command. | |
479 | ||
480 | @item | |
481 | Many commands that take a long time to execute display a message that | |
482 | says something like @samp{Operating...} when they start, and change it to | |
483 | @samp{Operating...done} when they finish. Please keep the style of | |
484 | these messages uniform: @emph{no} space around the ellipsis, and | |
485 | @emph{no} period after @samp{done}. | |
486 | ||
487 | @item | |
488 | Try to avoid using recursive edits. Instead, do what the Rmail @kbd{e} | |
489 | command does: use a new local keymap that contains one command defined | |
490 | to switch back to the old local keymap. Or do what the | |
491 | @code{edit-options} command does: switch to another buffer and let the | |
492 | user switch back at will. @xref{Recursive Editing}. | |
493 | @end itemize | |
494 | ||
495 | @node Compilation Tips | |
496 | @section Tips for Making Compiled Code Fast | |
497 | @cindex execution speed | |
498 | @cindex speedups | |
499 | ||
500 | Here are ways of improving the execution speed of byte-compiled | |
501 | Lisp programs. | |
502 | ||
503 | @itemize @bullet | |
504 | @item | |
505 | @cindex profiling | |
506 | @cindex timing programs | |
507 | @cindex @file{elp.el} | |
508 | Profile your program with the @file{elp} library. See the file | |
509 | @file{elp.el} for instructions. | |
510 | ||
511 | @item | |
512 | @cindex @file{benchmark.el} | |
513 | @cindex benchmarking | |
514 | Check the speed of individual Emacs Lisp forms using the | |
515 | @file{benchmark} library. See the functions @code{benchmark-run} and | |
516 | @code{benchmark-run-compiled} in @file{benchmark.el}. | |
517 | ||
518 | @item | |
519 | Use iteration rather than recursion whenever possible. | |
520 | Function calls are slow in Emacs Lisp even when a compiled function | |
521 | is calling another compiled function. | |
522 | ||
523 | @item | |
524 | Using the primitive list-searching functions @code{memq}, @code{member}, | |
525 | @code{assq}, or @code{assoc} is even faster than explicit iteration. It | |
526 | can be worth rearranging a data structure so that one of these primitive | |
527 | search functions can be used. | |
528 | ||
529 | @item | |
530 | Certain built-in functions are handled specially in byte-compiled code, | |
531 | avoiding the need for an ordinary function call. It is a good idea to | |
532 | use these functions rather than alternatives. To see whether a function | |
533 | is handled specially by the compiler, examine its @code{byte-compile} | |
534 | property. If the property is non-@code{nil}, then the function is | |
535 | handled specially. | |
536 | ||
537 | For example, the following input will show you that @code{aref} is | |
538 | compiled specially (@pxref{Array Functions}): | |
539 | ||
540 | @example | |
541 | @group | |
542 | (get 'aref 'byte-compile) | |
543 | @result{} byte-compile-two-args | |
544 | @end group | |
545 | @end example | |
546 | ||
547 | @item | |
548 | If calling a small function accounts for a substantial part of your | |
549 | program's running time, make the function inline. This eliminates | |
550 | the function call overhead. Since making a function inline reduces | |
551 | the flexibility of changing the program, don't do it unless it gives | |
552 | a noticeable speedup in something slow enough that users care about | |
553 | the speed. @xref{Inline Functions}. | |
554 | @end itemize | |
555 | ||
556 | @node Warning Tips | |
557 | @section Tips for Avoiding Compiler Warnings | |
558 | @cindex byte compiler warnings, how to avoid | |
559 | ||
560 | @itemize @bullet | |
561 | @item | |
562 | Try to avoid compiler warnings about undefined free variables, by adding | |
563 | dummy @code{defvar} definitions for these variables, like this: | |
564 | ||
565 | @example | |
566 | (defvar foo) | |
567 | @end example | |
568 | ||
569 | Such a definition has no effect except to tell the compiler | |
570 | not to warn about uses of the variable @code{foo} in this file. | |
571 | ||
572 | @item | |
573 | If you use many functions and variables from a certain file, you can | |
574 | add a @code{require} for that package to avoid compilation warnings | |
575 | for them. For instance, | |
576 | ||
577 | @example | |
578 | (eval-when-compile | |
579 | (require 'foo)) | |
580 | @end example | |
581 | ||
582 | @item | |
583 | If you bind a variable in one function, and use it or set it in | |
584 | another function, the compiler warns about the latter function unless | |
585 | the variable has a definition. But adding a definition would be | |
586 | unclean if the variable has a short name, since Lisp packages should | |
587 | not define short variable names. The right thing to do is to rename | |
588 | this variable to start with the name prefix used for the other | |
589 | functions and variables in your package. | |
590 | ||
591 | @item | |
592 | The last resort for avoiding a warning, when you want to do something | |
593 | that usually is a mistake but it's not a mistake in this one case, | |
594 | is to put a call to @code{with-no-warnings} around it. | |
595 | @end itemize | |
596 | ||
597 | @node Documentation Tips | |
598 | @section Tips for Documentation Strings | |
599 | @cindex documentation strings, conventions and tips | |
600 | ||
601 | @findex checkdoc-minor-mode | |
602 | Here are some tips and conventions for the writing of documentation | |
603 | strings. You can check many of these conventions by running the command | |
604 | @kbd{M-x checkdoc-minor-mode}. | |
605 | ||
606 | @itemize @bullet | |
607 | @item | |
608 | Every command, function, or variable intended for users to know about | |
609 | should have a documentation string. | |
610 | ||
611 | @item | |
612 | An internal variable or subroutine of a Lisp program might as well have | |
613 | a documentation string. In earlier Emacs versions, you could save space | |
614 | by using a comment instead of a documentation string, but that is no | |
615 | longer the case---documentation strings now take up very little space in | |
616 | a running Emacs. | |
617 | ||
618 | @item | |
619 | Format the documentation string so that it fits in an Emacs window on an | |
620 | 80-column screen. It is a good idea for most lines to be no wider than | |
621 | 60 characters. The first line should not be wider than 67 characters | |
622 | or it will look bad in the output of @code{apropos}. | |
623 | ||
624 | You can fill the text if that looks good. However, rather than blindly | |
625 | filling the entire documentation string, you can often make it much more | |
626 | readable by choosing certain line breaks with care. Use blank lines | |
627 | between topics if the documentation string is long. | |
628 | ||
629 | @item | |
630 | The first line of the documentation string should consist of one or two | |
631 | complete sentences that stand on their own as a summary. @kbd{M-x | |
632 | apropos} displays just the first line, and if that line's contents don't | |
633 | stand on their own, the result looks bad. In particular, start the | |
634 | first line with a capital letter and end with a period. | |
635 | ||
636 | For a function, the first line should briefly answer the question, | |
637 | ``What does this function do?'' For a variable, the first line should | |
638 | briefly answer the question, ``What does this value mean?'' | |
639 | ||
640 | Don't limit the documentation string to one line; use as many lines as | |
641 | you need to explain the details of how to use the function or | |
642 | variable. Please use complete sentences for the rest of the text too. | |
643 | ||
644 | @item | |
645 | When the user tries to use a disabled command, Emacs displays just the | |
646 | first paragraph of its documentation string---everything through the | |
647 | first blank line. If you wish, you can choose which information to | |
648 | include before the first blank line so as to make this display useful. | |
649 | ||
650 | @item | |
651 | The first line should mention all the important arguments of the | |
652 | function, and should mention them in the order that they are written | |
653 | in a function call. If the function has many arguments, then it is | |
654 | not feasible to mention them all in the first line; in that case, the | |
655 | first line should mention the first few arguments, including the most | |
656 | important arguments. | |
657 | ||
658 | @item | |
659 | When a function's documentation string mentions the value of an argument | |
660 | of the function, use the argument name in capital letters as if it were | |
661 | a name for that value. Thus, the documentation string of the function | |
662 | @code{eval} refers to its second argument as @samp{FORM}, because the | |
663 | actual argument name is @code{form}: | |
664 | ||
665 | @example | |
666 | Evaluate FORM and return its value. | |
667 | @end example | |
668 | ||
669 | Also write metasyntactic variables in capital letters, such as when you | |
670 | show the decomposition of a list or vector into subunits, some of which | |
671 | may vary. @samp{KEY} and @samp{VALUE} in the following example | |
672 | illustrate this practice: | |
673 | ||
674 | @example | |
675 | The argument TABLE should be an alist whose elements | |
676 | have the form (KEY . VALUE). Here, KEY is ... | |
677 | @end example | |
678 | ||
679 | @item | |
680 | Never change the case of a Lisp symbol when you mention it in a doc | |
681 | string. If the symbol's name is @code{foo}, write ``foo,'' not | |
682 | ``Foo'' (which is a different symbol). | |
683 | ||
684 | This might appear to contradict the policy of writing function | |
685 | argument values, but there is no real contradiction; the argument | |
686 | @emph{value} is not the same thing as the @emph{symbol} which the | |
687 | function uses to hold the value. | |
688 | ||
689 | If this puts a lower-case letter at the beginning of a sentence | |
690 | and that annoys you, rewrite the sentence so that the symbol | |
691 | is not at the start of it. | |
692 | ||
693 | @item | |
694 | Do not start or end a documentation string with whitespace. | |
695 | ||
696 | @item | |
697 | @strong{Do not} indent subsequent lines of a documentation string so | |
698 | that the text is lined up in the source code with the text of the first | |
699 | line. This looks nice in the source code, but looks bizarre when users | |
700 | view the documentation. Remember that the indentation before the | |
701 | starting double-quote is not part of the string! | |
702 | ||
703 | @anchor{Docstring hyperlinks} | |
704 | @item | |
705 | @iftex | |
706 | When a documentation string refers to a Lisp symbol, write it as it | |
707 | would be printed (which usually means in lower case), with single-quotes | |
708 | around it. For example: @samp{`lambda'}. There are two exceptions: | |
709 | write @code{t} and @code{nil} without single-quotes. | |
710 | @end iftex | |
711 | @ifnottex | |
712 | When a documentation string refers to a Lisp symbol, write it as it | |
713 | would be printed (which usually means in lower case), with single-quotes | |
714 | around it. For example: @samp{lambda}. There are two exceptions: write | |
715 | t and nil without single-quotes. (In this manual, we use a different | |
716 | convention, with single-quotes for all symbols.) | |
717 | @end ifnottex | |
718 | ||
719 | @cindex hyperlinks in documentation strings | |
720 | Help mode automatically creates a hyperlink when a documentation string | |
721 | uses a symbol name inside single quotes, if the symbol has either a | |
722 | function or a variable definition. You do not need to do anything | |
723 | special to make use of this feature. However, when a symbol has both a | |
724 | function definition and a variable definition, and you want to refer to | |
725 | just one of them, you can specify which one by writing one of the words | |
726 | @samp{variable}, @samp{option}, @samp{function}, or @samp{command}, | |
727 | immediately before the symbol name. (Case makes no difference in | |
728 | recognizing these indicator words.) For example, if you write | |
729 | ||
730 | @example | |
731 | This function sets the variable `buffer-file-name'. | |
732 | @end example | |
733 | ||
734 | @noindent | |
735 | then the hyperlink will refer only to the variable documentation of | |
736 | @code{buffer-file-name}, and not to its function documentation. | |
737 | ||
738 | If a symbol has a function definition and/or a variable definition, but | |
739 | those are irrelevant to the use of the symbol that you are documenting, | |
740 | you can write the words @samp{symbol} or @samp{program} before the | |
741 | symbol name to prevent making any hyperlink. For example, | |
742 | ||
743 | @example | |
744 | If the argument KIND-OF-RESULT is the symbol `list', | |
745 | this function returns a list of all the objects | |
746 | that satisfy the criterion. | |
747 | @end example | |
748 | ||
749 | @noindent | |
750 | does not make a hyperlink to the documentation, irrelevant here, of the | |
751 | function @code{list}. | |
752 | ||
753 | Normally, no hyperlink is made for a variable without variable | |
754 | documentation. You can force a hyperlink for such variables by | |
755 | preceding them with one of the words @samp{variable} or | |
756 | @samp{option}. | |
757 | ||
758 | Hyperlinks for faces are only made if the face name is preceded or | |
759 | followed by the word @samp{face}. In that case, only the face | |
760 | documentation will be shown, even if the symbol is also defined as a | |
761 | variable or as a function. | |
762 | ||
763 | To make a hyperlink to Info documentation, write the name of the Info | |
764 | node (or anchor) in single quotes, preceded by @samp{info node}, | |
765 | @samp{Info node}, @samp{info anchor} or @samp{Info anchor}. The Info | |
766 | file name defaults to @samp{emacs}. For example, | |
767 | ||
768 | @smallexample | |
769 | See Info node `Font Lock' and Info node `(elisp)Font Lock Basics'. | |
770 | @end smallexample | |
771 | ||
772 | Finally, to create a hyperlink to URLs, write the URL in single | |
773 | quotes, preceded by @samp{URL}. For example, | |
774 | ||
775 | @smallexample | |
776 | The home page for the GNU project has more information (see URL | |
777 | `http://www.gnu.org/'). | |
778 | @end smallexample | |
779 | ||
780 | @item | |
781 | Don't write key sequences directly in documentation strings. Instead, | |
782 | use the @samp{\\[@dots{}]} construct to stand for them. For example, | |
783 | instead of writing @samp{C-f}, write the construct | |
784 | @samp{\\[forward-char]}. When Emacs displays the documentation string, | |
785 | it substitutes whatever key is currently bound to @code{forward-char}. | |
786 | (This is normally @samp{C-f}, but it may be some other character if the | |
787 | user has moved key bindings.) @xref{Keys in Documentation}. | |
788 | ||
789 | @item | |
790 | In documentation strings for a major mode, you will want to refer to the | |
791 | key bindings of that mode's local map, rather than global ones. | |
792 | Therefore, use the construct @samp{\\<@dots{}>} once in the | |
793 | documentation string to specify which key map to use. Do this before | |
794 | the first use of @samp{\\[@dots{}]}. The text inside the | |
795 | @samp{\\<@dots{}>} should be the name of the variable containing the | |
796 | local keymap for the major mode. | |
797 | ||
798 | It is not practical to use @samp{\\[@dots{}]} very many times, because | |
799 | display of the documentation string will become slow. So use this to | |
800 | describe the most important commands in your major mode, and then use | |
801 | @samp{\\@{@dots{}@}} to display the rest of the mode's keymap. | |
802 | ||
803 | @item | |
804 | For consistency, phrase the verb in the first sentence of a function's | |
805 | documentation string as an imperative---for instance, use ``Return the | |
806 | cons of A and B.'' in preference to ``Returns the cons of A and B@.'' | |
807 | Usually it looks good to do likewise for the rest of the first | |
808 | paragraph. Subsequent paragraphs usually look better if each sentence | |
809 | is indicative and has a proper subject. | |
810 | ||
811 | @item | |
812 | The documentation string for a function that is a yes-or-no predicate | |
813 | should start with words such as ``Return t if,'' to indicate | |
814 | explicitly what constitutes ``truth.'' The word ``return'' avoids | |
815 | starting the sentence with lower-case ``t,'' which could be somewhat | |
816 | distracting. | |
817 | ||
818 | @item | |
819 | If a line in a documentation string begins with an open-parenthesis, | |
820 | write a backslash before the open-parenthesis, like this: | |
821 | ||
822 | @example | |
823 | The argument FOO can be either a number | |
824 | \(a buffer position) or a string (a file name). | |
825 | @end example | |
826 | ||
827 | This prevents the open-parenthesis from being treated as the start of a | |
828 | defun (@pxref{Defuns,, Defuns, emacs, The GNU Emacs Manual}). | |
829 | ||
830 | @item | |
831 | Write documentation strings in the active voice, not the passive, and in | |
832 | the present tense, not the future. For instance, use ``Return a list | |
833 | containing A and B.'' instead of ``A list containing A and B will be | |
834 | returned.'' | |
835 | ||
836 | @item | |
837 | Avoid using the word ``cause'' (or its equivalents) unnecessarily. | |
838 | Instead of, ``Cause Emacs to display text in boldface,'' write just | |
839 | ``Display text in boldface.'' | |
840 | ||
841 | @item | |
842 | Avoid using ``iff'' (a mathematics term meaning ``if and only if''), | |
843 | since many people are unfamiliar with it and mistake it for a typo. In | |
844 | most cases, the meaning is clear with just ``if''. Otherwise, try to | |
845 | find an alternate phrasing that conveys the meaning. | |
846 | ||
847 | @item | |
848 | When a command is meaningful only in a certain mode or situation, | |
849 | do mention that in the documentation string. For example, | |
850 | the documentation of @code{dired-find-file} is: | |
851 | ||
852 | @example | |
853 | In Dired, visit the file or directory named on this line. | |
854 | @end example | |
855 | ||
856 | @item | |
857 | When you define a variable that users ought to set interactively, you | |
858 | normally should use @code{defcustom}. However, if for some reason you | |
859 | use @code{defvar} instead, start the doc string with a @samp{*}. | |
860 | @xref{Defining Variables}. | |
861 | ||
862 | @item | |
863 | The documentation string for a variable that is a yes-or-no flag should | |
864 | start with words such as ``Non-nil means,'' to make it clear that | |
865 | all non-@code{nil} values are equivalent and indicate explicitly what | |
866 | @code{nil} and non-@code{nil} mean. | |
867 | @end itemize | |
868 | ||
869 | @node Comment Tips | |
870 | @section Tips on Writing Comments | |
871 | @cindex comments, Lisp convention for | |
872 | ||
873 | We recommend these conventions for where to put comments and how to | |
874 | indent them: | |
875 | ||
876 | @table @samp | |
877 | @item ; | |
878 | Comments that start with a single semicolon, @samp{;}, should all be | |
879 | aligned to the same column on the right of the source code. Such | |
880 | comments usually explain how the code on the same line does its job. In | |
881 | Lisp mode and related modes, the @kbd{M-;} (@code{indent-for-comment}) | |
882 | command automatically inserts such a @samp{;} in the right place, or | |
883 | aligns such a comment if it is already present. | |
884 | ||
885 | This and following examples are taken from the Emacs sources. | |
886 | ||
887 | @smallexample | |
888 | @group | |
889 | (setq base-version-list ; there was a base | |
890 | (assoc (substring fn 0 start-vn) ; version to which | |
891 | file-version-assoc-list)) ; this looks like | |
892 | ; a subversion | |
893 | @end group | |
894 | @end smallexample | |
895 | ||
896 | @item ;; | |
897 | Comments that start with two semicolons, @samp{;;}, should be aligned to | |
898 | the same level of indentation as the code. Such comments usually | |
899 | describe the purpose of the following lines or the state of the program | |
900 | at that point. For example: | |
901 | ||
902 | @smallexample | |
903 | @group | |
904 | (prog1 (setq auto-fill-function | |
905 | @dots{} | |
906 | @dots{} | |
907 | ;; update mode line | |
908 | (force-mode-line-update))) | |
909 | @end group | |
910 | @end smallexample | |
911 | ||
912 | We also normally use two semicolons for comments outside functions. | |
913 | ||
914 | @smallexample | |
915 | @group | |
916 | ;; This Lisp code is run in Emacs | |
917 | ;; when it is to operate as a server | |
918 | ;; for other processes. | |
919 | @end group | |
920 | @end smallexample | |
921 | ||
922 | Every function that has no documentation string (presumably one that is | |
923 | used only internally within the package it belongs to), should instead | |
924 | have a two-semicolon comment right before the function, explaining what | |
925 | the function does and how to call it properly. Explain precisely what | |
926 | each argument means and how the function interprets its possible values. | |
927 | ||
928 | @item ;;; | |
929 | Comments that start with three semicolons, @samp{;;;}, should start at | |
930 | the left margin. These are used, occasionally, for comments within | |
931 | functions that should start at the margin. We also use them sometimes | |
932 | for comments that are between functions---whether to use two or three | |
933 | semicolons depends on whether the comment should be considered a | |
934 | ``heading'' by Outline minor mode. By default, comments starting with | |
935 | at least three semicolons (followed by a single space and a | |
936 | non-whitespace character) are considered headings, comments starting | |
937 | with two or less are not. | |
938 | ||
939 | Another use for triple-semicolon comments is for commenting out lines | |
940 | within a function. We use three semicolons for this precisely so that | |
941 | they remain at the left margin. By default, Outline minor mode does | |
942 | not consider a comment to be a heading (even if it starts with at | |
943 | least three semicolons) if the semicolons are followed by at least two | |
944 | spaces. Thus, if you add an introductory comment to the commented out | |
945 | code, make sure to indent it by at least two spaces after the three | |
946 | semicolons. | |
947 | ||
948 | @smallexample | |
949 | (defun foo (a) | |
950 | ;;; This is no longer necessary. | |
951 | ;;; (force-mode-line-update) | |
952 | (message "Finished with %s" a)) | |
953 | @end smallexample | |
954 | ||
955 | When commenting out entire functions, use two semicolons. | |
956 | ||
957 | @item ;;;; | |
958 | Comments that start with four semicolons, @samp{;;;;}, should be aligned | |
959 | to the left margin and are used for headings of major sections of a | |
960 | program. For example: | |
961 | ||
962 | @smallexample | |
963 | ;;;; The kill ring | |
964 | @end smallexample | |
965 | @end table | |
966 | ||
967 | @noindent | |
968 | The indentation commands of the Lisp modes in Emacs, such as @kbd{M-;} | |
969 | (@code{indent-for-comment}) and @key{TAB} (@code{lisp-indent-line}), | |
970 | automatically indent comments according to these conventions, | |
971 | depending on the number of semicolons. @xref{Comments,, | |
972 | Manipulating Comments, emacs, The GNU Emacs Manual}. | |
973 | ||
974 | @node Library Headers | |
975 | @section Conventional Headers for Emacs Libraries | |
976 | @cindex header comments | |
977 | @cindex library header comments | |
978 | ||
979 | Emacs has conventions for using special comments in Lisp libraries | |
980 | to divide them into sections and give information such as who wrote | |
981 | them. This section explains these conventions. | |
982 | ||
983 | We'll start with an example, a package that is included in the Emacs | |
984 | distribution. | |
985 | ||
986 | Parts of this example reflect its status as part of Emacs; for | |
987 | example, the copyright notice lists the Free Software Foundation as the | |
988 | copyright holder, and the copying permission says the file is part of | |
989 | Emacs. When you write a package and post it, the copyright holder would | |
990 | be you (unless your employer claims to own it instead), and you should | |
991 | get the suggested copying permission from the end of the GNU General | |
992 | Public License itself. Don't say your file is part of Emacs | |
993 | if we haven't installed it in Emacs yet! | |
994 | ||
995 | With that warning out of the way, on to the example: | |
996 | ||
997 | @smallexample | |
998 | @group | |
999 | ;;; lisp-mnt.el --- minor mode for Emacs Lisp maintainers | |
1000 | ||
1001 | ;; Copyright (C) 1992 Free Software Foundation, Inc. | |
1002 | @end group | |
1003 | ||
1004 | ;; Author: Eric S. Raymond <esr@@snark.thyrsus.com> | |
1005 | ;; Maintainer: Eric S. Raymond <esr@@snark.thyrsus.com> | |
1006 | ;; Created: 14 Jul 1992 | |
1007 | ;; Version: 1.2 | |
1008 | @group | |
1009 | ;; Keywords: docs | |
1010 | ||
1011 | ;; This file is part of GNU Emacs. | |
1012 | @dots{} | |
352c8b4a | 1013 | ;; along with GNU Emacs. If not, see <http://www.gnu.org/licenses/>. |
b8d4c8d0 GM |
1014 | @end group |
1015 | @end smallexample | |
1016 | ||
1017 | The very first line should have this format: | |
1018 | ||
1019 | @example | |
1020 | ;;; @var{filename} --- @var{description} | |
1021 | @end example | |
1022 | ||
1023 | @noindent | |
1024 | The description should be complete in one line. If the file | |
1025 | needs a @samp{-*-} specification, put it after @var{description}. | |
1026 | ||
1027 | After the copyright notice come several @dfn{header comment} lines, | |
1028 | each beginning with @samp{;; @var{header-name}:}. Here is a table of | |
1029 | the conventional possibilities for @var{header-name}: | |
1030 | ||
1031 | @table @samp | |
1032 | @item Author | |
1033 | This line states the name and net address of at least the principal | |
1034 | author of the library. | |
1035 | ||
1036 | If there are multiple authors, you can list them on continuation lines | |
1037 | led by @code{;;} and a tab character, like this: | |
1038 | ||
1039 | @smallexample | |
1040 | @group | |
1041 | ;; Author: Ashwin Ram <Ram-Ashwin@@cs.yale.edu> | |
1042 | ;; Dave Sill <de5@@ornl.gov> | |
1043 | ;; Dave Brennan <brennan@@hal.com> | |
1044 | ;; Eric Raymond <esr@@snark.thyrsus.com> | |
1045 | @end group | |
1046 | @end smallexample | |
1047 | ||
1048 | @item Maintainer | |
1049 | This line should contain a single name/address as in the Author line, or | |
1050 | an address only, or the string @samp{FSF}. If there is no maintainer | |
1051 | line, the person(s) in the Author field are presumed to be the | |
1052 | maintainers. The example above is mildly bogus because the maintainer | |
1053 | line is redundant. | |
1054 | ||
1055 | The idea behind the @samp{Author} and @samp{Maintainer} lines is to make | |
1056 | possible a Lisp function to ``send mail to the maintainer'' without | |
1057 | having to mine the name out by hand. | |
1058 | ||
1059 | Be sure to surround the network address with @samp{<@dots{}>} if | |
1060 | you include the person's full name as well as the network address. | |
1061 | ||
1062 | @item Created | |
1063 | This optional line gives the original creation date of the | |
1064 | file. For historical interest only. | |
1065 | ||
1066 | @item Version | |
1067 | If you wish to record version numbers for the individual Lisp program, put | |
1068 | them in this line. | |
1069 | ||
1070 | @item Adapted-By | |
1071 | In this header line, place the name of the person who adapted the | |
1072 | library for installation (to make it fit the style conventions, for | |
1073 | example). | |
1074 | ||
1075 | @item Keywords | |
1076 | This line lists keywords for the @code{finder-by-keyword} help command. | |
1077 | Please use that command to see a list of the meaningful keywords. | |
1078 | ||
1079 | This field is important; it's how people will find your package when | |
1080 | they're looking for things by topic area. To separate the keywords, you | |
1081 | can use spaces, commas, or both. | |
1082 | @end table | |
1083 | ||
1084 | Just about every Lisp library ought to have the @samp{Author} and | |
1085 | @samp{Keywords} header comment lines. Use the others if they are | |
1086 | appropriate. You can also put in header lines with other header | |
1087 | names---they have no standard meanings, so they can't do any harm. | |
1088 | ||
1089 | We use additional stylized comments to subdivide the contents of the | |
1090 | library file. These should be separated by blank lines from anything | |
1091 | else. Here is a table of them: | |
1092 | ||
1093 | @table @samp | |
1094 | @item ;;; Commentary: | |
1095 | This begins introductory comments that explain how the library works. | |
1096 | It should come right after the copying permissions, terminated by a | |
1097 | @samp{Change Log}, @samp{History} or @samp{Code} comment line. This | |
1098 | text is used by the Finder package, so it should make sense in that | |
1099 | context. | |
1100 | ||
1101 | @item ;;; Documentation: | |
1102 | This was used in some files in place of @samp{;;; Commentary:}, | |
1103 | but it is deprecated. | |
1104 | ||
1105 | @item ;;; Change Log: | |
1106 | This begins change log information stored in the library file (if you | |
1107 | store the change history there). For Lisp files distributed with Emacs, | |
1108 | the change history is kept in the file @file{ChangeLog} and not in the | |
1109 | source file at all; these files generally do not have a @samp{;;; Change | |
1110 | Log:} line. @samp{History} is an alternative to @samp{Change Log}. | |
1111 | ||
1112 | @item ;;; Code: | |
1113 | This begins the actual code of the program. | |
1114 | ||
1115 | @item ;;; @var{filename} ends here | |
1116 | This is the @dfn{footer line}; it appears at the very end of the file. | |
1117 | Its purpose is to enable people to detect truncated versions of the file | |
1118 | from the lack of a footer line. | |
1119 | @end table | |
1120 | ||
1121 | @ignore | |
1122 | arch-tag: 9ea911c2-6b1d-47dd-88b7-0a94e8b27c2e | |
1123 | @end ignore |