Loading
*******

Loading a file of Lisp code means bringing its contents into the Lisp environment in the form of Lisp objects.  Emacs finds and opens the file, reads the text, evaluates each form, and then closes the file.  Such a file is also called a Lisp library.

The load functions evaluate all the expressions in a file just as the eval-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.

Emacs can also load compiled dynamic modules: shared libraries that provide additional functionality for use in Emacs Lisp programs, just like a package written in Emacs Lisp would.  When a dynamic module is loaded, Emacs calls a specially-named initialization function which the module needs to implement, and which exposes the additional functions and variables to Emacs Lisp programs.

For on-demand loading of external libraries which are known in advance to be required by certain Emacs primitives, see Dynamic Libraries.

How Programs Do Loading
=======================

Emacs Lisp has several interfaces for loading.  For example, autoload creates a placeholder object for a function defined in a file; trying to call the autoloading function loads the file to get the function's real definition (see Autoload).  require loads a file if it isn't already loaded (see Named Features).  Ultimately, all these facilities call the load function to do the work.

 -- Function: load filename &optional missing-ok nomessage nosuffix must-suffix
     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 the extension .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.  If Emacs was compiled with support for dynamic modules (see Dynamic Modules), load next looks for a file named FILENAME.EXT, where EXT is a system-dependent file-name extension of shared libraries.  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 Auto Compression mode is enabled, as it is by default, then if load can not find a file, it searches for a compressed version of the file before trying other file names.  It decompresses and loads it if it exists.  It looks for compressed versions by appending each of the suffixes in jka-compr-load-suffixes to the file name. The value of this variable must be a list of strings.  Its standard value is (".gz").

     If the optional argument NOSUFFIX is non-nil, then load does not try the suffixes .elc and .el.  In this case, you must specify the precise file name you want, except that, if Auto Compression mode is enabled, load will still use jka-compr-load-suffixes to find compressed versions.  By specifying the precise file name and using t for NOSUFFIX, you can prevent file names like foo.el.el from being tried.

     If the optional argument MUST-SUFFIX is non-nil, then load insists that the file name used must end in either .el or .elc (possibly extended with a compression suffix) or the shared-library extension, unless it contains an explicit directory name.

     If the option load-prefer-newer is non-nil, then when searching suffixes, load selects whichever version of a file (.elc, .el, etc.) has been modified most recently.

     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.  See Library Search.

     Whatever the name under which the file is eventually found, and the directory where Emacs found it, Emacs sets the value of the variable load-file-name to that file's name.

     If you get a warning that foo.elc is older than foo.el, it means you should consider recompiling foo.el.  See Byte Compilation.

     When loading a source file (not compiled), load performs character set translation just as Emacs would do when visiting the file. See Coding Systems.

     When loading an uncompiled file, Emacs tries to expand any macros that the file contains (see Macros).  We refer to this as eager macro expansion.  Doing this (rather than deferring the expansion until the relevant code runs) can significantly speed up the execution of uncompiled code.  Sometimes, this macro expansion cannot be done, owing to a cyclic dependency.  In the simplest example of this, the file you are loading refers to a macro defined in another file, and that file in turn requires the file you are loading.  This is generally harmless.  Emacs prints a warning (Eager macro-expansion skipped due to cycle...) giving details of the problem, but it still loads the file, just leaving the macro unexpanded for now.  You may wish to restructure your code so that this does not happen.  Loading a compiled file does not cause macroexpansion, because this should already have happened during compilation.  See Compiling Macros.

     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.

 -- Command: load-file filename
     This command loads the file FILENAME.  If FILENAME is a relative file name, then the current default directory is assumed. This command does not use load-path, and does not append suffixes.  However, it does look for compressed versions (if Auto Compression Mode is enabled).  Use this command if you wish to specify precisely the file name to load.

 -- Command: load-library library
     This command loads the library named LIBRARY.  It is equivalent to load, except for the way it reads its argument interactively. See Lisp Libraries (The GNU Emacs Manual).

 -- 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-file-name
     When Emacs is in the process of loading a file, this variable's value is the name of that file, as Emacs found it during the search described earlier in this section.

 -- 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.

     By default, this variable's value is read.  See Input Functions.

     Instead of using this variable, it is cleaner to use another, newer feature: to pass the function as the READ-FUNCTION argument to eval-region.  See Eval.

For information about how load is used in building Emacs, see Building Emacs.

