tips.texi 40.9 KB
Newer Older
Richard M. Stallman's avatar
Richard M. Stallman committed
1 2
@c -*-texinfo-*-
@c This is part of the GNU Emacs Lisp Reference Manual.
3
@c Copyright (C) 1990, 1991, 1992, 1993, 1995, 1998, 1999, 2002, 2003,
4
@c   2004, 2005, 2006 Free Software Foundation, Inc.
Richard M. Stallman's avatar
Richard M. Stallman committed
5 6
@c See the file elisp.texi for copying conditions.
@setfilename ../info/tips
Werner LEMBERG's avatar
Werner LEMBERG committed
7
@node Tips, GNU Emacs Internals, GPL, Top
8
@appendix Tips and Conventions
Richard M. Stallman's avatar
Richard M. Stallman committed
9 10 11 12
@cindex tips
@cindex standards of coding style
@cindex coding standards

13 14 15 16
  This chapter describes no additional features of Emacs Lisp.  Instead
it gives advice on making effective use of the features described in the
previous chapters, and describes conventions Emacs Lisp programmers
should follow.
Richard M. Stallman's avatar
Richard M. Stallman committed
17

18 19 20 21 22 23
  You can automatically check some of the conventions described below by
running the command @kbd{M-x checkdoc RET} when visiting a Lisp file.
It cannot check all of the conventions, and not all the warnings it
gives necessarily correspond to problems, but it is worth examining them
all.

Richard M. Stallman's avatar
Richard M. Stallman committed
24
@menu
25
* Coding Conventions::        Conventions for clean and robust programs.
26 27
* Key Binding Conventions::   Which keys should be bound by which programs.
* Programming Tips::          Making Emacs code fit smoothly in Emacs.
Richard M. Stallman's avatar
Richard M. Stallman committed
28
* Compilation Tips::          Making compiled code run fast.
29
* Warning Tips::              Turning off compiler warnings.
Richard M. Stallman's avatar
Richard M. Stallman committed
30 31 32 33 34
* Documentation Tips::        Writing readable documentation strings.
* Comment Tips::	      Conventions for writing comments.
* Library Headers::           Standard headers for library packages.
@end menu

35 36
@node Coding Conventions
@section Emacs Lisp Coding Conventions
Richard M. Stallman's avatar
Richard M. Stallman committed
37

38
@cindex coding conventions in Emacs Lisp
39 40
  Here are conventions that you should follow when writing Emacs Lisp
code intended for widespread use:
Richard M. Stallman's avatar
Richard M. Stallman committed
41 42

@itemize @bullet
43 44 45 46 47 48 49 50 51 52
@item
Simply loading the package should not change Emacs's editing behavior.
Include a command or commands to enable and disable the feature,
or to invoke it.

This convention is mandatory for any file that includes custom
definitions.  If fixing such a file to follow this convention requires
an incompatible change, go ahead and make the incompatible change;
don't postpone it.

Richard M. Stallman's avatar
Richard M. Stallman committed
53
@item
Richard M. Stallman's avatar
Richard M. Stallman committed
54 55
Since all global variables share the same name space, and all
functions share another name space, you should choose a short word to
56
distinguish your program from other Lisp programs@footnote{The
Richard M. Stallman's avatar
Richard M. Stallman committed
57
benefits of a Common Lisp-style package system are considered not to
58
outweigh the costs.}.  Then take care to begin the names of all global
Richard M. Stallman's avatar
Richard M. Stallman committed
59
variables, constants, and functions in your program with the chosen
60 61 62 63 64 65 66
prefix.  This helps avoid name conflicts.

Occasionally, for a command name intended for users to use, it is more
convenient if some words come before the package's name prefix.  And
constructs that define functions, variables, etc., work better if they
start with @samp{defun} or @samp{defvar}, so put the name prefix later
on in the name.
Richard M. Stallman's avatar
Richard M. Stallman committed
67 68

This recommendation applies even to names for traditional Lisp
69
primitives that are not primitives in Emacs Lisp---such as
70 71 72 73
@code{copy-list}.  Believe it or not, there is more than one plausible
way to define @code{copy-list}.  Play it safe; append your name prefix
to produce a name like @code{foo-copy-list} or @code{mylib-copy-list}
instead.
Richard M. Stallman's avatar
Richard M. Stallman committed
74 75 76 77

If you write a function that you think ought to be added to Emacs under
a certain name, such as @code{twiddle-files}, don't call it by that name
in your program.  Call it @code{mylib-twiddle-files} in your program,
78
and send mail to @samp{bug-gnu-emacs@@gnu.org} suggesting we add
Richard M. Stallman's avatar
Richard M. Stallman committed
79 80
it to Emacs.  If and when we do, we can change the name easily enough.

81
If one prefix is insufficient, your package can use two or three
Richard M. Stallman's avatar
Richard M. Stallman committed
82 83 84 85 86 87 88
alternative common prefixes, so long as they make sense.

Separate the prefix from the rest of the symbol name with a hyphen,
@samp{-}.  This will be consistent with Emacs itself and with most Emacs
Lisp programs.

@item
89
Put a call to @code{provide} at the end of each separate Lisp file.
Richard M. Stallman's avatar
Richard M. Stallman committed
90

Karl Heuer's avatar
Karl Heuer committed
91
@item
92
If a file requires certain other Lisp programs to be loaded
Karl Heuer's avatar
Karl Heuer committed
93 94 95
beforehand, then the comments at the beginning of the file should say
so.  Also, use @code{require} to make sure they are loaded.

Richard M. Stallman's avatar
Richard M. Stallman committed
96 97
@item
If one file @var{foo} uses a macro defined in another file @var{bar},
Karl Heuer's avatar
Karl Heuer committed
98 99 100 101 102 103 104 105
@var{foo} should contain this expression before the first use of the
macro:

