| 1 | @c -*-texinfo-*- |
| 2 | @c This is part of the GNU Emacs Lisp Reference Manual. |
| 3 | @c Copyright (C) 1990, 1991, 1992, 1993, 1994 Free Software Foundation, Inc. |
| 4 | @c See the file elisp.texi for copying conditions. |
| 5 | @setfilename ../info/loading |
| 6 | @node Loading, Byte Compilation, Macros, Top |
| 7 | @chapter Loading |
| 8 | @cindex loading |
| 9 | @cindex library |
| 10 | @cindex Lisp library |
| 11 | |
| 12 | Loading a file of Lisp code means bringing its contents into the Lisp |
| 13 | environment in the form of Lisp objects. Emacs finds and opens the |
| 14 | file, reads the text, evaluates each form, and then closes the file. |
| 15 | |
| 16 | The load functions evaluate all the expressions in a file just |
| 17 | as the @code{eval-current-buffer} function evaluates all the |
| 18 | expressions in a buffer. The difference is that the load functions |
| 19 | read and evaluate the text in the file as found on disk, not the text |
| 20 | in an Emacs buffer. |
| 21 | |
| 22 | @cindex top-level form |
| 23 | The loaded file must contain Lisp expressions, either as source code |
| 24 | or as byte-compiled code. Each form in the file is called a |
| 25 | @dfn{top-level form}. There is no special format for the forms in a |
| 26 | loadable file; any form in a file may equally well be typed directly |
| 27 | into a buffer and evaluated there. (Indeed, most code is tested this |
| 28 | way.) Most often, the forms are function definitions and variable |
| 29 | definitions. |
| 30 | |
| 31 | A file containing Lisp code is often called a @dfn{library}. Thus, |
| 32 | the ``Rmail library'' is a file containing code for Rmail mode. |
| 33 | Similarly, a ``Lisp library directory'' is a directory of files |
| 34 | containing Lisp code. |
| 35 | |
| 36 | @menu |
| 37 | * How Programs Do Loading:: The @code{load} function and others. |
| 38 | * Autoload:: Setting up a function to autoload. |
| 39 | * Repeated Loading:: Precautions about loading a file twice. |
| 40 | * Named Features:: Loading a library if it isn't already loaded. |
| 41 | * Unloading:: How to ``unload'' a library that was loaded. |
| 42 | * Hooks for Loading:: Providing code to be run when |
| 43 | particular libraries are loaded. |
| 44 | @end menu |
| 45 | |
| 46 | @node How Programs Do Loading |
| 47 | @section How Programs Do Loading |
| 48 | |
| 49 | Emacs Lisp has several interfaces for loading. For example, |
| 50 | @code{autoload} creates a placeholder object for a function in a file; |
| 51 | trying to call the autoloading function loads the file to get the |
| 52 | function's real definition (@pxref{Autoload}). @code{require} loads a |
| 53 | file if it isn't already loaded (@pxref{Named Features}). Ultimately, all |
| 54 | these facilities call the @code{load} function to do the work. |
| 55 | |
| 56 | @defun load filename &optional missing-ok nomessage nosuffix |
| 57 | This function finds and opens a file of Lisp code, evaluates all the |
| 58 | forms in it, and closes the file. |
| 59 | |
| 60 | To find the file, @code{load} first looks for a file named |
| 61 | @file{@var{filename}.elc}, that is, for a file whose name is |
| 62 | @var{filename} with @samp{.elc} appended. If such a file exists, it is |
| 63 | loaded. If there is no file by that name, then @code{load} looks for a |
| 64 | file named @file{@var{filename}.el}. If that file exists, it is loaded. |
| 65 | Finally, if neither of those names is found, @code{load} looks for a |
| 66 | file named @var{filename} with nothing appended, and loads it if it |
| 67 | exists. (The @code{load} function is not clever about looking at |
| 68 | @var{filename}. In the perverse case of a file named @file{foo.el.el}, |
| 69 | evaluation of @code{(load "foo.el")} will indeed find it.) |
| 70 | |
| 71 | If the optional argument @var{nosuffix} is non-@code{nil}, then the |
| 72 | suffixes @samp{.elc} and @samp{.el} are not tried. In this case, you |
| 73 | must specify the precise file name you want. |
| 74 | |
| 75 | If @var{filename} is a relative file name, such as @file{foo} or |
| 76 | @file{baz/foo.bar}, @code{load} searches for the file using the variable |
| 77 | @code{load-path}. It appends @var{filename} to each of the directories |
| 78 | listed in @code{load-path}, and loads the first file it finds whose name |
| 79 | matches. The current default directory is tried only if it is specified |
| 80 | in @code{load-path}, where @code{nil} stands for the default directory. |
| 81 | @code{load} tries all three possible suffixes in the first directory in |
| 82 | @code{load-path}, then all three suffixes in the second directory, and |
| 83 | so on. |
| 84 | |
| 85 | If you get a warning that @file{foo.elc} is older than @file{foo.el}, it |
| 86 | means you should consider recompiling @file{foo.el}. @xref{Byte |
| 87 | Compilation}. |
| 88 | |
| 89 | Messages like @samp{Loading foo...} and @samp{Loading foo...done} appear |
| 90 | in the echo area during loading unless @var{nomessage} is |
| 91 | non-@code{nil}. |
| 92 | |
| 93 | @cindex load errors |
| 94 | Any unhandled errors while loading a file terminate loading. If the |
| 95 | load was done for the sake of @code{autoload}, any function definitions |
| 96 | made during the loading are undone. |
| 97 | |
| 98 | @kindex file-error |
| 99 | If @code{load} can't find the file to load, then normally it signals the |
| 100 | error @code{file-error} (with @samp{Cannot open load file |
| 101 | @var{filename}}). But if @var{missing-ok} is non-@code{nil}, then |
| 102 | @code{load} just returns @code{nil}. |
| 103 | |
| 104 | You can use the variable @code{load-read-function} to specify a function |
| 105 | for @code{load} to use instead of @code{read} for reading expressions. |
| 106 | See below. |
| 107 | |
| 108 | @code{load} returns @code{t} if the file loads successfully. |
| 109 | @end defun |
| 110 | |
| 111 | @ignore |
| 112 | @deffn Command load-file filename |
| 113 | This function loads the file @var{filename}. If @var{filename} is an |
| 114 | absolute file name, then it is loaded. If it is relative, then the |
| 115 | current default directory is assumed. @code{load-path} is not used, and |
| 116 | suffixes are not appended. Use this function if you wish to specify |
| 117 | the file to be loaded exactly. |
| 118 | @end deffn |
| 119 | |
| 120 | @deffn Command load-library library |
| 121 | This function loads the library named @var{library}. A library is |
| 122 | nothing more than a file that may be loaded as described earlier. This |
| 123 | function is identical to @code{load}, save that it reads a file name |
| 124 | interactively with completion. |
| 125 | @end deffn |
| 126 | @end ignore |
| 127 | |
| 128 | @defopt load-path |
| 129 | @cindex @code{EMACSLOADPATH} environment variable |
| 130 | The value of this variable is a list of directories to search when |
| 131 | loading files with @code{load}. Each element is a string (which must be |
| 132 | a directory name) or @code{nil} (which stands for the current working |
| 133 | directory). The value of @code{load-path} is initialized from the |
| 134 | environment variable @code{EMACSLOADPATH}, if that exists; otherwise its |
| 135 | default value is specified in @file{emacs/src/paths.h} when Emacs is |
| 136 | built. |
| 137 | |
| 138 | The syntax of @code{EMACSLOADPATH} is the same as used for @code{PATH}; |
| 139 | @samp{:} (or @samp{;}, according to the operating system) separates |
| 140 | directory names, and @samp{.} is used for the current default directory. |
| 141 | Here is an example of how to set your @code{EMACSLOADPATH} variable from |
| 142 | a @code{csh} @file{.login} file: |
| 143 | |
| 144 | @c This overfull hbox is OK. --rjc 16mar92 |
| 145 | @smallexample |
| 146 | setenv EMACSLOADPATH .:/user/bil/emacs:/usr/lib/emacs/lisp |
| 147 | @end smallexample |
| 148 | |
| 149 | Here is how to set it using @code{sh}: |
| 150 | |
| 151 | @smallexample |
| 152 | export EMACSLOADPATH |
| 153 | EMACSLOADPATH=.:/user/bil/emacs:/usr/local/lib/emacs/lisp |
| 154 | @end smallexample |
| 155 | |
| 156 | Here is an example of code you can place in a @file{.emacs} file to add |
| 157 | several directories to the front of your default @code{load-path}: |
| 158 | |
| 159 | @smallexample |
| 160 | @group |
| 161 | (setq load-path |
| 162 | (append (list nil "/user/bil/emacs" |
| 163 | "/usr/local/lisplib" |
| 164 | "~/emacs") |
| 165 | load-path)) |
| 166 | @end group |
| 167 | @end smallexample |
| 168 | |
| 169 | @c Wordy to rid us of an overfull hbox. --rjc 15mar92 |
| 170 | @noindent |
| 171 | In this example, the path searches the current working directory first, |
| 172 | followed then by the @file{/user/bil/emacs} directory, the |
| 173 | @file{/usr/local/lisplib} directory, and the @file{~/emacs} directory, |
| 174 | which are then followed by the standard directories for Lisp code. |
| 175 | |
| 176 | The command line options @samp{-l} or @samp{-load} specify a Lisp |
| 177 | library to load as part of Emacs startup. Since this file might be in |
| 178 | the current directory, Emacs 18 temporarily adds the current directory |
| 179 | to the front of @code{load-path} so the file can be found there. Newer |
| 180 | Emacs versions also find such files in the current directory, but |
| 181 | without altering @code{load-path}. |
| 182 | |
| 183 | Dumping Emacs uses a special value of @code{load-path}. If the value of |
| 184 | @code{load-path} at the end of dumping is unchanged (that is, still the |
| 185 | same special value), the dumped Emacs switches to the ordinary |
| 186 | @code{load-path} value when it starts up, as described above. But if |
| 187 | @code{load-path} has any other value at the end of dumping, that value |
| 188 | is used for execution of the dumped Emacs also. |
| 189 | |
| 190 | Therefore, if you want to change @code{load-path} temporarily for |
| 191 | loading a few libraries in @file{site-init.el} or @file{site-load.el}, |
| 192 | you should bind @code{load-path} locally with @code{let} around the |
| 193 | calls to @code{load}. |
| 194 | @end defopt |
| 195 | |
| 196 | @defvar load-in-progress |
| 197 | This variable is non-@code{nil} if Emacs is in the process of loading a |
| 198 | file, and it is @code{nil} otherwise. |
| 199 | @end defvar |
| 200 | |
| 201 | @defvar load-read-function |
| 202 | This variable specifies an alternate expression-reading function for |
| 203 | @code{load} and @code{eval-region} to use instead of @code{read}. |
| 204 | The function should accept one argument, just as @code{read} does. |
| 205 | |
| 206 | Normally, the variable's value is @code{nil}, which means those |
| 207 | functions should use @code{read}. |
| 208 | @end defvar |
| 209 | |
| 210 | To learn how @code{load} is used to build Emacs, see @ref{Building Emacs}. |
| 211 | |
| 212 | @node Autoload |
| 213 | @section Autoload |
| 214 | @cindex autoload |
| 215 | |
| 216 | The @dfn{autoload} facility allows you to make a function or macro |
| 217 | known in Lisp, but put off loading the file that defines it. The first |
| 218 | call to the function automatically reads the proper file to install the |
| 219 | real definition and other associated code, then runs the real definition |
| 220 | as if it had been loaded all along. |
| 221 | |
| 222 | There are two ways to set up an autoloaded function: by calling |
| 223 | @code{autoload}, and by writing a special ``magic'' comment in the |
| 224 | source before the real definition. @code{autoload} is the low-level |
| 225 | primitive for autoloading; any Lisp program can call @code{autoload} at |
| 226 | any time. Magic comments do nothing on their own; they serve as a guide |
| 227 | for the command @code{update-file-autoloads}, which constructs calls to |
| 228 | @code{autoload} and arranges to execute them when Emacs is built. Magic |
| 229 | comments are the most convenient way to make a function autoload, but |
| 230 | only for packages installed along with Emacs. |
| 231 | |
| 232 | @defun autoload function filename &optional docstring interactive type |
| 233 | This function defines the function (or macro) named @var{function} so as |
| 234 | to load automatically from @var{filename}. The string @var{filename} |
| 235 | specifies the file to load to get the real definition of @var{function}. |
| 236 | |
| 237 | The argument @var{docstring} is the documentation string for the |
| 238 | function. Normally, this is the identical to the documentation string |
| 239 | in the function definition itself. Specifying the documentation string |
| 240 | in the call to @code{autoload} makes it possible to look at the |
| 241 | documentation without loading the function's real definition. |
| 242 | |
| 243 | If @var{interactive} is non-@code{nil}, then the function can be called |
| 244 | interactively. This lets completion in @kbd{M-x} work without loading |
| 245 | the function's real definition. The complete interactive specification |
| 246 | need not be given here; it's not needed unless the user actually calls |
| 247 | @var{function}, and when that happens, it's time to load the real |
| 248 | definition. |
| 249 | |
| 250 | You can autoload macros and keymaps as well as ordinary functions. |
| 251 | Specify @var{type} as @code{macro} if @var{function} is really a macro. |
| 252 | Specify @var{type} as @code{keymap} if @var{function} is really a |
| 253 | keymap. Various parts of Emacs need to know this information without |
| 254 | loading the real definition. |
| 255 | |
| 256 | An autoloaded keymap loads automatically during key lookup when a prefix |
| 257 | key's binding is the symbol @var{function}. Autoloading does not occur |
| 258 | for other kinds of access to the keymap. In particular, it does not |
| 259 | happen when a Lisp program gets the keymap from the value of a variable |
| 260 | and calls @code{define-key}; not even if the variable name is the same |
| 261 | symbol @var{function}. |
| 262 | |
| 263 | @cindex function cell in autoload |
| 264 | If @var{function} already has a non-void function definition that is not |
| 265 | an autoload object, @code{autoload} does nothing and returns @code{nil}. |
| 266 | If the function cell of @var{function} is void, or is already an autoload |
| 267 | object, then it is defined as an autoload object like this: |
| 268 | |
| 269 | @example |
| 270 | (autoload @var{filename} @var{docstring} @var{interactive} @var{type}) |
| 271 | @end example |
| 272 | |
| 273 | For example, |
| 274 | |
| 275 | @example |
| 276 | @group |
| 277 | (symbol-function 'run-prolog) |
| 278 | @result{} (autoload "prolog" 169681 t nil) |
| 279 | @end group |
| 280 | @end example |
| 281 | |
| 282 | @noindent |
| 283 | In this case, @code{"prolog"} is the name of the file to load, 169681 |
| 284 | refers to the documentation string in the @file{emacs/etc/DOC} file |
| 285 | (@pxref{Documentation Basics}), @code{t} means the function is |
| 286 | interactive, and @code{nil} that it is not a macro or a keymap. |
| 287 | @end defun |
| 288 | |
| 289 | @cindex autoload errors |
| 290 | The autoloaded file usually contains other definitions and may require |
| 291 | or provide one or more features. If the file is not completely loaded |
| 292 | (due to an error in the evaluation of its contents), any function |
| 293 | definitions or @code{provide} calls that occurred during the load are |
| 294 | undone. This is to ensure that the next attempt to call any function |
| 295 | autoloading from this file will try again to load the file. If not for |
| 296 | this, then some of the functions in the file might appear defined, but |
| 297 | they might fail to work properly for the lack of certain subroutines |
| 298 | defined later in the file and not loaded successfully. |
| 299 | |
| 300 | If the autoloaded file fails to define the desired Lisp function or |
| 301 | macro, then an error is signaled with data @code{"Autoloading failed to |
| 302 | define function @var{function-name}"}. |
| 303 | |
| 304 | @findex update-file-autoloads |
| 305 | @findex update-directory-autoloads |
| 306 | A magic autoload comment looks like @samp{;;;###autoload}, on a line |
| 307 | by itself, just before the real definition of the function in its |
| 308 | autoloadable source file. The command @kbd{M-x update-file-autoloads} |
| 309 | writes a corresponding @code{autoload} call into @file{loaddefs.el}. |
| 310 | Building Emacs loads @file{loaddefs.el} and thus calls @code{autoload}. |
| 311 | @kbd{M-x update-directory-autoloads} is even more powerful; it updates |
| 312 | autoloads for all files in the current directory. |
| 313 | |
| 314 | The same magic comment can copy any kind of form into |
| 315 | @file{loaddefs.el}. If the form following the magic comment is not a |
| 316 | function definition, it is copied verbatim. You can also use a magic |
| 317 | comment to execute a form at build time @emph{without} executing it when |
| 318 | the file itself is loaded. To do this, write the form @emph{on the same |
| 319 | line} as the magic comment. Since it is in a comment, it does nothing |
| 320 | when you load the source file; but @code{update-file-autoloads} copies |
| 321 | it to @file{loaddefs.el}, where it is executed while building Emacs. |
| 322 | |
| 323 | The following example shows how @code{doctor} is prepared for |
| 324 | autoloading with a magic comment: |
| 325 | |
| 326 | @smallexample |
| 327 | ;;;###autoload |
| 328 | (defun doctor () |
| 329 | "Switch to *doctor* buffer and start giving psychotherapy." |
| 330 | (interactive) |
| 331 | (switch-to-buffer "*doctor*") |
| 332 | (doctor-mode)) |
| 333 | @end smallexample |
| 334 | |
| 335 | @noindent |
| 336 | Here's what that produces in @file{loaddefs.el}: |
| 337 | |
| 338 | @smallexample |
| 339 | (autoload 'doctor "doctor" |
| 340 | "\ |
| 341 | Switch to *doctor* buffer and start giving psychotherapy." |
| 342 | t) |
| 343 | @end smallexample |
| 344 | |
| 345 | @noindent |
| 346 | The backslash and newline immediately following the double-quote are a |
| 347 | convention used only in the preloaded Lisp files such as |
| 348 | @file{loaddefs.el}; they tell @code{make-docfile} to put the |
| 349 | documentation string in the @file{etc/DOC} file. @xref{Building Emacs}. |
| 350 | |
| 351 | @node Repeated Loading |
| 352 | @section Repeated Loading |
| 353 | @cindex repeated loading |
| 354 | |
| 355 | You may load one file more than once in an Emacs session. For |
| 356 | example, after you have rewritten and reinstalled a function definition |
| 357 | by editing it in a buffer, you may wish to return to the original |
| 358 | version; you can do this by reloading the file it came from. |
| 359 | |
| 360 | When you load or reload files, bear in mind that the @code{load} and |
| 361 | @code{load-library} functions automatically load a byte-compiled file |
| 362 | rather than a non-compiled file of similar name. If you rewrite a file |
| 363 | that you intend to save and reinstall, remember to byte-compile it if |
| 364 | necessary; otherwise you may find yourself inadvertently reloading the |
| 365 | older, byte-compiled file instead of your newer, non-compiled file! |
| 366 | |
| 367 | When writing the forms in a Lisp library file, keep in mind that the |
| 368 | file might be loaded more than once. For example, the choice of |
| 369 | @code{defvar} vs.@: @code{defconst} for defining a variable depends on |
| 370 | whether it is desirable to reinitialize the variable if the library is |
| 371 | reloaded: @code{defconst} does so, and @code{defvar} does not. |
| 372 | (@xref{Defining Variables}.) |
| 373 | |
| 374 | The simplest way to add an element to an alist is like this: |
| 375 | |
| 376 | @example |
| 377 | (setq minor-mode-alist |
| 378 | (cons '(leif-mode " Leif") minor-mode-alist)) |
| 379 | @end example |
| 380 | |
| 381 | @noindent |
| 382 | But this would add multiple elements if the library is reloaded. |
| 383 | To avoid the problem, write this: |
| 384 | |
| 385 | @example |
| 386 | (or (assq 'leif-mode minor-mode-alist) |
| 387 | (setq minor-mode-alist |
| 388 | (cons '(leif-mode " Leif") minor-mode-alist))) |
| 389 | @end example |
| 390 | |
| 391 | To add an element to a list just once, use @code{add-to-list} |
| 392 | (@pxref{Setting Variables}). |
| 393 | |
| 394 | Occasionally you will want to test explicitly whether a library has |
| 395 | already been loaded. Here's one way to test, in a library, whether it |
| 396 | has been loaded before: |
| 397 | |
| 398 | @example |
| 399 | (defvar foo-was-loaded) |
| 400 | |
| 401 | (if (not (boundp 'foo-was-loaded)) |
| 402 | @var{execute-first-time-only}) |
| 403 | |
| 404 | (setq foo-was-loaded t) |
| 405 | @end example |
| 406 | |
| 407 | @noindent |
| 408 | If the library uses @code{provide} to provide a named feature, you can |
| 409 | use @code{featurep} to test whether the library has been loaded. |
| 410 | @ifinfo |
| 411 | @xref{Named Features}. |
| 412 | @end ifinfo |
| 413 | |
| 414 | @node Named Features |
| 415 | @section Features |
| 416 | @cindex features |
| 417 | @cindex requiring features |
| 418 | @cindex providing features |
| 419 | |
| 420 | @code{provide} and @code{require} are an alternative to |
| 421 | @code{autoload} for loading files automatically. They work in terms of |
| 422 | named @dfn{features}. Autoloading is triggered by calling a specific |
| 423 | function, but a feature is loaded the first time another program asks |
| 424 | for it by name. |
| 425 | |
| 426 | A feature name is a symbol that stands for a collection of functions, |
| 427 | variables, etc. The file that defines them should @dfn{provide} the |
| 428 | feature. Another program that uses them may ensure they are defined by |
| 429 | @dfn{requiring} the feature. This loads the file of definitions if it |
| 430 | hasn't been loaded already. |
| 431 | |
| 432 | To require the presence of a feature, call @code{require} with the |
| 433 | feature name as argument. @code{require} looks in the global variable |
| 434 | @code{features} to see whether the desired feature has been provided |
| 435 | already. If not, it loads the feature from the appropriate file. This |
| 436 | file should call @code{provide} at the top level to add the feature to |
| 437 | @code{features}; if it fails to do so, @code{require} signals an error. |
| 438 | @cindex load error with require |
| 439 | |
| 440 | Features are normally named after the files that provide them, so that |
| 441 | @code{require} need not be given the file name. |
| 442 | |
| 443 | For example, in @file{emacs/lisp/prolog.el}, |
| 444 | the definition for @code{run-prolog} includes the following code: |
| 445 | |
| 446 | @smallexample |
| 447 | (defun run-prolog () |
| 448 | "Run an inferior Prolog process, input and output via buffer *prolog*." |
| 449 | (interactive) |
| 450 | (require 'comint) |
| 451 | (switch-to-buffer (make-comint "prolog" prolog-program-name)) |
| 452 | (inferior-prolog-mode)) |
| 453 | @end smallexample |
| 454 | |
| 455 | @noindent |
| 456 | The expression @code{(require 'comint)} loads the file @file{comint.el} |
| 457 | if it has not yet been loaded. This ensures that @code{make-comint} is |
| 458 | defined. |
| 459 | |
| 460 | The @file{comint.el} file contains the following top-level expression: |
| 461 | |
| 462 | @smallexample |
| 463 | (provide 'comint) |
| 464 | @end smallexample |
| 465 | |
| 466 | @noindent |
| 467 | This adds @code{comint} to the global @code{features} list, so that |
| 468 | @code{(require 'comint)} will henceforth know that nothing needs to be |
| 469 | done. |
| 470 | |
| 471 | @cindex byte-compiling @code{require} |
| 472 | When @code{require} is used at top level in a file, it takes effect |
| 473 | when you byte-compile that file (@pxref{Byte Compilation}) as well as |
| 474 | when you load it. This is in case the required package contains macros |
| 475 | that the byte compiler must know about. |
| 476 | |
| 477 | Although top-level calls to @code{require} are evaluated during |
| 478 | byte compilation, @code{provide} calls are not. Therefore, you can |
| 479 | ensure that a file of definitions is loaded before it is byte-compiled |
| 480 | by including a @code{provide} followed by a @code{require} for the same |
| 481 | feature, as in the following example. |
| 482 | |
| 483 | @smallexample |
| 484 | @group |
| 485 | (provide 'my-feature) ; @r{Ignored by byte compiler,} |
| 486 | ; @r{evaluated by @code{load}.} |
| 487 | (require 'my-feature) ; @r{Evaluated by byte compiler.} |
| 488 | @end group |
| 489 | @end smallexample |
| 490 | |
| 491 | @noindent |
| 492 | The compiler ignores the @code{provide}, then processes the |
| 493 | @code{require} by loading the file in question. Loading the file does |
| 494 | execute the @code{provide} call, so the subsequent @code{require} call |
| 495 | does nothing while loading. |
| 496 | |
| 497 | @defun provide feature |
| 498 | This function announces that @var{feature} is now loaded, or being |
| 499 | loaded, into the current Emacs session. This means that the facilities |
| 500 | associated with @var{feature} are or will be available for other Lisp |
| 501 | programs. |
| 502 | |
| 503 | The direct effect of calling @code{provide} is to add @var{feature} to |
| 504 | the front of the list @code{features} if it is not already in the list. |
| 505 | The argument @var{feature} must be a symbol. @code{provide} returns |
| 506 | @var{feature}. |
| 507 | |
| 508 | @smallexample |
| 509 | features |
| 510 | @result{} (bar bish) |
| 511 | |
| 512 | (provide 'foo) |
| 513 | @result{} foo |
| 514 | features |
| 515 | @result{} (foo bar bish) |
| 516 | @end smallexample |
| 517 | |
| 518 | When a file is loaded to satisfy an autoload, and it stops due to an |
| 519 | error in the evaluating its contents, any function definitions or |
| 520 | @code{provide} calls that occurred during the load are undone. |
| 521 | @xref{Autoload}. |
| 522 | @end defun |
| 523 | |
| 524 | @defun require feature &optional filename |
| 525 | This function checks whether @var{feature} is present in the current |
| 526 | Emacs session (using @code{(featurep @var{feature})}; see below). If it |
| 527 | is not, then @code{require} loads @var{filename} with @code{load}. If |
| 528 | @var{filename} is not supplied, then the name of the symbol |
| 529 | @var{feature} is used as the file name to load. |
| 530 | |
| 531 | If loading the file fails to provide @var{feature}, @code{require} |
| 532 | signals an error, @samp{Required feature @var{feature} was not |
| 533 | provided}. |
| 534 | @end defun |
| 535 | |
| 536 | @defun featurep feature |
| 537 | This function returns @code{t} if @var{feature} has been provided in the |
| 538 | current Emacs session (i.e., @var{feature} is a member of |
| 539 | @code{features}.) |
| 540 | @end defun |
| 541 | |
| 542 | @defvar features |
| 543 | The value of this variable is a list of symbols that are the features |
| 544 | loaded in the current Emacs session. Each symbol was put in this list |
| 545 | with a call to @code{provide}. The order of the elements in the |
| 546 | @code{features} list is not significant. |
| 547 | @end defvar |
| 548 | |
| 549 | @node Unloading |
| 550 | @section Unloading |
| 551 | @cindex unloading |
| 552 | |
| 553 | @c Emacs 19 feature |
| 554 | You can discard the functions and variables loaded by a library to |
| 555 | reclaim memory for other Lisp objects. To do this, use the function |
| 556 | @code{unload-feature}: |
| 557 | |
| 558 | @deffn Command unload-feature feature &optional force |
| 559 | This command unloads the library that provided feature @var{feature}. |
| 560 | It undefines all functions, macros, and variables defined in that |
| 561 | library with @code{defconst}, @code{defvar}, @code{defun}, |
| 562 | @code{defmacro}, @code{defsubst} and @code{defalias}. It then restores |
| 563 | any autoloads formerly associated with those symbols. (Loading |
| 564 | saves these in the @code{autoload} property of the symbol.) |
| 565 | |
| 566 | Ordinarily, @code{unload-feature} refuses to unload a library on which |
| 567 | other loaded libraries depend. (A library @var{a} depends on library |
| 568 | @var{b} if @var{a} contains a @code{require} for @var{b}.) If the |
| 569 | optional argument @var{force} is non-@code{nil}, dependencies are |
| 570 | ignored and you can unload any library. |
| 571 | @end deffn |
| 572 | |
| 573 | The @code{unload-feature} function is written in Lisp; its actions are |
| 574 | based on the variable @code{load-history}. |
| 575 | |
| 576 | @defvar load-history |
| 577 | This variable's value is an alist connecting library names with the |
| 578 | names of functions and variables they define, the features they provide, |
| 579 | and the features they require. |
| 580 | |
| 581 | Each element is a list and describes one library. The @sc{car} of the |
| 582 | list is the name of the library, as a string. The rest of the list is |
| 583 | composed of these kinds of objects: |
| 584 | |
| 585 | @itemize @bullet |
| 586 | @item |
| 587 | Symbols that were defined by this library. |
| 588 | @item |
| 589 | Lists of the form @code{(require . @var{feature})} indicating |
| 590 | features that were required. |
| 591 | @item |
| 592 | Lists of the form @code{(provide . @var{feature})} indicating |
| 593 | features that were provided. |
| 594 | @end itemize |
| 595 | |
| 596 | The value of @code{load-history} may have one element whose @sc{car} is |
| 597 | @code{nil}. This element describes definitions made with |
| 598 | @code{eval-buffer} on a buffer that is not visiting a file. |
| 599 | @end defvar |
| 600 | |
| 601 | The command @code{eval-region} updates @code{load-history}, but does so |
| 602 | by adding the symbols defined to the element for the file being visited, |
| 603 | rather than replacing that element. |
| 604 | |
| 605 | @node Hooks for Loading |
| 606 | @section Hooks for Loading |
| 607 | @cindex loading hooks |
| 608 | @cindex hooks for loading |
| 609 | |
| 610 | You can ask for code to be executed if and when a particular library is |
| 611 | loaded, by calling @code{eval-after-load}. |
| 612 | |
| 613 | @defun eval-after-load library form |
| 614 | This function arranges to evaluate @var{form} at the end of loading the |
| 615 | library @var{library}, if and when @var{library} is loaded. If |
| 616 | @var{library} is already loaded, it evaluates @var{form} right away. |
| 617 | |
| 618 | The library name @var{library} must exactly match the argument of |
| 619 | @code{load}. To get the proper results when an installed library is |
| 620 | found by searching @code{load-path}, you should not include any |
| 621 | directory names in @var{library}. |
| 622 | |
| 623 | An error in @var{form} does not undo the load, but does prevent |
| 624 | execution of the rest of @var{form}. |
| 625 | @end defun |
| 626 | |
| 627 | In general, well-designed Lisp programs should not use this feature. |
| 628 | The clean and modular ways to interact with a Lisp library are (1) |
| 629 | examine and set the library's variables (those which are meant for |
| 630 | outside use), and (2) call the library's functions. If you wish to |
| 631 | do (1), you can do it immediately---there is no need to wait for when |
| 632 | the library is loaded. To do (2), you must load the library (preferably |
| 633 | with @code{require}). |
| 634 | |
| 635 | But it is ok to use @code{eval-after-load} in your personal customizations |
| 636 | if you don't feel they must meet the design standards of programs to be |
| 637 | released. |
| 638 | |
| 639 | @defvar after-load-alist |
| 640 | An alist of expressions to evaluate if and when particular libraries are |
| 641 | loaded. Each element looks like this: |
| 642 | |
| 643 | @example |
| 644 | (@var{filename} @var{forms}@dots{}) |
| 645 | @end example |
| 646 | |
| 647 | The function @code{load} checks @code{after-load-alist} in order to |
| 648 | implement @code{eval-after-load}. |
| 649 | @end defvar |
| 650 | |
| 651 | @c Emacs 19 feature |