Load Suffixes
=============

We now describe some technical details about the exact suffixes that load tries.

 -- Variable: load-suffixes
     This is a list of suffixes indicating (compiled or source) Emacs Lisp files.  It should not include the empty string.  load uses these suffixes in order when it appends Lisp suffixes to the specified file name.  The standard value is (".elc" ".el") which produces the behavior described in the previous section.

 -- Variable: load-file-rep-suffixes
     This is a list of suffixes that indicate representations of the same file.  This list should normally start with the empty string. When load searches for a file it appends the suffixes in this list, in order, to the file name, before searching for another file.

     Enabling Auto Compression mode appends the suffixes in jka-compr-load-suffixes to this list and disabling Auto Compression mode removes them again.  The standard value of load-file-rep-suffixes if Auto Compression mode is disabled is ("").  Given that the standard value of jka-compr-load-suffixes is (".gz"), the standard value of load-file-rep-suffixes if Auto Compression mode is enabled is ("" ".gz").

 -- Function: get-load-suffixes
     This function returns the list of all suffixes that load should try, in order, when its MUST-SUFFIX argument is non-nil. This takes both load-suffixes and load-file-rep-suffixes into account.  If load-suffixes, jka-compr-load-suffixes and load-file-rep-suffixes all have their standard values, this function returns (".elc" ".elc.gz" ".el" ".el.gz") if Auto Compression mode is enabled and (".elc" ".el") if Auto Compression mode is disabled.

To summarize, load normally first tries the suffixes in the value of (get-load-suffixes) and then those in load-file-rep-suffixes.  If NOSUFFIX is non-nil, it skips the former group, and if MUST-SUFFIX is non-nil, it skips the latter group.

 -- User Option: load-prefer-newer
     If this option is non-nil, then rather than stopping at the first suffix that exists, load tests them all, and uses whichever file is the newest.

Library Search
==============

When Emacs loads a Lisp library, it searches for the library in a list of directories specified by the variable load-path.

 -- Variable: 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).

When Emacs starts up, it sets up the value of load-path in several steps.  First, it initializes load-path using default locations set when Emacs was compiled.  Normally, this is a directory something like

     "/usr/local/share/emacs/VERSION/lisp"

(In this and the following examples, replace /usr/local with the installation prefix appropriate for your Emacs.) These directories contain the standard Lisp files that come with Emacs.  If Emacs cannot find them, it will not start correctly.

If you run Emacs from the directory where it was built---that is, an executable that has not been formally installed---Emacs instead initializes load-path using the lisp directory in the directory containing the sources from which it was built. If you built Emacs in a separate directory from the sources, it also adds the lisp directories from the build directory. (In all cases, elements are represented as absolute file names.)

Unless you start Emacs with the --no-site-lisp option, it then adds two more site-lisp directories to the front of load-path.  These are intended for locally installed Lisp files, and are normally of the form:

     "/usr/local/share/emacs/VERSION/site-lisp"

and

     "/usr/local/share/emacs/site-lisp"

The first one is for locally installed files for a specific Emacs version; the second is for locally installed files meant for use with all installed Emacs versions.  (If Emacs is running uninstalled, it also adds site-lisp directories from the source and build directories, if they exist.  Normally these directories do not contain site-lisp directories.)

If the environment variable EMACSLOADPATH is set, it modifies the above initialization procedure.  Emacs initializes load-path based on the value of the environment variable.

The syntax of EMACSLOADPATH is the same as used for PATH; directory names are separated by : (or ;, on some operating systems). Here is an example of how to set EMACSLOADPATH variable (from a sh-style shell):

     export EMACSLOADPATH=/home/foo/.emacs.d/lisp:

An empty element in the value of the environment variable, whether trailing (as in the above example), leading, or embedded, is replaced by the default value of load-path as determined by the standard initialization procedure.  If there are no such empty elements, then EMACSLOADPATH specifies the entire load-path.  You must include either an empty element, or the explicit path to the directory containing the standard Lisp files, else Emacs will not function. (Another way to modify load-path is to use the -L command-line option when starting Emacs; see below.)

For each directory in load-path, Emacs then checks to see if it contains a file subdirs.el, and if so, loads it.  The subdirs.el file is created when Emacs is built/installed, and contains code that causes Emacs to add any subdirectories of those directories to load-path.  Both immediate subdirectories and subdirectories multiple levels down are added.  But it excludes subdirectories whose names do not start with a letter or digit, and subdirectories named RCS or CVS, and subdirectories containing a file named .nosearch.

Next, Emacs adds any extra load directories that you specify using the -L command-line option (see Action Arguments (The GNU Emacs Manual)).  It also adds the directories where optional packages are installed, if any (see Packaging Basics).

It is common to add code to one's init file (see Init File) to add one or more directories to load-path.  For example:

     (push "~/.emacs.d/lisp" load-path)

Dumping Emacs uses a special value of load-path.  If you use a site-load.el or site-init.el file to customize the dumped Emacs (see Building Emacs), any changes to load-path that these files make will be lost after dumping.

 -- Command: locate-library library &optional nosuffix path interactive-call
     This command finds the precise file name for library LIBRARY.  It searches for the library in the same way load does, and the argument NOSUFFIX has the same meaning as in load: don't add suffixes .elc or .el to the specified name LIBRARY.

     If the PATH is non-nil, that list of directories is used instead of load-path.

     When locate-library is called from a program, it returns the file name as a string.  When the user runs locate-library interactively, the argument INTERACTIVE-CALL is t, and this tells locate-library to display the file name in the echo area.

 -- Command: list-load-path-shadows &optional stringp
     This command shows a list of shadowed Emacs Lisp files.  A shadowed file is one that will not normally be loaded, despite being in a directory on load-path, due to the existence of another similarly-named file in a directory earlier on load-path.

     For instance, suppose load-path is set to

            ("/opt/emacs/site-lisp" "/usr/share/emacs/23.3/lisp")

     and that both these directories contain a file named foo.el. Then (require 'foo) never loads the file in the second directory.  Such a situation might indicate a problem in the way Emacs was installed.

     When called from Lisp, this function prints a message listing the shadowed files, instead of displaying them in a buffer.  If the optional argument stringp is non-nil, it instead returns the shadowed files as a string.

Loading Non-ASCII Characters
============================

When Emacs Lisp programs contain string constants with non-ASCII characters, these can be represented within Emacs either as unibyte strings or as multibyte strings (see Text Representations).  Which representation is used depends on how the file is read into Emacs.  If it is read with decoding into multibyte representation, the text of the Lisp program will be multibyte text, and its string constants will be multibyte strings.  If a file containing Latin-1 characters (for example) is read without decoding, the text of the program will be unibyte text, and its string constants will be unibyte strings. See Coding Systems.

In most Emacs Lisp programs, the fact that non-ASCII strings are multibyte strings should not be noticeable, since inserting them in unibyte buffers converts them to unibyte automatically.  However, if this does make a difference, you can force a particular Lisp file to be interpreted as unibyte by writing coding: raw-text in a local variables section.  With that designator, the file will unconditionally be interpreted as unibyte.  This can matter when making keybindings to non-ASCII characters written as ?vLITERAL.

Autoload
========

The autoload facility lets you register the existence of a function or macro, but put off loading the file that defines it.  The first call to the function automatically loads the proper library, in order to install the real definition and other associated code, then runs the real definition as if it had been loaded all along. Autoloading can also be triggered by looking up the documentation of the function or macro (see Documentation Basics).

There are two ways to set up an autoloaded function: by calling autoload, and by writing a ``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 are the most convenient way to make a function autoload, for packages installed along with Emacs.  These comments do nothing on their own, but 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.

 -- 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.

     If FILENAME does not contain either a directory name, or the suffix .el or .elc, this function insists on adding one of these suffixes, and it will not load from a file whose name is just FILENAME with no added suffix.  (The variable load-suffixes specifies the exact required suffixes.)

     The argument DOCSTRING is the documentation string for the function.  Specifying the documentation string in the call to autoload makes it possible to look at the documentation without loading the function's real definition.  Normally, this should be identical to the documentation string in the function definition itself.  If it isn't, the function definition's documentation string takes effect when it is loaded.

     If INTERACTIVE is non-nil, that says FUNCTION can be called interactively.  This lets completion in M-x work without loading FUNCTION's real definition.  The complete interactive specification is not 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, this function does nothing and returns nil. Otherwise, it constructs an autoload object (see Autoload Type), and stores it as the function definition for FUNCTION.  The autoload object has this form:

          (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 emacs/etc/DOC file (see Documentation Basics), t means the function is interactive, and nil that it is not a macro or a keymap.

 -- Function: autoloadp object
     This function returns non-nil if OBJECT is an autoload object.  For example, to check if run-prolog is defined as an autoloaded function, evaluate

          (autoloadp (symbol-function 'run-prolog))

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 be defined by the aborted load, but fail to work properly for the lack of certain subroutines not loaded successfully because they come later in the file.

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 (often called an autoload cookie) consists of ;;;###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. (The string that serves as the autoload cookie and the name of the file generated by update-file-autoloads can be changed from the above defaults, see below.) 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.  The form following the magic comment is copied verbatim, except if it is one of the forms which the autoload facility handles specially (e.g., by conversion into an autoload call).  The forms which are not copied verbatim are the following:

Definitions for function or function-like objects:
     defun and defmacro; also cl-defun and cl-defmacro (see Argument Lists (Common Lisp Extensions)), and define-overloadable-function (see the commentary in mode-local.el).

Definitions for major or minor modes:
     define-minor-mode, define-globalized-minor-mode, define-generic-mode, define-derived-mode, easy-mmode-define-minor-mode, easy-mmode-define-global-mode, define-compilation-mode, and define-global-minor-mode.

Other definition types:
     defcustom, defgroup, defclass (see EIEIO), and define-skeleton (see Skeleton Language (Autotyping)).

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 M-x 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 (quote doctor) "doctor" "\
     Switch to *doctor* buffer and start giving psychotherapy.

     \(fn)" t nil)

The backslash and newline immediately following the double-quote are a convention used only in the preloaded uncompiled Lisp files such as loaddefs.el; they tell make-docfile to put the documentation string in the etc/DOC file.  See Building Emacs. See also the commentary in lib-src/make-docfile.c.  (fn) in the usage part of the documentation string is replaced with the function's name when the various help functions (see Help Functions) display it.

If you write a function definition with an unusual macro that is not one of the known and recognized function definition methods, use of an ordinary magic autoload comment would copy the whole definition into loaddefs.el.  That is not desirable.  You can put the desired autoload call into loaddefs.el instead by writing this:

     ;;;###autoload (autoload 'foo "myfile")
     (mydefunmacro foo
       ...)

You can use a non-default string as the autoload cookie and have the corresponding autoload calls written into a file whose name is different from the default loaddefs.el.  Emacs provides two variables to control this:

 -- Variable: generate-autoload-cookie
     The value of this variable should be a string whose syntax is a Lisp comment.  M-x update-file-autoloads copies the Lisp form that follows the cookie into the autoload file it generates.  The default value of this variable is ";;;###autoload".

 -- Variable: generated-autoload-file
     The value of this variable names an Emacs Lisp file where the autoload calls should go.  The default value is loaddefs.el, but you can override that, e.g., in the local variables section of a .el file (see File Local Variables).  The autoload file is assumed to contain a trailer starting with a formfeed character.

The following function may be used to explicitly load the library specified by an autoload object:

 -- Function: autoload-do-load autoload &optional name macro-only
     This function performs the loading specified by AUTOLOAD, which should be an autoload object.  The optional argument NAME, if non-nil, should be a symbol whose function value is AUTOLOAD; in that case, the return value of this function is the symbol's new function value.  If the value of the optional argument MACRO-ONLY is macro, this function avoids loading a function, only a macro.

Repeated Loading
================

You can load a given 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, you need to byte-compile the new version; otherwise Emacs will load the older, byte-compiled file instead of your newer, non-compiled file!  If that happens, the message displayed when loading the file includes, (compiled; note, source is newer), to remind you to recompile it.

When writing the forms in a Lisp library file, keep in mind that the file might be loaded more than once.  For example, think about whether each variable should be reinitialized when you reload the library; defvar does not change the value if the variable is already initialized.  (see Defining Variables.)

The simplest way to add an element to an alist is like this:

     (push '(leif-mode " Leif") minor-mode-alist)

But this would add multiple elements if the library is reloaded.  To avoid the problem, use add-to-list (see List Variables):

     (add-to-list 'minor-mode-alist '(leif-mode " Leif"))

Occasionally you will want to test explicitly whether a library has already been loaded.  If the library uses provide to provide a named feature, you can use featurep earlier in the file to test whether the provide call has been executed before (see Named Features).  Alternatively, you could use something like this:

     (defvar foo-was-loaded nil)

     (unless foo-was-loaded
       EXECUTE-FIRST-TIME-ONLY
       (setq foo-was-loaded t))

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.

For example, in idlwave.el, the definition for idlwave-complete-filename includes the following code:

     (defun idlwave-complete-filename ()
       "Use the comint stuff to complete a file name."
        (require 'comint)
        (let* ((comint-file-name-chars "~/A-Za-z0-9+@:_.$#%={}\\-")
               (comint-completion-addsuffix nil)
               ...)
            (comint-dynamic-complete-filename)))

The expression (require 'comint) loads the file comint.el if it has not yet been loaded, ensuring that comint-dynamic-complete-filename is defined.  Features are normally named after the files that provide them, so that require need not be given the file name.  (Note that it is important that the require statement be outside the body of the let.  Loading a library while its variables are let-bound can have unintended consequences, namely the variables becoming unbound after the let exits.)

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 (see 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.  It also avoids byte compiler warnings for functions and variables defined in the file loaded with require.

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 when the file is loaded.

 -- Function: provide feature &optional subfeatures
     This function announces that FEATURE is now loaded, or being loaded, into the current Emacs 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 features if it is not already in that list and call any eval-after-load code waiting for it (see Hooks for Loading).  The argument FEATURE must be a symbol. provide returns FEATURE.

     If provided, SUBFEATURES should be a list of symbols indicating a set of specific subfeatures provided by this version of FEATURE.  You can test the presence of a subfeature using featurep.  The idea of subfeatures is that you use them when a package (which is one FEATURE) is complex enough to make it useful to give names to various parts or functionalities of the package, which might or might not be loaded, or might or might not be present in a given version.  See Network Feature Testing, for an example.

          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 evaluation of its contents, any function definitions or provide calls that occurred during the load are undone. See Autoload.

 -- Function: require feature &optional filename noerror
     This function checks whether FEATURE is present in the current Emacs session (using (featurep FEATURE); see below).  The argument FEATURE must be a symbol.

     If the feature is not present, then require loads FILENAME with load.  If FILENAME is not supplied, then the name of the symbol FEATURE is used as the base file name to load. However, in this case, require insists on finding FEATURE with an added .el or .elc suffix (possibly extended with a compression suffix); a file whose name is just FEATURE won't be used.  (The variable load-suffixes specifies the exact required Lisp suffixes.)

     If NOERROR is non-nil, that suppresses errors from actual loading of the file.  In that case, require returns nil if loading the file fails.  Normally, require returns FEATURE.

     If loading the file succeeds but does not provide FEATURE, require signals an error, Required feature FEATURE was not provided.

 -- Function: featurep feature &optional subfeature
     This function returns t if FEATURE has been provided in the current Emacs session (i.e., if FEATURE is a member of features.)  If SUBFEATURE is non-nil, then the function returns t only if that subfeature is provided as well (i.e., if SUBFEATURE is a member of the subfeature property of the FEATURE symbol.)

 -- Variable: features
     The value of this variable is a list of symbols that are the features loaded in the current Emacs 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.

Which File Defined a Certain Symbol
===================================

 -- Function: symbol-file symbol &optional type
     This function returns the name of the file that defined SYMBOL. If TYPE is nil, then any kind of definition is acceptable. If TYPE is defun, defvar, or defface, that specifies function definition, variable definition, or face definition only.

     The value is normally an absolute file name.  It can also be nil, if the definition is not associated with any file.  If SYMBOL specifies an autoloaded function, the value can be a relative file name without extension.

The basis for symbol-file is the data in the variable load-history.

 -- Variable: load-history
     The value of this variable is an alist that associates the names of loaded library files with the names of the functions and variables they defined, as well as the features they provided or required.

     Each element in this alist describes one loaded library (including libraries that are preloaded at startup).  It is a list whose CAR is the absolute file name of the library (a string).  The rest of the list elements have these forms:

     VAR
          The symbol VAR was defined as a variable.

     (defun . FUN)
          The function FUN was defined.

     (t . FUN)
          The function FUN was previously an autoload before this library redefined it as a function.  The following element is always (defun . FUN), which represents defining FUN as a function.

     (autoload . FUN)
          The function FUN was defined as an autoload.

     (defface . FACE)
          The face FACE was defined.

     (require . FEATURE)
          The feature FEATURE was required.

     (provide . FEATURE)
          The feature FEATURE was provided.

     (cl-defmethod METHOD SPECIALIZERS)
          The named METHOD was defined by using cl-defmethod, with SPECIALIZERS as its specializers.

     (define-type . TYPE)
          The type TYPE was defined.

     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.  See Eval.

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 defun, defalias, defsubst, defmacro, defconst, defvar, and defcustom. It then restores any autoloads formerly associated with those symbols. (Loading saves these in the autoload property of the symbol.)

     Before restoring the previous definitions, unload-feature runs remove-hook to remove functions in the library from certain hooks.  These hooks include variables whose names end in -hook (or the deprecated suffix -hooks), plus those listed in unload-feature-special-hooks, as well as auto-mode-alist.  This is to prevent Emacs from ceasing to function because important hooks refer to functions that are no longer defined.

     Standard unloading activities also undoes ELP profiling of functions in that library, unprovides any features provided by the library, and cancels timers held in variables defined by the library.

     If these measures are not sufficient to prevent malfunction, a library can define an explicit unloader named FEATURE-unload-function. If that symbol is defined as a function, unload-feature calls it with no arguments before doing anything else.  It can do whatever is appropriate to unload the library.  If it returns nil, unload-feature proceeds to take the normal unload actions. Otherwise it considers the job to be done.

     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: unload-feature-special-hooks
     This variable holds a list of hooks to be scanned before unloading a library, to remove functions defined in the library.

Hooks for Loading
=================

You can ask for code to be executed each time Emacs loads a library, by using the variable after-load-functions:

 -- Variable: after-load-functions
     This abnormal hook is run after loading a file.  Each function in the hook is called with a single argument, the absolute filename of the file that was just loaded.

If you want code to be executed when a particular library is loaded, use the macro with-eval-after-load:

 -- Macro: with-eval-after-load library body...
     This macro arranges to evaluate BODY at the end of loading the file LIBRARY, each time LIBRARY is loaded.  If LIBRARY is already loaded, it evaluates BODY right away.

     You don't need to give a directory or extension in the file name LIBRARY.  Normally, you just give a bare file name, like this:

          (with-eval-after-load "edebug" (def-edebug-spec c-point t))

     To restrict which files can trigger the evaluation, include a directory or an extension or both in LIBRARY.  Only a file whose absolute true name (i.e., the name with all symbolic links chased out) matches all the given name components will match.  In the following example, my_inst.elc or my_inst.elc.gz in some directory ..../foo/bar will trigger the evaluation, but not my_inst.el:

          (with-eval-after-load "foo/bar/my_inst.elc" ...)

     LIBRARY can also be a feature (i.e., a symbol), in which case BODY is evaluated at the end of any file where (provide LIBRARY) is called.

     An error in BODY does not undo the load, but does prevent execution of the rest of BODY.

Normally, well-designed Lisp programs should not use with-eval-after-load.  If you need to examine and set the variables defined in another library (those meant for outside use), you can do it immediately---there is no need to wait until the library is loaded.  If you need to call functions defined by that library, you should load the library, preferably with require (see Named Features).

Emacs Dynamic Modules
=====================

A dynamic Emacs module is a shared library that provides additional functionality for use in Emacs Lisp programs, just like a package written in Emacs Lisp would.

Functions that load Emacs Lisp packages can also load dynamic modules.  They recognize dynamic modules by looking at their file-name extension, a.k.a. ``suffix''.  This suffix is platform-dependent.

 -- Variable: module-file-suffix
     This variable holds the system-dependent value of the file-name extension of the module files.  Its value is .so on Posix hosts and .dll on MS-Windows.

Every dynamic module should export a C-callable function named emacs_module_init, which Emacs will call as part of the call to load or require which loads the module.  It should also export a symbol named plugin_is_GPL_compatible to indicate that its code is released under the GPL or compatible license; Emacs will refuse to load modules that don't export such a symbol.

If a module needs to call Emacs functions, it should do so through the API defined and documented in the header file emacs-module.h that is part of the Emacs distribution.

Modules can create user-ptr Lisp objects that embed pointers to C struct's defined by the module.  This is useful for keeping around complex data structures created by a module, to be passed back to the module's functions.  User-ptr objects can also have associated finalizers -- functions to be run when the object is GC'ed; this is useful for freeing any resources allocated for the underlying data structure, such as memory, open file descriptors, etc.

 -- Function: user-ptrp object
     This function returns t if its argument is a user-ptr object.

Loadable modules in Emacs are enabled by using the --with-modules option at configure time.