@example
(eval-when-compile (require '@var{bar}))
@end example

@noindent
106 107 108 109 110
(And the library @var{bar} should contain @code{(provide '@var{bar})},
to make the @code{require} work.)  This will cause @var{bar} to be
loaded when you byte-compile @var{foo}.  Otherwise, you risk compiling
@var{foo} without the necessary macro loaded, and that would produce
compiled code that won't work right.  @xref{Compiling Macros}.
Karl Heuer's avatar
Karl Heuer committed
111 112 113

Using @code{eval-when-compile} avoids loading @var{bar} when
the compiled version of @var{foo} is @emph{used}.
Richard M. Stallman's avatar
Richard M. Stallman committed
114

Karl Heuer's avatar
Karl Heuer committed
115 116 117 118 119 120 121
@item
Please don't require the @code{cl} package of Common Lisp extensions at
run time.  Use of this package is optional, and it is not part of the
standard Emacs namespace.  If your package loads @code{cl} at run time,
that could cause name clashes for users who don't use that package.

However, there is no problem with using the @code{cl} package at compile
122
time, with @code{(eval-when-compile (require 'cl))}.
Karl Heuer's avatar
Karl Heuer committed
123

Richard M. Stallman's avatar
Richard M. Stallman committed
124
@item
125 126 127 128 129 130
When defining a major mode, please follow the major mode
conventions.  @xref{Major Mode Conventions}.

@item
When defining a minor mode, please follow the minor mode
conventions.  @xref{Minor Mode Conventions}.
Richard M. Stallman's avatar
Richard M. Stallman committed
131

132 133 134 135 136 137 138 139 140 141
@item
If the purpose of a function is to tell you whether a certain condition
is true or false, give the function a name that ends in @samp{p}.  If
the name is one word, add just @samp{p}; if the name is multiple words,
add @samp{-p}.  Examples are @code{framep} and @code{frame-live-p}.

@item
If a user option variable records a true-or-false condition, give it a
name that ends in @samp{-flag}.

142 143 144 145 146 147
@item
If the purpose of a variable is to store a single function, give it a
name that ends in @samp{-function}.  If the purpose of a variable is
to store a list of functions (i.e., the variable is a hook), please
follow the naming conventions for hooks.  @xref{Hooks}.

148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176
@item
@cindex unloading packages
If loading the file adds functions to hooks, define a function
@code{@var{feature}-unload-hook}, where @var{feature} is the name of
the feature the package provides, and make it undo any such changes.
Using @code{unload-feature} to unload the file will run this function.
@xref{Unloading}.

@item
It is a bad idea to define aliases for the Emacs primitives.  Normally
you should use the standard names instead.  The case where an alias
may be useful is where it facilitates backwards compatibility or
portability.

@item
If a package needs to define an alias or a new function for
compatibility with some other version of Emacs, name it with the package
prefix, not with the raw name with which it occurs in the other version.
Here is an example from Gnus, which provides many examples of such
compatibility issues.

@example
(defalias 'gnus-point-at-bol
  (if (fboundp 'point-at-bol)
      'point-at-bol
    'line-beginning-position))
@end example

@item
177
Redefining (or advising) an Emacs primitive is a bad idea.  It may do
178
the right thing for a particular program, but there is no telling what
179
other programs might break as a result.  In any case, it is a problem
180 181 182
for debugging, because the advised function doesn't do what its source
code says it does.  If the programmer investigating the problem is
unaware that there is advice on the function, the experience can be
183 184 185 186 187 188 189 190
very frustrating.

We hope to remove all the places in Emacs that advise primitives.
In the mean time, please don't add any more.

@item
It is likewise a bad idea for one Lisp package to advise a function
in another Lisp package.
191 192 193 194

@item
Likewise, avoid using @code{eval-after-load} (@pxref{Hooks for
Loading}) in libraries and packages.  This feature is meant for
195 196 197 198
personal customizations; using it in a Lisp program is unclean,
because it modifies the behavior of another Lisp file in a way that's
not visible in that file.  This is an obstacle for debugging, much
like advising a function in the other package.
199 200 201 202 203 204 205 206

@item
If a file does replace any of the functions or library programs of
standard Emacs, prominent comments at the beginning of the file should
say which functions are replaced, and how the behavior of the
replacements differs from that of the originals.

@item
207 208 209 210 211 212 213 214
Constructs that define a function or variable should be macros,
not functions, and their names should start with @samp{def}.

@item
Macros that define a functions or variables should take the name to be
defined as the first argument.  That will help various tools find the
definition automatically.  Avoid constructing the names in the macro
itself, since that would confuse these tools.
215 216 217 218 219 220 221 222 223 224 225 226 227 228

@item
Please keep the names of your Emacs Lisp source files to 13 characters
or less.  This way, if the files are compiled, the compiled files' names
will be 14 characters or less, which is short enough to fit on all kinds
of Unix systems.

@item
In some other systems there is a convention of choosing variable names
that begin and end with @samp{*}.  We don't use that convention in Emacs
Lisp, so please don't use it in your programs.  (Emacs uses such names
only for special-purpose buffers.)  The users will find Emacs more
coherent if all libraries use the same conventions.

229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252
@item
If your program contains non-ASCII characters in string or character
constants, you should make sure Emacs always decodes these characters
the same way, regardless of the user's settings.  There are two ways
to do that:

@itemize -
@item
Use coding system @code{emacs-mule}, and specify that for
@code{coding} in the @samp{-*-} line or the local variables list.

@example
;; XXX.el  -*- coding: emacs-mule; -*-
@end example

@item
Use one of the coding systems based on ISO 2022 (such as
iso-8859-@var{n} and iso-2022-7bit), and specify it with @samp{!} at
the end for @code{coding}.  (The @samp{!} turns off any possible
character translation.)

@example
;; XXX.el -*- coding: iso-latin-2!; -*-
@end example
253
@end itemize
254

255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283
@item
Indent each function with @kbd{C-M-q} (@code{indent-sexp}) using the
default indentation parameters.

@item
Don't make a habit of putting close-parentheses on lines by themselves;
Lisp programmers find this disconcerting.  Once in a while, when there
is a sequence of many consecutive close-parentheses, it may make sense
to split the sequence in one or two significant places.

@item
Please put a copyright notice and copying permission notice on the
file if you distribute copies.  Use a notice like this one:

@smallexample
;; Copyright (C) @var{year} @var{name}

;; This program is free software; you can redistribute it and/or
;; modify it under the terms of the GNU General Public License as
;; published by the Free Software Foundation; either version 2 of
;; the License, or (at your option) any later version.

;; This program is distributed in the hope that it will be
;; useful, but WITHOUT ANY WARRANTY; without even the implied
;; warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR
;; PURPOSE.  See the GNU General Public License for more details.

;; You should have received a copy of the GNU General Public
;; License along with this program; if not, write to the Free
Karl Berry's avatar
Karl Berry committed
284 285
;; Software Foundation, Inc., 51 Franklin Street, Fifth Floor,
;; Boston, MA 02110-1301 USA
286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307
@end smallexample

If you have signed papers to assign the copyright to the Foundation,
then use @samp{Free Software Foundation, Inc.} as @var{name}.
Otherwise, use your name.  See also @xref{Library Headers}.
@end itemize

@node Key Binding Conventions
@section Key Binding Conventions

@itemize @bullet
@item
@cindex mouse-2
@cindex references, following
Special major modes used for read-only text should usually redefine
@kbd{mouse-2} and @key{RET} to trace some sort of reference in the text.
Modes such as Dired, Info, Compilation, and Occur redefine it in this
way.

In addition, they should mark the text as a kind of ``link'' so that
@kbd{mouse-1} will follow it also.  @xref{Links and Mouse-1}.

Richard M. Stallman's avatar
Richard M. Stallman committed
308
@item
309 310
@cindex reserved keys
@cindex keys, reserved
311 312 313 314
Please do not define @kbd{C-c @var{letter}} as a key in Lisp programs.
Sequences consisting of @kbd{C-c} and a letter (either upper or lower
case) are reserved for users; they are the @strong{only} sequences
reserved for users, so do not block them.
Richard M. Stallman's avatar
Richard M. Stallman committed
315

316 317 318
Changing all the Emacs major modes to respect this convention was a
lot of work; abandoning this convention would make that work go to
waste, and inconvenience users.  Please comply with it.
Richard M. Stallman's avatar
Richard M. Stallman committed
319

320 321 322 323 324 325 326 327 328 329
@item
Function keys @key{F5} through @key{F9} without modifier keys are
also reserved for users to define.

@item
Applications should not bind mouse events based on button 1 with the
shift key held down.  These events include @kbd{S-mouse-1},
@kbd{M-S-mouse-1}, @kbd{C-S-mouse-1}, and so on.  They are reserved for
users.

330 331 332
@item
Sequences consisting of @kbd{C-c} followed by a control character or a
digit are reserved for major modes.
333 334 335 336 337 338 339 340 341 342

@item
Sequences consisting of @kbd{C-c} followed by @kbd{@{}, @kbd{@}},
@kbd{<}, @kbd{>}, @kbd{:} or @kbd{;} are also reserved for major modes.

@item
Sequences consisting of @kbd{C-c} followed by any other punctuation
character are allocated for minor modes.  Using them in a major mode is
not absolutely prohibited, but if you do that, the major mode binding
may be shadowed from time to time by minor modes.
Richard M. Stallman's avatar
Richard M. Stallman committed
343 344

@item
345
Do not bind @kbd{C-h} following any prefix character (including
Richard M. Stallman's avatar
Richard M. Stallman committed
346 347 348 349
@kbd{C-c}).  If you don't bind @kbd{C-h}, it is automatically available
as a help character for listing the subcommands of the prefix character.

@item
350
Do not bind a key sequence ending in @key{ESC} except following
351
another @key{ESC}.  (That is, it is OK to bind a sequence ending in
Richard M. Stallman's avatar
Richard M. Stallman committed
352 353 354 355 356 357
@kbd{@key{ESC} @key{ESC}}.)

The reason for this rule is that a non-prefix binding for @key{ESC} in
any context prevents recognition of escape sequences as function keys in
that context.

358 359
@item
Anything which acts like a temporary mode or state which the user can
Karl Heuer's avatar
Karl Heuer committed
360
enter and leave should define @kbd{@key{ESC} @key{ESC}} or
361 362 363 364 365 366 367 368 369
@kbd{@key{ESC} @key{ESC} @key{ESC}} as a way to escape.

For a state which accepts ordinary Emacs commands, or more generally any
kind of state in which @key{ESC} followed by a function key or arrow key
is potentially meaningful, then you must not define @kbd{@key{ESC}
@key{ESC}}, since that would preclude recognizing an escape sequence
after @key{ESC}.  In these states, you should define @kbd{@key{ESC}
@key{ESC} @key{ESC}} as the way to escape.  Otherwise, define
@kbd{@key{ESC} @key{ESC}} instead.
370
@end itemize
371

372 373
@node Programming Tips
@section Emacs Programming Tips
374

375 376
  Following these conventions will make your program fit better
into Emacs when it runs.
Richard M. Stallman's avatar
Richard M. Stallman committed
377

378
@itemize @bullet
Richard M. Stallman's avatar
Richard M. Stallman committed
379 380 381 382 383 384
@item
Don't use @code{next-line} or @code{previous-line} in programs; nearly
always, @code{forward-line} is more convenient as well as more
predictable and robust.  @xref{Text Lines}.

@item
385 386 387 388
Don't call functions that set the mark, unless setting the mark is one
of the intended features of your program.  The mark is a user-level
feature, so it is incorrect to change the mark except to supply a value
for the user's benefit.  @xref{The Mark}.
Richard M. Stallman's avatar
Richard M. Stallman committed
389

390
In particular, don't use any of these functions:
Richard M. Stallman's avatar
Richard M. Stallman committed
391 392 393 394 395 396

@itemize @bullet
@item
@code{beginning-of-buffer}, @code{end-of-buffer}
@item
@code{replace-string}, @code{replace-regexp}
397 398
@item
@code{insert-file}, @code{insert-buffer}
Richard M. Stallman's avatar
Richard M. Stallman committed
399 400
@end itemize

401 402 403 404
If you just want to move point, or replace a certain string, or insert
a file or buffer's contents, without any of the other features
intended for interactive users, you can replace these functions with
one or two lines of simple Lisp code.
Richard M. Stallman's avatar
Richard M. Stallman committed
405

Richard M. Stallman's avatar
Richard M. Stallman committed
406 407 408 409 410 411 412 413 414
@item
Use lists rather than vectors, except when there is a particular reason
to use a vector.  Lisp has more facilities for manipulating lists than
for vectors, and working with lists is usually more convenient.

Vectors are advantageous for tables that are substantial in size and are
accessed in random order (not searched front to back), provided there is
no need to insert or delete elements (only lists allow that).

Richard M. Stallman's avatar
Richard M. Stallman committed
415
@item
416
The recommended way to show a message in the echo area is with
Richard M. Stallman's avatar
Richard M. Stallman committed
417 418 419 420 421 422 423 424 425 426
the @code{message} function, not @code{princ}.  @xref{The Echo Area}.

@item
When you encounter an error condition, call the function @code{error}
(or @code{signal}).  The function @code{error} does not return.
@xref{Signaling Errors}.

Do not use @code{message}, @code{throw}, @code{sleep-for},
or @code{beep} to report errors.

Karl Heuer's avatar
Karl Heuer committed
427 428 429 430
@item
An error message should start with a capital letter but should not end
with a period.

431 432 433 434 435 436 437 438 439 440 441
@item
A question asked in the minibuffer with @code{y-or-n-p} or
@code{yes-or-no-p} should start with a capital letter and end with
@samp{? }.

@item
When you mention a default value in a minibuffer prompt,
put it and the word @samp{default} inside parentheses.
It should look like this:

@example
442
Enter the answer (default 42):
443 444
@end example

445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480
@item
In @code{interactive}, if you use a Lisp expression to produce a list
of arguments, don't try to provide the ``correct'' default values for
region or position arguments.  Instead, provide @code{nil} for those
arguments if they were not specified, and have the function body
compute the default value when the argument is @code{nil}.  For
instance, write this:

@example
(defun foo (pos)
  (interactive
   (list (if @var{specified} @var{specified-pos})))
  (unless pos (setq pos @var{default-pos}))
  ...)
@end example

@noindent
rather than this:

@example
(defun foo (pos)
  (interactive
   (list (if @var{specified} @var{specified-pos}
             @var{default-pos})))
  ...)
@end example

@noindent
This is so that repetition of the command will recompute
these defaults based on the current circumstances.

You do not need to take such precautions when you use interactive
specs @samp{d}, @samp{m} and @samp{r}, because they make special
arrangements to recompute the argument values on repetition of the
command.

481 482
@item
Many commands that take a long time to execute display a message that
483
says something like @samp{Operating...} when they start, and change it to
484 485
@samp{Operating...done} when they finish.  Please keep the style of
these messages uniform: @emph{no} space around the ellipsis, and
486
@emph{no} period after @samp{done}.
487

Richard M. Stallman's avatar
Richard M. Stallman committed
488
@item
489 490 491 492 493
Try to avoid using recursive edits.  Instead, do what the Rmail @kbd{e}
command does: use a new local keymap that contains one command defined
to switch back to the old local keymap.  Or do what the
@code{edit-options} command does: switch to another buffer and let the
user switch back at will.  @xref{Recursive Editing}.
Richard M. Stallman's avatar
Richard M. Stallman committed
494 495 496 497 498 499 500 501
@end itemize

@node Compilation Tips
@section Tips for Making Compiled Code Fast
@cindex execution speed
@cindex speedups

  Here are ways of improving the execution speed of byte-compiled
502
Lisp programs.
Richard M. Stallman's avatar
Richard M. Stallman committed
503 504 505 506 507

@itemize @bullet
@item
@cindex profiling
@cindex timing programs
508
@cindex @file{elp.el}
509 510
Profile your program with the @file{elp} library.  See the file
@file{elp.el} for instructions.
Richard M. Stallman's avatar
Richard M. Stallman committed
511

512 513 514 515 516 517 518
@item
@cindex @file{benchmark.el}
@cindex benchmarking
Check the speed of individual Emacs Lisp forms using the
@file{benchmark} library.  See the functions @code{benchmark-run} and
@code{benchmark-run-compiled} in @file{benchmark.el}.

Richard M. Stallman's avatar
Richard M. Stallman committed
519 520 521 522 523 524
@item
Use iteration rather than recursion whenever possible.
Function calls are slow in Emacs Lisp even when a compiled function
is calling another compiled function.

@item
Karl Heuer's avatar
Karl Heuer committed
525 526
Using the primitive list-searching functions @code{memq}, @code{member},
@code{assq}, or @code{assoc} is even faster than explicit iteration.  It
527
can be worth rearranging a data structure so that one of these primitive
Karl Heuer's avatar
Karl Heuer committed
528
search functions can be used.
Richard M. Stallman's avatar
Richard M. Stallman committed
529 530

@item
531
Certain built-in functions are handled specially in byte-compiled code,
Richard M. Stallman's avatar
Richard M. Stallman committed
532 533 534 535 536 537 538
avoiding the need for an ordinary function call.  It is a good idea to
use these functions rather than alternatives.  To see whether a function
is handled specially by the compiler, examine its @code{byte-compile}
property.  If the property is non-@code{nil}, then the function is
handled specially.

For example, the following input will show you that @code{aref} is
539
compiled specially (@pxref{Array Functions}):
Richard M. Stallman's avatar
Richard M. Stallman committed
540

541
@example
Richard M. Stallman's avatar
Richard M. Stallman committed
542 543 544 545
@group
(get 'aref 'byte-compile)
     @result{} byte-compile-two-args
@end group
546
@end example
Richard M. Stallman's avatar
Richard M. Stallman committed
547 548

@item
549
If calling a small function accounts for a substantial part of your
Richard M. Stallman's avatar
Richard M. Stallman committed
550 551 552
program's running time, make the function inline.  This eliminates
the function call overhead.  Since making a function inline reduces
the flexibility of changing the program, don't do it unless it gives
553
a noticeable speedup in something slow enough that users care about
Richard M. Stallman's avatar
Richard M. Stallman committed
554 555 556
the speed.  @xref{Inline Functions}.
@end itemize

557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596
@node Warning Tips
@section Tips for Avoiding Compiler Warnings

@itemize @bullet
@item
Try to avoid compiler warnings about undefined free variables, by adding
dummy @code{defvar} definitions for these variables, like this:

@example
(defvar foo)
@end example

Such a definition has no effect except to tell the compiler
not to warn about uses of the variable @code{foo} in this file.

@item
If you use many functions and variables from a certain file, you can
add a @code{require} for that package to avoid compilation warnings
for them.  For instance,

@example
(eval-when-compile
  (require 'foo))
@end example

@item
If you bind a variable in one function, and use it or set it in
another function, the compiler warns about the latter function unless
the variable has a definition.  But adding a definition would be
unclean if the variable has a short name, since Lisp packages should
not define short variable names.  The right thing to do is to rename
this variable to start with the name prefix used for the other
functions and variables in your package.

@item
The last resort for avoiding a warning, when you want to do something
that usually is a mistake but it's not a mistake in this one case,
is to put a call to @code{with-no-warnings} around it.
@end itemize

Richard M. Stallman's avatar
Richard M. Stallman committed
597 598 599
@node Documentation Tips
@section Tips for Documentation Strings

600 601 602 603
@findex checkdoc-minor-mode
  Here are some tips and conventions for the writing of documentation
strings.  You can check many of these conventions by running the command
@kbd{M-x checkdoc-minor-mode}.
Richard M. Stallman's avatar
Richard M. Stallman committed
604 605 606

@itemize @bullet
@item
607
Every command, function, or variable intended for users to know about
Richard M. Stallman's avatar
Richard M. Stallman committed
608 609 610
should have a documentation string.

@item
611 612 613
An internal variable or subroutine of a Lisp program might as well have
a documentation string.  In earlier Emacs versions, you could save space
by using a comment instead of a documentation string, but that is no
614 615
longer the case---documentation strings now take up very little space in
a running Emacs.
Richard M. Stallman's avatar
Richard M. Stallman committed
616

Richard M. Stallman's avatar
Richard M. Stallman committed
617 618 619 620 621 622 623 624 625 626 627
@item
Format the documentation string so that it fits in an Emacs window on an
80-column screen.  It is a good idea for most lines to be no wider than
60 characters.  The first line should not be wider than 67 characters
or it will look bad in the output of @code{apropos}.

You can fill the text if that looks good.  However, rather than blindly
filling the entire documentation string, you can often make it much more
readable by choosing certain line breaks with care.  Use blank lines
between topics if the documentation string is long.

Richard M. Stallman's avatar
Richard M. Stallman committed
628 629
@item
The first line of the documentation string should consist of one or two
630
complete sentences that stand on their own as a summary.  @kbd{M-x
631 632 633
apropos} displays just the first line, and if that line's contents don't
stand on their own, the result looks bad.  In particular, start the
first line with a capital letter and end with a period.
Richard M. Stallman's avatar
Richard M. Stallman committed
634

635 636 637 638 639 640 641
For a function, the first line should briefly answer the question,
``What does this function do?''  For a variable, the first line should
briefly answer the question, ``What does this value mean?''

Don't limit the documentation string to one line; use as many lines as
you need to explain the details of how to use the function or
variable.  Please use complete sentences for the rest of the text too.
Richard M. Stallman's avatar
Richard M. Stallman committed
642

643 644 645 646 647 648 649 650
@item
The first line should mention all the important arguments of the
function, and should mention them in the order that they are written
in a function call.  If the function has many arguments, then it is
not feasible to mention them all in the first line; in that case, the
first line should mention the first few arguments, including the most
important arguments.

651
@item
652
For consistency, phrase the verb in the first sentence of a function's
653
documentation string as an imperative---for instance, use ``Return the
654 655 656
cons of A and B.'' in preference to ``Returns the cons of A and B@.''
Usually it looks good to do likewise for the rest of the first
paragraph.  Subsequent paragraphs usually look better if each sentence
Richard M. Stallman's avatar
Richard M. Stallman committed
657
is indicative and has a proper subject.
658

Richard M. Stallman's avatar
Richard M. Stallman committed
659 660 661 662 663 664 665 666 667 668 669
@item
Write documentation strings in the active voice, not the passive, and in
the present tense, not the future.  For instance, use ``Return a list
containing A and B.'' instead of ``A list containing A and B will be
returned.''

@item
Avoid using the word ``cause'' (or its equivalents) unnecessarily.
Instead of, ``Cause Emacs to display text in boldface,'' write just
``Display text in boldface.''

670 671 672 673 674 675 676 677 678
@item
When a command is meaningful only in a certain mode or situation,
do mention that in the documentation string.  For example,
the documentation of @code{dired-find-file} is:

@example
In Dired, visit the file or directory named on this line.
@end example

Richard M. Stallman's avatar
Richard M. Stallman committed
679 680
@item
Do not start or end a documentation string with whitespace.
681

Richard M. Stallman's avatar
Richard M. Stallman committed
682 683 684 685 686 687 688
@item
@strong{Do not} indent subsequent lines of a documentation string so
that the text is lined up in the source code with the text of the first
line.  This looks nice in the source code, but looks bizarre when users
view the documentation.  Remember that the indentation before the
starting double-quote is not part of the string!

689 690 691 692 693 694
@item
When the user tries to use a disabled command, Emacs displays just the
first paragraph of its documentation string---everything through the
first blank line.  If you wish, you can choose which information to
include before the first blank line so as to make this display useful.

Richard M. Stallman's avatar
Richard M. Stallman committed
695
@item
696
When you define a variable that users ought to set interactively, you
697
normally should use @code{defcustom}.  However, if for some reason you
698 699
use @code{defvar} instead, start the doc string with a @samp{*}.
@xref{Defining Variables}.
Richard M. Stallman's avatar
Richard M. Stallman committed
700 701 702

@item
The documentation string for a variable that is a yes-or-no flag should
703 704 705
start with words such as ``Non-nil means@dots{}'', to make it clear that
all non-@code{nil} values are equivalent and indicate explicitly what
@code{nil} and non-@code{nil} mean.
Richard M. Stallman's avatar
Richard M. Stallman committed
706

707 708 709 710 711 712 713
@item
The documentation string for a function that is a yes-or-no predicate
should start with words such as ``Return t if @dots{}'', to indicate
explicitly what constitutes ``truth''.  The word ``return'' avoids
starting the sentence with lower-case ``t'', which is somewhat
distracting.

Richard M. Stallman's avatar
Richard M. Stallman committed
714 715 716 717
@item
When a function's documentation string mentions the value of an argument
of the function, use the argument name in capital letters as if it were
a name for that value.  Thus, the documentation string of the function
718 719 720 721 722 723
@code{eval} refers to its second argument as @samp{FORM}, because the
actual argument name is @code{form}:

@example
Evaluate FORM and return its value.
@end example
Richard M. Stallman's avatar
Richard M. Stallman committed
724

725 726 727
Also write metasyntactic variables in capital letters, such as when you
show the decomposition of a list or vector into subunits, some of which
may vary.  @samp{KEY} and @samp{VALUE} in the following example
728 729 730 731 732 733
illustrate this practice:

@example
The argument TABLE should be an alist whose elements
have the form (KEY . VALUE).  Here, KEY is ...
@end example
Richard M. Stallman's avatar
Richard M. Stallman committed
734

735 736 737 738 739 740 741 742 743 744 745 746 747 748
@item
Never change the case of a Lisp symbol when you mention it in a doc
string.  If the symbol's name is @code{foo}, write ``foo'', not
``Foo'' (which is a different symbol).

This might appear to contradict the policy of writing function
argument values, but there is no real contradiction; the argument
@emph{value} is not the same thing as the @emph{symbol} which the
function uses to hold the value.

If this puts a lower-case letter at the beginning of a sentence
and that annoys you, rewrite the sentence so that the symbol
is not at the start of it.

749 750 751 752 753 754 755 756 757 758 759 760
@item
If a line in a documentation string begins with an open-parenthesis,
write a backslash before the open-parenthesis, like this:

@example
The argument FOO can be either a number
\(a buffer position) or a string (a file name).
@end example

This prevents the open-parenthesis from being treated as the start of a
defun (@pxref{Defuns,, Defuns, emacs, The GNU Emacs Manual}).

761
@anchor{Docstring hyperlinks}
Richard M. Stallman's avatar
Richard M. Stallman committed
762 763 764 765 766 767 768
@item
@iftex
When a documentation string refers to a Lisp symbol, write it as it
would be printed (which usually means in lower case), with single-quotes
around it.  For example: @samp{`lambda'}.  There are two exceptions:
write @code{t} and @code{nil} without single-quotes.
@end iftex
Gerd Moellmann's avatar
Gerd Moellmann committed
769
@ifnottex
Richard M. Stallman's avatar
Richard M. Stallman committed
770 771 772
When a documentation string refers to a Lisp symbol, write it as it
would be printed (which usually means in lower case), with single-quotes
around it.  For example: @samp{lambda}.  There are two exceptions: write
773 774
t and nil without single-quotes.  (In this manual, we use a different
convention, with single-quotes for all symbols.)
Gerd Moellmann's avatar
Gerd Moellmann committed
775
@end ifnottex
Richard M. Stallman's avatar
Richard M. Stallman committed
776

777 778
Help mode automatically creates a hyperlink when a documentation string
uses a symbol name inside single quotes, if the symbol has either a
779 780 781 782 783 784 785 786 787 788 789 790 791 792 793 794 795 796
function or a variable definition.  You do not need to do anything
special to make use of this feature.  However, when a symbol has both a
function definition and a variable definition, and you want to refer to
just one of them, you can specify which one by writing one of the words
@samp{variable}, @samp{option}, @samp{function}, or @samp{command},
immediately before the symbol name.  (Case makes no difference in
recognizing these indicator words.)  For example, if you write

@example
This function sets the variable `buffer-file-name'.
@end example

@noindent
then the hyperlink will refer only to the variable documentation of
@code{buffer-file-name}, and not to its function documentation.

If a symbol has a function definition and/or a variable definition, but
those are irrelevant to the use of the symbol that you are documenting,
797 798
you can write the words @samp{symbol} or @samp{program} before the
symbol name to prevent making any hyperlink.  For example,
799 800

@example
801 802 803
If the argument KIND-OF-RESULT is the symbol `list',
this function returns a list of all the objects
that satisfy the criterion.
804 805
@end example

806 807 808 809
@noindent
does not make a hyperlink to the documentation, irrelevant here, of the
function @code{list}.

810 811 812 813 814 815 816 817 818 819
Normally, no hyperlink is made for a variable without variable
documentation.  You can force a hyperlink for such variables by
preceding them with one of the words @samp{variable} or
@samp{option}.

Hyperlinks for faces are only made if the face name is preceded or
followed by the word @samp{face}.  In that case, only the face
documentation will be shown, even if the symbol is also defined as a
variable or as a function.

820
To make a hyperlink to Info documentation, write the name of the Info
821 822 823
node (or anchor) in single quotes, preceded by @samp{info node},
@samp{Info node}, @samp{info anchor} or @samp{Info anchor}.  The Info
file name defaults to @samp{emacs}.  For example,
824 825 826 827 828

@smallexample
See Info node `Font Lock' and Info node `(elisp)Font Lock Basics'.
@end smallexample

829 830 831 832 833 834 835 836
Finally, to create a hyperlink to URLs, write the URL in single
quotes, preceded by @samp{URL}. For example,

@smallexample
The home page for the GNU project has more information (see URL
`http://www.gnu.org/').
@end smallexample

Richard M. Stallman's avatar
Richard M. Stallman committed
837 838 839
@item
Don't write key sequences directly in documentation strings.  Instead,
use the @samp{\\[@dots{}]} construct to stand for them.  For example,
840 841 842 843 844
instead of writing @samp{C-f}, write the construct
@samp{\\[forward-char]}.  When Emacs displays the documentation string,
it substitutes whatever key is currently bound to @code{forward-char}.
(This is normally @samp{C-f}, but it may be some other character if the
user has moved key bindings.)  @xref{Keys in Documentation}.
Richard M. Stallman's avatar
Richard M. Stallman committed
845 846 847 848 849 850 851 852 853 854 855 856 857 858 859 860 861 862 863 864 865 866 867 868 869 870 871 872 873

@item
In documentation strings for a major mode, you will want to refer to the
key bindings of that mode's local map, rather than global ones.
Therefore, use the construct @samp{\\<@dots{}>} once in the
documentation string to specify which key map to use.  Do this before
the first use of @samp{\\[@dots{}]}.  The text inside the
@samp{\\<@dots{}>} should be the name of the variable containing the
local keymap for the major mode.

It is not practical to use @samp{\\[@dots{}]} very many times, because
display of the documentation string will become slow.  So use this to
describe the most important commands in your major mode, and then use
@samp{\\@{@dots{}@}} to display the rest of the mode's keymap.
@end itemize

@node Comment Tips
@section Tips on Writing Comments

  We recommend these conventions for where to put comments and how to
indent them:

@table @samp
@item ;
Comments that start with a single semicolon, @samp{;}, should all be
aligned to the same column on the right of the source code.  Such
comments usually explain how the code on the same line does its job.  In
Lisp mode and related modes, the @kbd{M-;} (@code{indent-for-comment})
command automatically inserts such a @samp{;} in the right place, or
874
aligns such a comment if it is already present.
Richard M. Stallman's avatar
Richard M. Stallman committed
875

876
This and following examples are taken from the Emacs sources.
Richard M. Stallman's avatar
Richard M. Stallman committed
877 878 879 880 881 882 883 884 885 886 887 888

@smallexample
@group
(setq base-version-list                 ; there was a base
      (assoc (substring fn 0 start-vn)  ; version to which
             file-version-assoc-list))  ; this looks like
                                        ; a subversion
@end group
@end smallexample

@item ;;
Comments that start with two semicolons, @samp{;;}, should be aligned to
889
the same level of indentation as the code.  Such comments usually
Richard M. Stallman's avatar
Richard M. Stallman committed
890 891 892 893 894 895 896 897
describe the purpose of the following lines or the state of the program
at that point.  For example:

@smallexample
@group
(prog1 (setq auto-fill-function
             @dots{}
             @dots{}
898
  ;; update mode line
Richard M. Stallman's avatar
Richard M. Stallman committed
899 900 901 902
  (force-mode-line-update)))
@end group
@end smallexample

903
We also normally use two semicolons for comments outside functions.
Richard M. Stallman's avatar
Richard M. Stallman committed
904 905 906

@smallexample
@group
907 908 909
;; This Lisp code is run in Emacs
;; when it is to operate as a server
;; for other processes.
Richard M. Stallman's avatar
Richard M. Stallman committed
910 911 912
@end group
@end smallexample

913 914 915 916 917 918 919 920 921 922 923
Every function that has no documentation string (presumably one that is
used only internally within the package it belongs to), should instead
have a two-semicolon comment right before the function, explaining what
the function does and how to call it properly.  Explain precisely what
each argument means and how the function interprets its possible values.

@item ;;;
Comments that start with three semicolons, @samp{;;;}, should start at
the left margin.  These are used, occasionally, for comments within
functions that should start at the margin.  We also use them sometimes
for comments that are between functions---whether to use two or three
924 925 926 927 928
semicolons depends on whether the comment should be considered a
``heading'' by Outline minor mode.  By default, comments starting with
at least three semicolons (followed by a single space and a
non-whitespace character) are considered headings, comments starting
with two or less are not.
929

930
Another use for triple-semicolon comments is for commenting out lines
931
within a function.  We use three semicolons for this precisely so that
932 933 934 935 936 937
they remain at the left margin.  By default, Outline minor mode does
not consider a comment to be a heading (even if it starts with at
least three semicolons) if the semicolons are followed by at least two
spaces.  Thus, if you add an introductory comment to the commented out
code, make sure to indent it by at least two spaces after the three
semicolons.
938 939 940

@smallexample
(defun foo (a)
941
;;;  This is no longer necessary.
942 943 944 945
;;;  (force-mode-line-update)
  (message "Finished with %s" a))
@end smallexample

946 947
When commenting out entire functions, use two semicolons.

Richard M. Stallman's avatar
Richard M. Stallman committed
948 949 950 951 952 953 954 955 956 957 958 959
@item ;;;;
Comments that start with four semicolons, @samp{;;;;}, should be aligned
to the left margin and are used for headings of major sections of a
program.  For example:

@smallexample
;;;; The kill ring
@end smallexample
@end table

@noindent
The indentation commands of the Lisp modes in Emacs, such as @kbd{M-;}
960
(@code{indent-for-comment}) and @key{TAB} (@code{lisp-indent-line}),
Richard M. Stallman's avatar
Richard M. Stallman committed
961
automatically indent comments according to these conventions,
962
depending on the number of semicolons.  @xref{Comments,,
Richard M. Stallman's avatar
Richard M. Stallman committed
963 964 965 966 967 968 969
Manipulating Comments, emacs, The GNU Emacs Manual}.

@node Library Headers
@section Conventional Headers for Emacs Libraries
@cindex header comments
@cindex library header comments

970
  Emacs has conventions for using special comments in Lisp libraries
Richard M. Stallman's avatar
Richard M. Stallman committed
971
to divide them into sections and give information such as who wrote
972 973 974 975 976 977 978 979 980 981 982 983 984 985 986
them.  This section explains these conventions.

  We'll start with an example, a package that is included in the Emacs
distribution.

  Parts of this example reflect its status as part of Emacs; for
example, the copyright notice lists the Free Software Foundation as the
copyright holder, and the copying permission says the file is part of
Emacs.  When you write a package and post it, the copyright holder would
be you (unless your employer claims to own it instead), and you should
get the suggested copying permission from the end of the GNU General
Public License itself.  Don't say your file is part of Emacs
if we haven't installed it in Emacs yet!

  With that warning out of the way, on to the example:
Richard M. Stallman's avatar
Richard M. Stallman committed
987 988 989 990 991 992 993 994 995 996 997 998 999 1000 1001 1002

@smallexample
@group
;;; lisp-mnt.el --- minor mode for Emacs Lisp maintainers

;; Copyright (C) 1992 Free Software Foundation, Inc.
@end group

;; Author: Eric S. Raymond <esr@@snark.thyrsus.com>
;; Maintainer: Eric S. Raymond <esr@@snark.thyrsus.com>
;; Created: 14 Jul 1992
;; Version: 1.2
@group
;; Keywords: docs

;; This file is part of GNU Emacs.
1003
@dots{}
Lute Kamstra's avatar
Lute Kamstra committed
1004 1005
;; Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor,
;; Boston, MA 02110-1301, USA.
Richard M. Stallman's avatar
Richard M. Stallman committed
1006 1007 1008 1009 1010 1011 1012 1013 1014 1015
@end group
@end smallexample

  The very first line should have this format:

@example
;;; @var{filename} --- @var{description}
@end example

@noindent
1016 1017
The description should be complete in one line.  If the file
needs a @samp{-*-} specification, put it after @var{description}.
Richard M. Stallman's avatar
Richard M. Stallman committed
1018 1019

  After the copyright notice come several @dfn{header comment} lines,
1020
each beginning with @samp{;; @var{header-name}:}.  Here is a table of
Richard M. Stallman's avatar
Richard M. Stallman committed
1021 1022 1023 1024 1025 1026 1027 1028
the conventional possibilities for @var{header-name}:

@table @samp
@item Author
This line states the name and net address of at least the principal
author of the library.

If there are multiple authors, you can list them on continuation lines
1029
led by @code{;;} and a tab character, like this:
Richard M. Stallman's avatar
Richard M. Stallman committed
1030 1031 1032 1033

@smallexample
@group
;; Author: Ashwin Ram <Ram-Ashwin@@cs.yale.edu>
1034 1035 1036
;;      Dave Sill <de5@@ornl.gov>
;;      Dave Brennan <brennan@@hal.com>
;;      Eric Raymond <esr@@snark.thyrsus.com>
Richard M. Stallman's avatar
Richard M. Stallman committed
1037 1038 1039 1040 1041
@end group
@end smallexample

@item Maintainer
This line should contain a single name/address as in the Author line, or
1042 1043 1044 1045
an address only, or the string @samp{FSF}.  If there is no maintainer
line, the person(s) in the Author field are presumed to be the
maintainers.  The example above is mildly bogus because the maintainer
line is redundant.
Richard M. Stallman's avatar
Richard M. Stallman committed
1046 1047 1048 1049 1050 1051 1052 1053 1054 1055 1056 1057 1058 1059 1060 1061 1062 1063 1064 1065 1066 1067 1068

The idea behind the @samp{Author} and @samp{Maintainer} lines is to make
possible a Lisp function to ``send mail to the maintainer'' without
having to mine the name out by hand.

Be sure to surround the network address with @samp{<@dots{}>} if
you include the person's full name as well as the network address.

@item Created
This optional line gives the original creation date of the
file.  For historical interest only.

@item Version
If you wish to record version numbers for the individual Lisp program, put
them in this line.

@item Adapted-By
In this header line, place the name of the person who adapted the
library for installation (to make it fit the style conventions, for
example).

@item Keywords
This line lists keywords for the @code{finder-by-keyword} help command.
1069 1070
Please use that command to see a list of the meaningful keywords.

Richard M. Stallman's avatar
Richard M. Stallman committed
1071
This field is important; it's how people will find your package when
Richard M. Stallman's avatar
Richard M. Stallman committed
1072 1073
they're looking for things by topic area.  To separate the keywords, you
can use spaces, commas, or both.
Richard M. Stallman's avatar
Richard M. Stallman committed
1074 1075 1076 1077 1078 1079 1080 1081
@end table

  Just about every Lisp library ought to have the @samp{Author} and
@samp{Keywords} header comment lines.  Use the others if they are
appropriate.  You can also put in header lines with other header
names---they have no standard meanings, so they can't do any harm.

  We use additional stylized comments to subdivide the contents of the
1082 1083
library file.  These should be separated by blank lines from anything
else.  Here is a table of them:
Richard M. Stallman's avatar
Richard M. Stallman committed
1084 1085 1086 1087

@table @samp
@item ;;; Commentary:
This begins introductory comments that explain how the library works.
1088 1089 1090 1091 1092
It should come right after the copying permissions, terminated by a
@samp{Change Log}, @samp{History} or @samp{Code} comment line.  This
text is used by the Finder package, so it should make sense in that
context.

Luc Teirlinck's avatar
Luc Teirlinck committed
1093
@item ;;; Documentation:
1094 1095
This was used in some files in place of @samp{;;; Commentary:},
but it is deprecated.
Richard M. Stallman's avatar
Richard M. Stallman committed
1096

1097
@item ;;; Change Log:
Richard M. Stallman's avatar
Richard M. Stallman committed
1098
This begins change log information stored in the library file (if you
1099 1100 1101 1102
store the change history there).  For Lisp files distributed with Emacs,
the change history is kept in the file @file{ChangeLog} and not in the
source file at all; these files generally do not have a @samp{;;; Change
Log:} line.  @samp{History} is an alternative to @samp{Change Log}.
Richard M. Stallman's avatar
Richard M. Stallman committed
1103 1104 1105 1106 1107 1108 1109 1110 1111

@item ;;; Code:
This begins the actual code of the program.

@item ;;; @var{filename} ends here
This is the @dfn{footer line}; it appears at the very end of the file.
Its purpose is to enable people to detect truncated versions of the file
from the lack of a footer line.
@end table
Miles Bader's avatar
Miles Bader committed
1112 1113 1114 1115

@ignore
   arch-tag: 9ea911c2-6b1d-47dd-88b7-0a94e8b27c2e
@end ignore