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