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