This is Info file ../../info/lispref.info, produced by Makeinfo version 1.68 from the input file lispref.texi. Edition History: GNU Emacs Lisp Reference Manual Second Edition (v2.01), May 1993 GNU Emacs Lisp Reference Manual Further Revised (v2.02), August 1993 Lucid Emacs Lisp Reference Manual (for 19.10) First Edition, March 1994 XEmacs Lisp Programmer's Manual (for 19.12) Second Edition, April 1995 GNU Emacs Lisp Reference Manual v2.4, June 1995 XEmacs Lisp Programmer's Manual (for 19.13) Third Edition, July 1995 XEmacs Lisp Reference Manual (for 19.14 and 20.0) v3.1, March 1996 XEmacs Lisp Reference Manual (for 19.15 and 20.1, 20.2) v3.2, April, May 1997 Copyright (C) 1990, 1991, 1992, 1993, 1994, 1995 Free Software Foundation, Inc. Copyright (C) 1994, 1995 Sun Microsystems, Inc. Copyright (C) 1995, 1996 Ben Wing. Permission is granted to make and distribute verbatim copies of this manual provided the copyright notice and this permission notice are preserved on all copies. Permission is granted to copy and distribute modified versions of this manual under the conditions for verbatim copying, provided that the entire resulting derived work is distributed under the terms of a permission notice identical to this one. Permission is granted to copy and distribute translations of this manual into another language, under the above conditions for modified versions, except that this permission notice may be stated in a translation approved by the Foundation. Permission is granted to copy and distribute modified versions of this manual under the conditions for verbatim copying, provided also that the section entitled "GNU General Public License" is included exactly as in the original, and provided that the entire resulting derived work is distributed under the terms of a permission notice identical to this one. Permission is granted to copy and distribute translations of this manual into another language, under the above conditions for modified versions, except that the section entitled "GNU General Public License" may be included in a translation approved by the Free Software Foundation instead of in the original English.  File: lispref.info, Node: Backquote, Next: Problems with Macros, Prev: Defining Macros, Up: Macros Backquote ========= Macros often need to construct large list structures from a mixture of constants and nonconstant parts. To make this easier, use the macro ``' (often called "backquote"). Backquote allows you to quote a list, but selectively evaluate elements of that list. In the simplest case, it is identical to the special form `quote' (*note Quoting::.). For example, these two forms yield identical results: `(a list of (+ 2 3) elements) => (a list of (+ 2 3) elements) '(a list of (+ 2 3) elements) => (a list of (+ 2 3) elements) The special marker `,' inside of the argument to backquote indicates a value that isn't constant. Backquote evaluates the argument of `,' and puts the value in the list structure: (list 'a 'list 'of (+ 2 3) 'elements) => (a list of 5 elements) `(a list of ,(+ 2 3) elements) => (a list of 5 elements) You can also "splice" an evaluated value into the resulting list, using the special marker `,@'. The elements of the spliced list become elements at the same level as the other elements of the resulting list. The equivalent code without using ``' is often unreadable. Here are some examples: (setq some-list '(2 3)) => (2 3) (cons 1 (append some-list '(4) some-list)) => (1 2 3 4 2 3) `(1 ,@some-list 4 ,@some-list) => (1 2 3 4 2 3) (setq list '(hack foo bar)) => (hack foo bar) (cons 'use (cons 'the (cons 'words (append (cdr list) '(as elements))))) => (use the words foo bar as elements) `(use the words ,@(cdr list) as elements) => (use the words foo bar as elements) Before Emacs version 19.29, ``' used a different syntax which required an extra level of parentheses around the entire backquote construct. Likewise, each `,' or `,@' substitution required an extra level of parentheses surrounding both the `,' or `,@' and the following expression. The old syntax required whitespace between the ``', `,' or `,@' and the following expression. This syntax is still accepted, but no longer recommended except for compatibility with old Emacs versions.  File: lispref.info, Node: Problems with Macros, Prev: Backquote, Up: Macros Common Problems Using Macros ============================ The basic facts of macro expansion have counterintuitive consequences. This section describes some important consequences that can lead to trouble, and rules to follow to avoid trouble. * Menu: * Argument Evaluation:: The expansion should evaluate each macro arg once. * Surprising Local Vars:: Local variable bindings in the expansion require special care. * Eval During Expansion:: Don't evaluate them; put them in the expansion. * Repeated Expansion:: Avoid depending on how many times expansion is done.  File: lispref.info, Node: Argument Evaluation, Next: Surprising Local Vars, Up: Problems with Macros Evaluating Macro Arguments Repeatedly ------------------------------------- When defining a macro you must pay attention to the number of times the arguments will be evaluated when the expansion is executed. The following macro (used to facilitate iteration) illustrates the problem. This macro allows us to write a simple "for" loop such as one might find in Pascal. (defmacro for (var from init to final do &rest body) "Execute a simple \"for\" loop. For example, (for i from 1 to 10 do (print i))." (list 'let (list (list var init)) (cons 'while (cons (list '<= var final) (append body (list (list 'inc var))))))) => for (for i from 1 to 3 do (setq square (* i i)) (princ (format "\n%d %d" i square))) ==> (let ((i 1)) (while (<= i 3) (setq square (* i i)) (princ (format "%d %d" i square)) (inc i))) -|1 1 -|2 4 -|3 9 => nil (The arguments `from', `to', and `do' in this macro are "syntactic sugar"; they are entirely ignored. The idea is that you will write noise words (such as `from', `to', and `do') in those positions in the macro call.) Here's an equivalent definition simplified through use of backquote: (defmacro for (var from init to final do &rest body) "Execute a simple \"for\" loop. For example, (for i from 1 to 10 do (print i))." `(let ((,var ,init)) (while (<= ,var ,final) ,@body (inc ,var)))) Both forms of this definition (with backquote and without) suffer from the defect that FINAL is evaluated on every iteration. If FINAL is a constant, this is not a problem. If it is a more complex form, say `(long-complex-calculation x)', this can slow down the execution significantly. If FINAL has side effects, executing it more than once is probably incorrect. A well-designed macro definition takes steps to avoid this problem by producing an expansion that evaluates the argument expressions exactly once unless repeated evaluation is part of the intended purpose of the macro. Here is a correct expansion for the `for' macro: (let ((i 1) (max 3)) (while (<= i max) (setq square (* i i)) (princ (format "%d %d" i square)) (inc i))) Here is a macro definition that creates this expansion: (defmacro for (var from init to final do &rest body) "Execute a simple for loop: (for i from 1 to 10 do (print i))." `(let ((,var ,init) (max ,final)) (while (<= ,var max) ,@body (inc ,var)))) Unfortunately, this introduces another problem. Proceed to the following node.  File: lispref.info, Node: Surprising Local Vars, Next: Eval During Expansion, Prev: Argument Evaluation, Up: Problems with Macros Local Variables in Macro Expansions ----------------------------------- In the previous section, the definition of `for' was fixed as follows to make the expansion evaluate the macro arguments the proper number of times: (defmacro for (var from init to final do &rest body) "Execute a simple for loop: (for i from 1 to 10 do (print i))." `(let ((,var ,init) (max ,final)) (while (<= ,var max) ,@body (inc ,var)))) The new definition of `for' has a new problem: it introduces a local variable named `max' which the user does not expect. This causes trouble in examples such as the following: (let ((max 0)) (for x from 0 to 10 do (let ((this (frob x))) (if (< max this) (setq max this))))) The references to `max' inside the body of the `for', which are supposed to refer to the user's binding of `max', really access the binding made by `for'. The way to correct this is to use an uninterned symbol instead of `max' (*note Creating Symbols::.). The uninterned symbol can be bound and referred to just like any other symbol, but since it is created by `for', we know that it cannot already appear in the user's program. Since it is not interned, there is no way the user can put it into the program later. It will never appear anywhere except where put by `for'. Here is a definition of `for' that works this way: (defmacro for (var from init to final do &rest body) "Execute a simple for loop: (for i from 1 to 10 do (print i))." (let ((tempvar (make-symbol "max"))) `(let ((,var ,init) (,tempvar ,final)) (while (<= ,var ,tempvar) ,@body (inc ,var))))) This creates an uninterned symbol named `max' and puts it in the expansion instead of the usual interned symbol `max' that appears in expressions ordinarily.  File: lispref.info, Node: Eval During Expansion, Next: Repeated Expansion, Prev: Surprising Local Vars, Up: Problems with Macros Evaluating Macro Arguments in Expansion --------------------------------------- Another problem can happen if you evaluate any of the macro argument expressions during the computation of the expansion, such as by calling `eval' (*note Eval::.). If the argument is supposed to refer to the user's variables, you may have trouble if the user happens to use a variable with the same name as one of the macro arguments. Inside the macro body, the macro argument binding is the most local binding of this variable, so any references inside the form being evaluated do refer to it. Here is an example: (defmacro foo (a) (list 'setq (eval a) t)) => foo (setq x 'b) (foo x) ==> (setq b t) => t ; and `b' has been set. ;; but (setq a 'c) (foo a) ==> (setq a t) => t ; but this set `a', not `c'. It makes a difference whether the user's variable is named `a' or `x', because `a' conflicts with the macro argument variable `a'. Another reason not to call `eval' in a macro definition is that it probably won't do what you intend in a compiled program. The byte-compiler runs macro definitions while compiling the program, when the program's own computations (which you might have wished to access with `eval') don't occur and its local variable bindings don't exist. The safe way to work with the run-time value of an expression is to put the expression into the macro expansion, so that its value is computed as part of executing the expansion.  File: lispref.info, Node: Repeated Expansion, Prev: Eval During Expansion, Up: Problems with Macros How Many Times is the Macro Expanded? ------------------------------------- Occasionally problems result from the fact that a macro call is expanded each time it is evaluated in an interpreted function, but is expanded only once (during compilation) for a compiled function. If the macro definition has side effects, they will work differently depending on how many times the macro is expanded. In particular, constructing objects is a kind of side effect. If the macro is called once, then the objects are constructed only once. In other words, the same structure of objects is used each time the macro call is executed. In interpreted operation, the macro is reexpanded each time, producing a fresh collection of objects each time. Usually this does not matter--the objects have the same contents whether they are shared or not. But if the surrounding program does side effects on the objects, it makes a difference whether they are shared. Here is an example: (defmacro empty-object () (list 'quote (cons nil nil))) (defun initialize (condition) (let ((object (empty-object))) (if condition (setcar object condition)) object)) If `initialize' is interpreted, a new list `(nil)' is constructed each time `initialize' is called. Thus, no side effect survives between calls. If `initialize' is compiled, then the macro `empty-object' is expanded during compilation, producing a single "constant" `(nil)' that is reused and altered each time `initialize' is called. One way to avoid pathological cases like this is to think of `empty-object' as a funny kind of constant, not as a memory allocation construct. You wouldn't use `setcar' on a constant such as `'(nil)', so naturally you won't use it on `(empty-object)' either.  File: lispref.info, Node: Loading, Next: Byte Compilation, Prev: Macros, Up: Top Loading ******* Loading a file of Lisp code means bringing its contents into the Lisp environment in the form of Lisp objects. XEmacs finds and opens the file, reads the text, evaluates each form, and then closes the file. The load functions evaluate all the expressions in a file just as the `eval-current-buffer' function evaluates all the expressions in a buffer. The difference is that the load functions read and evaluate the text in the file as found on disk, not the text in an Emacs buffer. The loaded file must contain Lisp expressions, either as source code or as byte-compiled code. Each form in the file is called a "top-level form". There is no special format for the forms in a loadable file; any form in a file may equally well be typed directly into a buffer and evaluated there. (Indeed, most code is tested this way.) Most often, the forms are function definitions and variable definitions. A file containing Lisp code is often called a "library". Thus, the "Rmail library" is a file containing code for Rmail mode. Similarly, a "Lisp library directory" is a directory of files containing Lisp code. * Menu: * How Programs Do Loading:: The `load' function and others. * Autoload:: Setting up a function to autoload. * Repeated Loading:: Precautions about loading a file twice. * Named Features:: Loading a library if it isn't already loaded. * Unloading:: How to "unload" a library that was loaded. * Hooks for Loading:: Providing code to be run when particular libraries are loaded.  File: lispref.info, Node: How Programs Do Loading, Next: Autoload, Up: Loading How Programs Do Loading ======================= XEmacs Lisp has several interfaces for loading. For example, `autoload' creates a placeholder object for a function in a file; trying to call the autoloading function loads the file to get the function's real definition (*note Autoload::.). `require' loads a file if it isn't already loaded (*note Named Features::.). Ultimately, all these facilities call the `load' function to do the work. - Function: load FILENAME &optional MISSING-OK NOMESSAGE NOSUFFIX This function finds and opens a file of Lisp code, evaluates all the forms in it, and closes the file. To find the file, `load' first looks for a file named `FILENAME.elc', that is, for a file whose name is FILENAME with `.elc' appended. If such a file exists, it is loaded. If there is no file by that name, then `load' looks for a file named `FILENAME.el'. If that file exists, it is loaded. Finally, if neither of those names is found, `load' looks for a file named FILENAME with nothing appended, and loads it if it exists. (The `load' function is not clever about looking at FILENAME. In the perverse case of a file named `foo.el.el', evaluation of `(load "foo.el")' will indeed find it.) If the optional argument NOSUFFIX is non-`nil', then the suffixes `.elc' and `.el' are not tried. In this case, you must specify the precise file name you want. If FILENAME is a relative file name, such as `foo' or `baz/foo.bar', `load' searches for the file using the variable `load-path'. It appends FILENAME to each of the directories listed in `load-path', and loads the first file it finds whose name matches. The current default directory is tried only if it is specified in `load-path', where `nil' stands for the default directory. `load' tries all three possible suffixes in the first directory in `load-path', then all three suffixes in the second directory, and so on. If you get a warning that `foo.elc' is older than `foo.el', it means you should consider recompiling `foo.el'. *Note Byte Compilation::. Messages like `Loading foo...' and `Loading foo...done' appear in the echo area during loading unless NOMESSAGE is non-`nil'. Any unhandled errors while loading a file terminate loading. If the load was done for the sake of `autoload', any function definitions made during the loading are undone. If `load' can't find the file to load, then normally it signals the error `file-error' (with `Cannot open load file FILENAME'). But if MISSING-OK is non-`nil', then `load' just returns `nil'. You can use the variable `load-read-function' to specify a function for `load' to use instead of `read' for reading expressions. See below. `load' returns `t' if the file loads successfully. - User Option: load-path The value of this variable is a list of directories to search when loading files with `load'. Each element is a string (which must be a directory name) or `nil' (which stands for the current working directory). The value of `load-path' is initialized from the environment variable `EMACSLOADPATH', if that exists; otherwise its default value is specified in `emacs/src/paths.h' when XEmacs is built. The syntax of `EMACSLOADPATH' is the same as used for `PATH'; `:' (or `;', according to the operating system) separates directory names, and `.' is used for the current default directory. Here is an example of how to set your `EMACSLOADPATH' variable from a `csh' `.login' file: setenv EMACSLOADPATH .:/user/bil/emacs:/usr/lib/emacs/lisp Here is how to set it using `sh': export EMACSLOADPATH EMACSLOADPATH=.:/user/bil/emacs:/usr/local/lib/emacs/lisp Here is an example of code you can place in a `.emacs' file to add several directories to the front of your default `load-path': (setq load-path (append (list nil "/user/bil/emacs" "/usr/local/lisplib" "~/emacs") load-path)) In this example, the path searches the current working directory first, followed then by the `/user/bil/emacs' directory, the `/usr/local/lisplib' directory, and the `~/emacs' directory, which are then followed by the standard directories for Lisp code. The command line options `-l' or `-load' specify a Lisp library to load as part of Emacs startup. Since this file might be in the current directory, Emacs 18 temporarily adds the current directory to the front of `load-path' so the file can be found there. Newer Emacs versions also find such files in the current directory, but without altering `load-path'. Dumping Emacs uses a special value of `load-path'. If the value of `load-path' at the end of dumping is unchanged (that is, still the same special value), the dumped Emacs switches to the ordinary `load-path' value when it starts up, as described above. But if `load-path' has any other value at the end of dumping, that value is used for execution of the dumped Emacs also. Therefore, if you want to change `load-path' temporarily for loading a few libraries in `site-init.el' or `site-load.el', you should bind `load-path' locally with `let' around the calls to `load'. - Function: locate-file FILENAME PATH-LIST &optional SUFFIXES MODE This function searches for a file in the same way that `load' does, and returns the file found (if any). (In fact, `load' uses this function to search through `load-path'.) It searches for FILENAME through PATH-LIST, expanded by one of the optional SUFFIXES (string of suffixes separated by `:'s), checking for access MODE (0|1|2|4 = exists|executable|writeable|readable), default readable. `locate-file' keeps hash tables of the directories it searches through, in order to speed things up. It tries valiantly to not get confused in the face of a changing and unpredictable environment, but can occasionally get tripped up. In this case, you will have to call `locate-file-clear-hashing' to get it back on track. See that function for details. - Function: locate-file-clear-hashing PATH This function clears the hash records for the specified list of directories. `locate-file' uses a hashing scheme to speed lookup, and will correctly track the following environmental changes: * changes of any sort to the list of directories to be searched. * addition and deletion of non-shadowing files (see below) from the directories in the list. * byte-compilation of a .el file into a .elc file. `locate-file' will primarily get confused if you add a file that shadows (i.e. has the same name as) another file further down in the directory list. In this case, you must call `locate-file-clear-hashing'. - Variable: load-in-progress This variable is non-`nil' if Emacs is in the process of loading a file, and it is `nil' otherwise. - Variable: load-read-function This variable specifies an alternate expression-reading function for `load' and `eval-region' to use instead of `read'. The function should accept one argument, just as `read' does. Normally, the variable's value is `nil', which means those functions should use `read'. - User Option: load-warn-when-source-newer This variable specifies whether `load' should check whether the source is newer than the binary. If this variable is true, then when a `.elc' file is being loaded and the corresponding `.el' is newer, a warning message will be printed. The default is `nil', but it is bound to `t' during the initial loadup. - User Option: load-warn-when-source-only This variable specifies whether `load' should warn when loading a `.el' file instead of an `.elc'. If this variable is true, then when `load' is called with a filename without an extension, and the `.elc' version doesn't exist but the `.el' version does, then a message will be printed. If an explicit extension is passed to `load', no warning will be printed. The default is `nil', but it is bound to `t' during the initial loadup. - User Option: load-ignore-elc-files This variable specifies whether `load' should ignore `.elc' files when a suffix is not given. This is normally used only to bootstrap the `.elc' files when building XEmacs, when you use the command `make all-elc'. (This forces the `.el' versions to be loaded in the process of compiling those same files, so that existing out-of-date `.elc' files do not make it mess things up.) To learn how `load' is used to build XEmacs, see *Note Building XEmacs::.  File: lispref.info, Node: Autoload, Next: Repeated Loading, Prev: How Programs Do Loading, Up: Loading Autoload ======== The "autoload" facility allows you to make a function or macro known in Lisp, but put off loading the file that defines it. The first call to the function automatically reads the proper file to install the real definition and other associated code, then runs the real definition as if it had been loaded all along. There are two ways to set up an autoloaded function: by calling `autoload', and by writing a special "magic" comment in the source before the real definition. `autoload' is the low-level primitive for autoloading; any Lisp program can call `autoload' at any time. Magic comments do nothing on their own; they serve as a guide for the command `update-file-autoloads', which constructs calls to `autoload' and arranges to execute them when Emacs is built. Magic comments are the most convenient way to make a function autoload, but only for packages installed along with Emacs. - Function: autoload FUNCTION FILENAME &optional DOCSTRING INTERACTIVE TYPE This function defines the function (or macro) named FUNCTION so as to load automatically from FILENAME. The string FILENAME specifies the file to load to get the real definition of FUNCTION. The argument DOCSTRING is the documentation string for the function. Normally, this is the identical to the documentation string in the function definition itself. Specifying the documentation string in the call to `autoload' makes it possible to look at the documentation without loading the function's real definition. If INTERACTIVE is non-`nil', then the function can be called interactively. This lets completion in `M-x' work without loading the function's real definition. The complete interactive specification need not be given here; it's not needed unless the user actually calls FUNCTION, and when that happens, it's time to load the real definition. You can autoload macros and keymaps as well as ordinary functions. Specify TYPE as `macro' if FUNCTION is really a macro. Specify TYPE as `keymap' if FUNCTION is really a keymap. Various parts of Emacs need to know this information without loading the real definition. An autoloaded keymap loads automatically during key lookup when a prefix key's binding is the symbol FUNCTION. Autoloading does not occur for other kinds of access to the keymap. In particular, it does not happen when a Lisp program gets the keymap from the value of a variable and calls `define-key'; not even if the variable name is the same symbol FUNCTION. If FUNCTION already has a non-void function definition that is not an autoload object, `autoload' does nothing and returns `nil'. If the function cell of FUNCTION is void, or is already an autoload object, then it is defined as an autoload object like this: (autoload FILENAME DOCSTRING INTERACTIVE TYPE) For example, (symbol-function 'run-prolog) => (autoload "prolog" 169681 t nil) In this case, `"prolog"' is the name of the file to load, 169681 refers to the documentation string in the `DOC' file (*note Documentation Basics::.), `t' means the function is interactive, and `nil' that it is not a macro or a keymap. The autoloaded file usually contains other definitions and may require or provide one or more features. If the file is not completely loaded (due to an error in the evaluation of its contents), any function definitions or `provide' calls that occurred during the load are undone. This is to ensure that the next attempt to call any function autoloading from this file will try again to load the file. If not for this, then some of the functions in the file might appear defined, but they might fail to work properly for the lack of certain subroutines defined later in the file and not loaded successfully. XEmacs as distributed comes with many autoloaded functions. The calls to `autoload' are in the file `loaddefs.el'. There is a convenient way of updating them automatically. If the autoloaded file fails to define the desired Lisp function or macro, then an error is signaled with data `"Autoloading failed to define function FUNCTION-NAME"'. A magic autoload comment looks like `;;;###autoload', on a line by itself, just before the real definition of the function in its autoloadable source file. The command `M-x update-file-autoloads' writes a corresponding `autoload' call into `loaddefs.el'. Building Emacs loads `loaddefs.el' and thus calls `autoload'. `M-x update-directory-autoloads' is even more powerful; it updates autoloads for all files in the current directory. The same magic comment can copy any kind of form into `loaddefs.el'. If the form following the magic comment is not a function definition, it is copied verbatim. You can also use a magic comment to execute a form at build time *without* executing it when the file itself is loaded. To do this, write the form "on the same line" as the magic comment. Since it is in a comment, it does nothing when you load the source file; but `update-file-autoloads' copies it to `loaddefs.el', where it is executed while building Emacs. The following example shows how `doctor' is prepared for autoloading with a magic comment: ;;;###autoload (defun doctor () "Switch to *doctor* buffer and start giving psychotherapy." (interactive) (switch-to-buffer "*doctor*") (doctor-mode)) Here's what that produces in `loaddefs.el': (autoload 'doctor "doctor" "\ Switch to *doctor* buffer and start giving psychotherapy." t) The backslash and newline immediately following the double-quote are a convention used only in the preloaded Lisp files such as `loaddefs.el'; they tell `make-docfile' to put the documentation string in the `DOC' file. *Note Building XEmacs::.  File: lispref.info, Node: Repeated Loading, Next: Named Features, Prev: Autoload, Up: Loading Repeated Loading ================ You may load one file more than once in an Emacs session. For example, after you have rewritten and reinstalled a function definition by editing it in a buffer, you may wish to return to the original version; you can do this by reloading the file it came from. When you load or reload files, bear in mind that the `load' and `load-library' functions automatically load a byte-compiled file rather than a non-compiled file of similar name. If you rewrite a file that you intend to save and reinstall, remember to byte-compile it if necessary; otherwise you may find yourself inadvertently reloading the older, byte-compiled file instead of your newer, non-compiled file! When writing the forms in a Lisp library file, keep in mind that the file might be loaded more than once. For example, the choice of `defvar' vs. `defconst' for defining a variable depends on whether it is desirable to reinitialize the variable if the library is reloaded: `defconst' does so, and `defvar' does not. (*Note Defining Variables::.) The simplest way to add an element to an alist is like this: (setq minor-mode-alist (cons '(leif-mode " Leif") minor-mode-alist)) But this would add multiple elements if the library is reloaded. To avoid the problem, write this: (or (assq 'leif-mode minor-mode-alist) (setq minor-mode-alist (cons '(leif-mode " Leif") minor-mode-alist))) To add an element to a list just once, use `add-to-list' (*note Setting Variables::.). Occasionally you will want to test explicitly whether a library has already been loaded. Here's one way to test, in a library, whether it has been loaded before: (defvar foo-was-loaded) (if (not (boundp 'foo-was-loaded)) EXECUTE-FIRST-TIME-ONLY) (setq foo-was-loaded t) If the library uses `provide' to provide a named feature, you can use `featurep' to test whether the library has been loaded. *Note Named Features::.  File: lispref.info, Node: Named Features, Next: Unloading, Prev: Repeated Loading, Up: Loading Features ======== `provide' and `require' are an alternative to `autoload' for loading files automatically. They work in terms of named "features". Autoloading is triggered by calling a specific function, but a feature is loaded the first time another program asks for it by name. A feature name is a symbol that stands for a collection of functions, variables, etc. The file that defines them should "provide" the feature. Another program that uses them may ensure they are defined by "requiring" the feature. This loads the file of definitions if it hasn't been loaded already. To require the presence of a feature, call `require' with the feature name as argument. `require' looks in the global variable `features' to see whether the desired feature has been provided already. If not, it loads the feature from the appropriate file. This file should call `provide' at the top level to add the feature to `features'; if it fails to do so, `require' signals an error. Features are normally named after the files that provide them, so that `require' need not be given the file name. For example, in `emacs/lisp/prolog.el', the definition for `run-prolog' includes the following code: (defun run-prolog () "Run an inferior Prolog process, input and output via buffer *prolog*." (interactive) (require 'comint) (switch-to-buffer (make-comint "prolog" prolog-program-name)) (inferior-prolog-mode)) The expression `(require 'comint)' loads the file `comint.el' if it has not yet been loaded. This ensures that `make-comint' is defined. The `comint.el' file contains the following top-level expression: (provide 'comint) This adds `comint' to the global `features' list, so that `(require 'comint)' will henceforth know that nothing needs to be done. When `require' is used at top level in a file, it takes effect when you byte-compile that file (*note Byte Compilation::.) as well as when you load it. This is in case the required package contains macros that the byte compiler must know about. Although top-level calls to `require' are evaluated during byte compilation, `provide' calls are not. Therefore, you can ensure that a file of definitions is loaded before it is byte-compiled by including a `provide' followed by a `require' for the same feature, as in the following example. (provide 'my-feature) ; Ignored by byte compiler, ; evaluated by `load'. (require 'my-feature) ; Evaluated by byte compiler. The compiler ignores the `provide', then processes the `require' by loading the file in question. Loading the file does execute the `provide' call, so the subsequent `require' call does nothing while loading. - Function: provide FEATURE This function announces that FEATURE is now loaded, or being loaded, into the current XEmacs session. This means that the facilities associated with FEATURE are or will be available for other Lisp programs. The direct effect of calling `provide' is to add FEATURE to the front of the list `features' if it is not already in the list. The argument FEATURE must be a symbol. `provide' returns FEATURE. features => (bar bish) (provide 'foo) => foo features => (foo bar bish) When a file is loaded to satisfy an autoload, and it stops due to an error in the evaluating its contents, any function definitions or `provide' calls that occurred during the load are undone. *Note Autoload::. - Function: require FEATURE &optional FILENAME This function checks whether FEATURE is present in the current XEmacs session (using `(featurep FEATURE)'; see below). If it is not, then `require' loads FILENAME with `load'. If FILENAME is not supplied, then the name of the symbol FEATURE is used as the file name to load. If loading the file fails to provide FEATURE, `require' signals an error, `Required feature FEATURE was not provided'. - Function: featurep FEATURE This function returns `t' if FEATURE has been provided in the current XEmacs session (i.e., FEATURE is a member of `features'.) - Variable: features The value of this variable is a list of symbols that are the features loaded in the current XEmacs session. Each symbol was put in this list with a call to `provide'. The order of the elements in the `features' list is not significant.  File: lispref.info, Node: Unloading, Next: Hooks for Loading, Prev: Named Features, Up: Loading Unloading ========= You can discard the functions and variables loaded by a library to reclaim memory for other Lisp objects. To do this, use the function `unload-feature': - Command: unload-feature FEATURE &optional FORCE This command unloads the library that provided feature FEATURE. It undefines all functions, macros, and variables defined in that library with `defconst', `defvar', `defun', `defmacro', `defsubst', `definf-function' and `defalias'. It then restores any autoloads formerly associated with those symbols. (Loading saves these in the `autoload' property of the symbol.) Ordinarily, `unload-feature' refuses to unload a library on which other loaded libraries depend. (A library A depends on library B if A contains a `require' for B.) If the optional argument FORCE is non-`nil', dependencies are ignored and you can unload any library. The `unload-feature' function is written in Lisp; its actions are based on the variable `load-history'. - Variable: load-history This variable's value is an alist connecting library names with the names of functions and variables they define, the features they provide, and the features they require. Each element is a list and describes one library. The CAR of the list is the name of the library, as a string. The rest of the list is composed of these kinds of objects: * Symbols that were defined by this library. * Lists of the form `(require . FEATURE)' indicating features that were required. * Lists of the form `(provide . FEATURE)' indicating features that were provided. The value of `load-history' may have one element whose CAR is `nil'. This element describes definitions made with `eval-buffer' on a buffer that is not visiting a file. The command `eval-region' updates `load-history', but does so by adding the symbols defined to the element for the file being visited, rather than replacing that element.  File: lispref.info, Node: Hooks for Loading, Prev: Unloading, Up: Loading Hooks for Loading ================= - Variable: after-load-alist An alist of expressions to evaluate if and when particular libraries are loaded. Each element looks like this: (FILENAME FORMS...) When `load' is run and the file-name argument is FILENAME, the FORMS in the corresponding element are executed at the end of loading. FILENAME must match exactly! Normally FILENAME is the name of a library, with no directory specified, since that is how `load' is normally called. An error in FORMS does not undo the load, but does prevent execution of the rest of the FORMS.  File: lispref.info, Node: Byte Compilation, Next: Debugging, Prev: Loading, Up: Top Byte Compilation **************** XEmacs Lisp has a "compiler" that translates functions written in Lisp into a special representation called "byte-code" that can be executed more efficiently. The compiler replaces Lisp function definitions with byte-code. When a byte-coded function is called, its definition is evaluated by the "byte-code interpreter". Because the byte-compiled code is evaluated by the byte-code interpreter, instead of being executed directly by the machine's hardware (as true compiled code is), byte-code is completely transportable from machine to machine without recompilation. It is not, however, as fast as true compiled code. In general, any version of Emacs can run byte-compiled code produced by recent earlier versions of Emacs, but the reverse is not true. In particular, if you compile a program with Emacs 19.29, the compiled code does not run in earlier versions. Files compiled in versions before 19.29 may not work in 19.29 if they contain character constants with modifier bits, because the bits were renumbered in Emacs 19.29. *Note Compilation Errors::, for how to investigate errors occurring in byte compilation. * Menu: * Speed of Byte-Code:: An example of speedup from byte compilation. * Compilation Functions:: Byte compilation functions. * Docs and Compilation:: Dynamic loading of documentation strings. * Dynamic Loading:: Dynamic loading of individual functions. * Eval During Compile:: Code to be evaluated when you compile. * Compiled-Function Objects:: The data type used for byte-compiled functions. * Disassembly:: Disassembling byte-code; how to read byte-code.  File: lispref.info, Node: Speed of Byte-Code, Next: Compilation Functions, Up: Byte Compilation Performance of Byte-Compiled Code ================================= A byte-compiled function is not as efficient as a primitive function written in C, but runs much faster than the version written in Lisp. Here is an example: (defun silly-loop (n) "Return time before and after N iterations of a loop." (let ((t1 (current-time-string))) (while (> (setq n (1- n)) 0)) (list t1 (current-time-string)))) => silly-loop (silly-loop 100000) => ("Fri Mar 18 17:25:57 1994" "Fri Mar 18 17:26:28 1994") ; 31 seconds (byte-compile 'silly-loop) => [Compiled code not shown] (silly-loop 100000) => ("Fri Mar 18 17:26:52 1994" "Fri Mar 18 17:26:58 1994") ; 6 seconds In this example, the interpreted code required 31 seconds to run, whereas the byte-compiled code required 6 seconds. These results are representative, but actual results will vary greatly.  File: lispref.info, Node: Compilation Functions, Next: Docs and Compilation, Prev: Speed of Byte-Code, Up: Byte Compilation The Compilation Functions ========================= You can byte-compile an individual function or macro definition with the `byte-compile' function. You can compile a whole file with `byte-compile-file', or several files with `byte-recompile-directory' or `batch-byte-compile'. When you run the byte compiler, you may get warnings in a buffer called `*Compile-Log*'. These report things in your program that suggest a problem but are not necessarily erroneous. Be careful when byte-compiling code that uses macros. Macro calls are expanded when they are compiled, so the macros must already be defined for proper compilation. For more details, see *Note Compiling Macros::. Normally, compiling a file does not evaluate the file's contents or load the file. But it does execute any `require' calls at top level in the file. One way to ensure that necessary macro definitions are available during compilation is to require the file that defines them (*note Named Features::.). To avoid loading the macro definition files when someone *runs* the compiled program, write `eval-when-compile' around the `require' calls (*note Eval During Compile::.). - Function: byte-compile SYMBOL This function byte-compiles the function definition of SYMBOL, replacing the previous definition with the compiled one. The function definition of SYMBOL must be the actual code for the function; i.e., the compiler does not follow indirection to another symbol. `byte-compile' returns the new, compiled definition of SYMBOL. If SYMBOL's definition is a compiled-function object, `byte-compile' does nothing and returns `nil'. Lisp records only one function definition for any symbol, and if that is already compiled, non-compiled code is not available anywhere. So there is no way to "compile the same definition again." (defun factorial (integer) "Compute factorial of INTEGER." (if (= 1 integer) 1 (* integer (factorial (1- integer))))) => factorial (byte-compile 'factorial) => # The result is a compiled-function object. The string it contains is the actual byte-code; each character in it is an instruction or an operand of an instruction. The vector contains all the constants, variable names and function names used by the function, except for certain primitives that are coded as special instructions. - Command: compile-defun &optional ARG This command reads the defun containing point, compiles it, and evaluates the result. If you use this on a defun that is actually a function definition, the effect is to install a compiled version of that function. If ARG is non-`nil', the result is inserted in the current buffer after the form; otherwise, it is printed in the minibuffer. - Command: byte-compile-file FILENAME &optional LOAD This function compiles a file of Lisp code named FILENAME into a file of byte-code. The output file's name is made by appending `c' to the end of FILENAME. If `load' is non-`nil', the file is loaded after having been compiled. Compilation works by reading the input file one form at a time. If it is a definition of a function or macro, the compiled function or macro definition is written out. Other forms are batched together, then each batch is compiled, and written so that its compiled code will be executed when the file is read. All comments are discarded when the input file is read. This command returns `t'. When called interactively, it prompts for the file name. % ls -l push* -rw-r--r-- 1 lewis 791 Oct 5 20:31 push.el (byte-compile-file "~/emacs/push.el") => t % ls -l push* -rw-r--r-- 1 lewis 791 Oct 5 20:31 push.el -rw-rw-rw- 1 lewis 638 Oct 8 20:25 push.elc - Command: byte-recompile-directory DIRECTORY &optional FLAG This function recompiles every `.el' file in DIRECTORY that needs recompilation. A file needs recompilation if a `.elc' file exists but is older than the `.el' file. When a `.el' file has no corresponding `.elc' file, then FLAG says what to do. If it is `nil', these files are ignored. If it is non-`nil', the user is asked whether to compile each such file. The returned value of this command is unpredictable. - Function: batch-byte-compile This function runs `byte-compile-file' on files specified on the command line. This function must be used only in a batch execution of Emacs, as it kills Emacs on completion. An error in one file does not prevent processing of subsequent files. (The file that gets the error will not, of course, produce any compiled code.) % emacs -batch -f batch-byte-compile *.el - Function: batch-byte-recompile-directory This function is similar to `batch-byte-compile' but runs the command `byte-recompile-directory' on the files remaining on the command line. - Variable: byte-recompile-directory-ignore-errors-p If non-`nil', this specifies that `byte-recompile-directory' will continue compiling even when an error occurs in a file. This is normally `nil', but is bound to `t' by `batch-byte-recompile-directory'. - Function: byte-code CODE-STRING DATA-VECTOR MAX-STACK This function actually interprets byte-code. A byte-compiled function is actually defined with a body that calls `byte-code'. Don't call this function yourself. Only the byte compiler knows how to generate valid calls to this function. In newer Emacs versions (19 and up), byte-code is usually executed as part of a compiled-function object, and only rarely due to an explicit call to `byte-code'.  File: lispref.info, Node: Docs and Compilation, Next: Dynamic Loading, Prev: Compilation Functions, Up: Byte Compilation Documentation Strings and Compilation ===================================== Functions and variables loaded from a byte-compiled file access their documentation strings dynamically from the file whenever needed. This saves space within Emacs, and makes loading faster because the documentation strings themselves need not be processed while loading the file. Actual access to the documentation strings becomes slower as a result, but normally not enough to bother users. Dynamic access to documentation strings does have drawbacks: * If you delete or move the compiled file after loading it, Emacs can no longer access the documentation strings for the functions and variables in the file. * If you alter the compiled file (such as by compiling a new version), then further access to documentation strings in this file will give nonsense results. If your site installs Emacs following the usual procedures, these problems will never normally occur. Installing a new version uses a new directory with a different name; as long as the old version remains installed, its files will remain unmodified in the places where they are expected to be. However, if you have built Emacs yourself and use it from the directory where you built it, you will experience this problem occasionally if you edit and recompile Lisp files. When it happens, you can cure the problem by reloading the file after recompiling it. Byte-compiled files made with Emacs 19.29 will not load into older versions because the older versions don't support this feature. You can turn off this feature by setting `byte-compile-dynamic-docstrings' to `nil'. Once this is done, you can compile files that will load into older Emacs versions. You can do this globally, or for one source file by specifying a file-local binding for the variable. Here's one way to do that: -*-byte-compile-dynamic-docstrings: nil;-*- - Variable: byte-compile-dynamic-docstrings If this is non-`nil', the byte compiler generates compiled files that are set up for dynamic loading of documentation strings. The dynamic documentation string feature writes compiled files that use a special Lisp reader construct, `#@COUNT'. This construct skips the next COUNT characters. It also uses the `#$' construct, which stands for "the name of this file, as a string." It is best not to use these constructs in Lisp source files.