[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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.
You can automatically check some of the conventions described below by running the command 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.
D.1 Emacs Lisp Coding Conventions | Conventions for clean and robust programs. | |
D.2 Tips for Making Compiled Code Fast | Making compiled code run fast. | |
D.3 Tips for Documentation Strings | Writing readable documentation strings. | |
D.4 Tips on Writing Comments | Conventions for writing comments. | |
D.5 Conventional Headers for Emacs Libraries | Standard headers for library packages. |
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Here are conventions that you should follow when writing Emacs Lisp code intended for widespread use:
This recommendation applies even to names for traditional Lisp
primitives that are not primitives in Emacs Lisp--even to
copy-list
. Believe it or not, there is more than one plausible
way to define copy-list
. Play it safe; append your name prefix
to produce a name like foo-copy-list
or mylib-copy-list
instead.
If you write a function that you think ought to be added to Emacs under
a certain name, such as twiddle-files
, don't call it by that name
in your program. Call it mylib-twiddle-files
in your program,
and send mail to `[email protected]' suggesting we add
it to Emacs. If and when we do, we can change the name easily enough.
If one prefix is insufficient, your package may use two or three alternative common prefixes, so long as they make sense.
Separate the prefix from the rest of the symbol name with a hyphen, `-'. This will be consistent with Emacs itself and with most Emacs Lisp programs.
provide
in each separate
library program, at least if there is more than one entry point to the
program.
require
to make sure they are loaded.
(eval-when-compile (require 'bar)) |
(And the library bar should contain (provide 'bar)
,
to make the require
work.) This will cause bar to be
loaded when you byte-compile foo. Otherwise, you risk compiling
foo without the necessary macro loaded, and that would produce
compiled code that won't work right. See section 13.3 Macros and Byte Compilation.
Using eval-when-compile
avoids loading bar when
the compiled version of foo is used.
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 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 cl
package at compile
time, for the sake of macros. You do that like this:
(eval-when-compile (require 'cl)) |
framep
and frame-live-p
.
Instead, define sequences consisting of C-c followed by a control character, a digit, or certain punctuation characters. These sequences are reserved for major modes.
Changing all the Emacs major modes to follow this convention was a lot of work. Abandoning this convention would make that work go to waste, and inconvenience users.
The reason for this rule is that a non-prefix binding for ESC in any context prevents recognition of escape sequences as function keys in that context.
For a state which accepts ordinary Emacs commands, or more generally any kind of state in which ESC followed by a function key or arrow key is potentially meaningful, then you must not define ESC ESC, since that would preclude recognizing an escape sequence after ESC. In these states, you should define ESC ESC ESC as the way to escape. Otherwise, define ESC ESC instead.
whatever-mode
which turns the feature on or
off, and make it autoload (see section 15.4 Autoload). Design the package so
that simply loading it has no visible effect--that should not enable
the feature.(11) Users will request the feature by
invoking the command.
(defalias 'gnus-point-at-bol (if (fboundp 'point-at-bol) 'point-at-bol 'line-beginning-position)) |
next-line
or previous-line
in programs; nearly
always, forward-line
is more convenient as well as more
predictable and robust. See section 30.2.4 Motion by Text Lines.
In particular, don't use any of these functions:
beginning-of-buffer
, end-of-buffer
replace-string
, replace-regexp
If you just want to move point, or replace a certain string, without any of the other features intended for interactive users, you can replace these functions with one or two lines of simple Lisp code.
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).
message
function, not princ
. See section 38.4 The Echo Area.
error
(or signal
). The function error
does not return.
See section 10.5.3.1 How to Signal an Error.
Do not use message
, throw
, sleep-for
,
or beep
to report errors.
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 nil
for those
arguments if they were not specified, and have the function body
compute the default value when the argument is nil
. For
instance, write this:
(defun foo (pos) (interactive (list (if specified specified-pos))) (unless pos (setq pos default-pos)) ...) |
rather than this:
(defun foo (pos) (interactive (list (if specified specified-pos default-pos))) ...) |
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 `d', `m' and `r', because they make special arrangements to recompute the argument values on repetition of the command.
edit-options
command does: switch to another buffer and let the
user switch back at will. See section 21.12 Recursive Editing.
defvar
definitions for these variables.
Sometimes adding a require
for another package is useful to avoid
compilation warnings for variables and functions defined in that
package. If you do this, often it is better if the require
acts
only at compile time. Here's how to do that:
(eval-when-compile (require 'foo) (defvar bar-baz)) |
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 often these variables have short names, and it is not clean for Lisp packages to define such variable names. Therefore, you should rename the variable to start with the name prefix used for the other functions and variables in your package.
indent-sexp
) using the
default indentation parameters.
;; Copyright (C) year 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 ;; Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, ;; MA 02111-1307 USA |
If you have signed papers to assign the copyright to the Foundation, then use `Free Software Foundation, Inc.' as name. Otherwise, use your name.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Here are ways of improving the execution speed of byte-compiled Lisp programs.
memq
, member
,
assq
, or assoc
is even faster than explicit iteration. It
can be worth rearranging a data structure so that one of these primitive
search functions can be used.
byte-compile
property. If the property is non-nil
, then the function is
handled specially.
For example, the following input will show you that aref
is
compiled specially (see section 6.3 Functions that Operate on Arrays):
(get 'aref 'byte-compile) => byte-compile-two-args |
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Here are some tips and conventions for the writing of documentation strings. You can check many of these conventions by running the command M-x checkdoc-minor-mode.
The documentation string is not limited 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 in the additional lines.
dired-find-file
is:
In Dired, visit the file or directory named on this line. |
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.
nil
values are equivalent and indicate explicitly what
nil
and non-nil
mean.
eval
refers to its second argument as `FORM', because the
actual argument name is form
:
Evaluate FORM and return its value. |
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. `KEY' and `VALUE' in the following example illustrate this practice:
The argument TABLE should be an alist whose elements have the form (KEY . VALUE). Here, KEY is ... |
The argument FOO can be either a number \(a buffer position) or a string (a file name). |
This prevents the open-parenthesis from being treated as the start of a defun (see section `Defuns' in The GNU Emacs Manual).
Help mode automatically creates a hyperlink when a documentation string uses a symbol name inside single quotes, if the symbol has either a 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 `variable', `option', `function', or `command', immediately before the symbol name. (Case makes no difference in recognizing these indicator words.) For example, if you write
This function sets the variable `buffer-file-name'. |
then the hyperlink will refer only to the variable documentation of
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, you can write the word `symbol' before the symbol name to prevent making any hyperlink. For example,
If the argument KIND-OF-RESULT is the symbol `list', this function returns a list of all the objects that satisfy the criterion. |
does not make a hyperlink to the documentation, irrelevant here, of the
function list
.
To make a hyperlink to Info documentation, write the name of the Info node in single quotes, preceded by `info node' or `Info node'. The Info file name defaults to `emacs'. For example,
See Info node `Font Lock' and Info node `(elisp)Font Lock Basics'. |
forward-char
.
(This is normally `C-f', but it may be some other character if the
user has moved key bindings.) See section 24.3 Substituting Key Bindings in Documentation.
It is not practical to use `\\[...]' 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 `\\{...}' to display the rest of the mode's keymap.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
We recommend these conventions for where to put comments and how to indent them:
indent-for-comment
)
command automatically inserts such a `;' in the right place, or
aligns such a comment if it is already present.
This and following examples are taken from the Emacs sources.
(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 |
(prog1 (setq auto-fill-function ... ... ;; update mode line (force-mode-line-update))) |
We also normally use two semicolons for comments outside functions.
;; This Lisp code is run in Emacs ;; when it is to operate as a server ;; for other processes. |
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.
Another use for triple-semicolon comments is for commenting out lines within a function. We use three semicolons for this precisely so that they remain at the left margin.
(defun foo (a) ;;; This is no longer necessary. ;;; (force-mode-line-update) (message "Finished with %s" a)) |
;;;; The kill ring |
The indentation commands of the Lisp modes in Emacs, such as M-;
(indent-for-comment
) and TAB (lisp-indent-line
),
automatically indent comments according to these conventions,
depending on the number of semicolons. See section `Manipulating Comments' in The GNU Emacs Manual.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Emacs has conventions for using special comments in Lisp libraries to divide them into sections and give information such as who wrote 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:
;;; lisp-mnt.el --- minor mode for Emacs Lisp maintainers ;; Copyright (C) 1992 Free Software Foundation, Inc. ;; Author: Eric S. Raymond <[email protected]> ;; Maintainer: Eric S. Raymond <[email protected]> ;; Created: 14 Jul 1992 ;; Version: 1.2 ;; Keywords: docs ;; This file is part of GNU Emacs. ... ;; Free Software Foundation, Inc., 59 Temple Place - Suite 330, ;; Boston, MA 02111-1307, USA. |
The very first line should have this format:
;;; filename --- description |
The description should be complete in one line.
After the copyright notice come several header comment lines, each beginning with `;; header-name:'. Here is a table of the conventional possibilities for header-name:
If there are multiple authors, you can list them on continuation lines
led by ;;
and a tab character, like this:
;; Author: Ashwin Ram <[email protected]> ;; Dave Sill <[email protected]> ;; Dave Brennan <[email protected]> ;; Eric Raymond <[email protected]> |
The idea behind the `Author' and `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 `<...>' if you include the person's full name as well as the network address.
finder-by-keyword
help command.
Please use that command to see a list of the meaningful keywords.
This field is important; it's how people will find your package when they're looking for things by topic area. To separate the keywords, you can use spaces, commas, or both.
Just about every Lisp library ought to have the `Author' and `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 library file. These should be separated by blank lines from anything else. Here is a table of them:
[ << ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |