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