Initial revision
This commit is contained in:
parent
a0acfc98dc
commit
83ac6b4598
3 changed files with 2585 additions and 0 deletions
1136
lispref/control.texi
Normal file
1136
lispref/control.texi
Normal file
File diff suppressed because it is too large
Load diff
867
lispref/intro.texi
Normal file
867
lispref/intro.texi
Normal file
|
@ -0,0 +1,867 @@
|
|||
@c -*-texinfo-*-
|
||||
@c This is part of the GNU Emacs Lisp Reference Manual.
|
||||
@c Copyright (C) 1990, 1991, 1992, 1993, 1994 Free Software Foundation, Inc.
|
||||
@c See the file elisp.texi for copying conditions.
|
||||
@setfilename ../info/intro
|
||||
|
||||
@node Copying, Introduction, Top, Top
|
||||
@comment node-name, next, previous, up
|
||||
@unnumbered GNU GENERAL PUBLIC LICENSE
|
||||
@center Version 2, June 1991
|
||||
|
||||
@display
|
||||
Copyright @copyright{} 1989, 1991 Free Software Foundation, Inc.
|
||||
675 Mass Ave, Cambridge, MA 02139, USA
|
||||
|
||||
Everyone is permitted to copy and distribute verbatim copies
|
||||
of this license document, but changing it is not allowed.
|
||||
@end display
|
||||
|
||||
@unnumberedsec Preamble
|
||||
|
||||
The licenses for most software are designed to take away your
|
||||
freedom to share and change it. By contrast, the GNU General Public
|
||||
License is intended to guarantee your freedom to share and change free
|
||||
software---to make sure the software is free for all its users. This
|
||||
General Public License applies to most of the Free Software
|
||||
Foundation's software and to any other program whose authors commit to
|
||||
using it. (Some other Free Software Foundation software is covered by
|
||||
the GNU Library General Public License instead.) You can apply it to
|
||||
your programs, too.
|
||||
|
||||
When we speak of free software, we are referring to freedom, not
|
||||
price. Our General Public Licenses are designed to make sure that you
|
||||
have the freedom to distribute copies of free software (and charge for
|
||||
this service if you wish), that you receive source code or can get it
|
||||
if you want it, that you can change the software or use pieces of it
|
||||
in new free programs; and that you know you can do these things.
|
||||
|
||||
To protect your rights, we need to make restrictions that forbid
|
||||
anyone to deny you these rights or to ask you to surrender the rights.
|
||||
These restrictions translate to certain responsibilities for you if you
|
||||
distribute copies of the software, or if you modify it.
|
||||
|
||||
For example, if you distribute copies of such a program, whether
|
||||
gratis or for a fee, you must give the recipients all the rights that
|
||||
you have. You must make sure that they, too, receive or can get the
|
||||
source code. And you must show them these terms so they know their
|
||||
rights.
|
||||
|
||||
We protect your rights with two steps: (1) copyright the software, and
|
||||
(2) offer you this license which gives you legal permission to copy,
|
||||
distribute and/or modify the software.
|
||||
|
||||
Also, for each author's protection and ours, we want to make certain
|
||||
that everyone understands that there is no warranty for this free
|
||||
software. If the software is modified by someone else and passed on, we
|
||||
want its recipients to know that what they have is not the original, so
|
||||
that any problems introduced by others will not reflect on the original
|
||||
authors' reputations.
|
||||
|
||||
Finally, any free program is threatened constantly by software
|
||||
patents. We wish to avoid the danger that redistributors of a free
|
||||
program will individually obtain patent licenses, in effect making the
|
||||
program proprietary. To prevent this, we have made it clear that any
|
||||
patent must be licensed for everyone's free use or not licensed at all.
|
||||
|
||||
The precise terms and conditions for copying, distribution and
|
||||
modification follow.
|
||||
|
||||
@iftex
|
||||
@unnumberedsec TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
|
||||
@end iftex
|
||||
@ifinfo
|
||||
@center TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
|
||||
@end ifinfo
|
||||
|
||||
@enumerate 0
|
||||
@item
|
||||
This License applies to any program or other work which contains
|
||||
a notice placed by the copyright holder saying it may be distributed
|
||||
under the terms of this General Public License. The ``Program'', below,
|
||||
refers to any such program or work, and a ``work based on the Program''
|
||||
means either the Program or any derivative work under copyright law:
|
||||
that is to say, a work containing the Program or a portion of it,
|
||||
either verbatim or with modifications and/or translated into another
|
||||
language. (Hereinafter, translation is included without limitation in
|
||||
the term ``modification''.) Each licensee is addressed as ``you''.
|
||||
|
||||
Activities other than copying, distribution and modification are not
|
||||
covered by this License; they are outside its scope. The act of
|
||||
running the Program is not restricted, and the output from the Program
|
||||
is covered only if its contents constitute a work based on the
|
||||
Program (independent of having been made by running the Program).
|
||||
Whether that is true depends on what the Program does.
|
||||
|
||||
@item
|
||||
You may copy and distribute verbatim copies of the Program's
|
||||
source code as you receive it, in any medium, provided that you
|
||||
conspicuously and appropriately publish on each copy an appropriate
|
||||
copyright notice and disclaimer of warranty; keep intact all the
|
||||
notices that refer to this License and to the absence of any warranty;
|
||||
and give any other recipients of the Program a copy of this License
|
||||
along with the Program.
|
||||
|
||||
You may charge a fee for the physical act of transferring a copy, and
|
||||
you may at your option offer warranty protection in exchange for a fee.
|
||||
|
||||
@item
|
||||
You may modify your copy or copies of the Program or any portion
|
||||
of it, thus forming a work based on the Program, and copy and
|
||||
distribute such modifications or work under the terms of Section 1
|
||||
above, provided that you also meet all of these conditions:
|
||||
|
||||
@enumerate a
|
||||
@item
|
||||
You must cause the modified files to carry prominent notices
|
||||
stating that you changed the files and the date of any change.
|
||||
|
||||
@item
|
||||
You must cause any work that you distribute or publish, that in
|
||||
whole or in part contains or is derived from the Program or any
|
||||
part thereof, to be licensed as a whole at no charge to all third
|
||||
parties under the terms of this License.
|
||||
|
||||
@item
|
||||
If the modified program normally reads commands interactively
|
||||
when run, you must cause it, when started running for such
|
||||
interactive use in the most ordinary way, to print or display an
|
||||
announcement including an appropriate copyright notice and a
|
||||
notice that there is no warranty (or else, saying that you provide
|
||||
a warranty) and that users may redistribute the program under
|
||||
these conditions, and telling the user how to view a copy of this
|
||||
License. (Exception: if the Program itself is interactive but
|
||||
does not normally print such an announcement, your work based on
|
||||
the Program is not required to print an announcement.)
|
||||
@end enumerate
|
||||
|
||||
These requirements apply to the modified work as a whole. If
|
||||
identifiable sections of that work are not derived from the Program,
|
||||
and can be reasonably considered independent and separate works in
|
||||
themselves, then this License, and its terms, do not apply to those
|
||||
sections when you distribute them as separate works. But when you
|
||||
distribute the same sections as part of a whole which is a work based
|
||||
on the Program, the distribution of the whole must be on the terms of
|
||||
this License, whose permissions for other licensees extend to the
|
||||
entire whole, and thus to each and every part regardless of who wrote it.
|
||||
|
||||
Thus, it is not the intent of this section to claim rights or contest
|
||||
your rights to work written entirely by you; rather, the intent is to
|
||||
exercise the right to control the distribution of derivative or
|
||||
collective works based on the Program.
|
||||
|
||||
In addition, mere aggregation of another work not based on the Program
|
||||
with the Program (or with a work based on the Program) on a volume of
|
||||
a storage or distribution medium does not bring the other work under
|
||||
the scope of this License.
|
||||
|
||||
@item
|
||||
You may copy and distribute the Program (or a work based on it,
|
||||
under Section 2) in object code or executable form under the terms of
|
||||
Sections 1 and 2 above provided that you also do one of the following:
|
||||
|
||||
@enumerate a
|
||||
@item
|
||||
Accompany it with the complete corresponding machine-readable
|
||||
source code, which must be distributed under the terms of Sections
|
||||
1 and 2 above on a medium customarily used for software interchange; or,
|
||||
|
||||
@item
|
||||
Accompany it with a written offer, valid for at least three
|
||||
years, to give any third party, for a charge no more than your
|
||||
cost of physically performing source distribution, a complete
|
||||
machine-readable copy of the corresponding source code, to be
|
||||
distributed under the terms of Sections 1 and 2 above on a medium
|
||||
customarily used for software interchange; or,
|
||||
|
||||
@item
|
||||
Accompany it with the information you received as to the offer
|
||||
to distribute corresponding source code. (This alternative is
|
||||
allowed only for noncommercial distribution and only if you
|
||||
received the program in object code or executable form with such
|
||||
an offer, in accord with Subsection b above.)
|
||||
@end enumerate
|
||||
|
||||
The source code for a work means the preferred form of the work for
|
||||
making modifications to it. For an executable work, complete source
|
||||
code means all the source code for all modules it contains, plus any
|
||||
associated interface definition files, plus the scripts used to
|
||||
control compilation and installation of the executable. However, as a
|
||||
special exception, the source code distributed need not include
|
||||
anything that is normally distributed (in either source or binary
|
||||
form) with the major components (compiler, kernel, and so on) of the
|
||||
operating system on which the executable runs, unless that component
|
||||
itself accompanies the executable.
|
||||
|
||||
If distribution of executable or object code is made by offering
|
||||
access to copy from a designated place, then offering equivalent
|
||||
access to copy the source code from the same place counts as
|
||||
distribution of the source code, even though third parties are not
|
||||
compelled to copy the source along with the object code.
|
||||
|
||||
@item
|
||||
You may not copy, modify, sublicense, or distribute the Program
|
||||
except as expressly provided under this License. Any attempt
|
||||
otherwise to copy, modify, sublicense or distribute the Program is
|
||||
void, and will automatically terminate your rights under this License.
|
||||
However, parties who have received copies, or rights, from you under
|
||||
this License will not have their licenses terminated so long as such
|
||||
parties remain in full compliance.
|
||||
|
||||
@item
|
||||
You are not required to accept this License, since you have not
|
||||
signed it. However, nothing else grants you permission to modify or
|
||||
distribute the Program or its derivative works. These actions are
|
||||
prohibited by law if you do not accept this License. Therefore, by
|
||||
modifying or distributing the Program (or any work based on the
|
||||
Program), you indicate your acceptance of this License to do so, and
|
||||
all its terms and conditions for copying, distributing or modifying
|
||||
the Program or works based on it.
|
||||
|
||||
@item
|
||||
Each time you redistribute the Program (or any work based on the
|
||||
Program), the recipient automatically receives a license from the
|
||||
original licensor to copy, distribute or modify the Program subject to
|
||||
these terms and conditions. You may not impose any further
|
||||
restrictions on the recipients' exercise of the rights granted herein.
|
||||
You are not responsible for enforcing compliance by third parties to
|
||||
this License.
|
||||
|
||||
@item
|
||||
If, as a consequence of a court judgment or allegation of patent
|
||||
infringement or for any other reason (not limited to patent issues),
|
||||
conditions are imposed on you (whether by court order, agreement or
|
||||
otherwise) that contradict the conditions of this License, they do not
|
||||
excuse you from the conditions of this License. If you cannot
|
||||
distribute so as to satisfy simultaneously your obligations under this
|
||||
License and any other pertinent obligations, then as a consequence you
|
||||
may not distribute the Program at all. For example, if a patent
|
||||
license would not permit royalty-free redistribution of the Program by
|
||||
all those who receive copies directly or indirectly through you, then
|
||||
the only way you could satisfy both it and this License would be to
|
||||
refrain entirely from distribution of the Program.
|
||||
|
||||
If any portion of this section is held invalid or unenforceable under
|
||||
any particular circumstance, the balance of the section is intended to
|
||||
apply and the section as a whole is intended to apply in other
|
||||
circumstances.
|
||||
|
||||
It is not the purpose of this section to induce you to infringe any
|
||||
patents or other property right claims or to contest validity of any
|
||||
such claims; this section has the sole purpose of protecting the
|
||||
integrity of the free software distribution system, which is
|
||||
implemented by public license practices. Many people have made
|
||||
generous contributions to the wide range of software distributed
|
||||
through that system in reliance on consistent application of that
|
||||
system; it is up to the author/donor to decide if he or she is willing
|
||||
to distribute software through any other system and a licensee cannot
|
||||
impose that choice.
|
||||
|
||||
This section is intended to make thoroughly clear what is believed to
|
||||
be a consequence of the rest of this License.
|
||||
|
||||
@item
|
||||
If the distribution and/or use of the Program is restricted in
|
||||
certain countries either by patents or by copyrighted interfaces, the
|
||||
original copyright holder who places the Program under this License
|
||||
may add an explicit geographical distribution limitation excluding
|
||||
those countries, so that distribution is permitted only in or among
|
||||
countries not thus excluded. In such case, this License incorporates
|
||||
the limitation as if written in the body of this License.
|
||||
|
||||
@item
|
||||
The Free Software Foundation may publish revised and/or new versions
|
||||
of the General Public License from time to time. Such new versions will
|
||||
be similar in spirit to the present version, but may differ in detail to
|
||||
address new problems or concerns.
|
||||
|
||||
Each version is given a distinguishing version number. If the Program
|
||||
specifies a version number of this License which applies to it and ``any
|
||||
later version'', you have the option of following the terms and conditions
|
||||
either of that version or of any later version published by the Free
|
||||
Software Foundation. If the Program does not specify a version number of
|
||||
this License, you may choose any version ever published by the Free Software
|
||||
Foundation.
|
||||
|
||||
@item
|
||||
If you wish to incorporate parts of the Program into other free
|
||||
programs whose distribution conditions are different, write to the author
|
||||
to ask for permission. For software which is copyrighted by the Free
|
||||
Software Foundation, write to the Free Software Foundation; we sometimes
|
||||
make exceptions for this. Our decision will be guided by the two goals
|
||||
of preserving the free status of all derivatives of our free software and
|
||||
of promoting the sharing and reuse of software generally.
|
||||
|
||||
@iftex
|
||||
@heading NO WARRANTY
|
||||
@end iftex
|
||||
@ifinfo
|
||||
@center NO WARRANTY
|
||||
@end ifinfo
|
||||
|
||||
@item
|
||||
BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY
|
||||
FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW@. EXCEPT WHEN
|
||||
OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES
|
||||
PROVIDE THE PROGRAM ``AS IS'' WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED
|
||||
OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
|
||||
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE@. THE ENTIRE RISK AS
|
||||
TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU@. SHOULD THE
|
||||
PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING,
|
||||
REPAIR OR CORRECTION.
|
||||
|
||||
@item
|
||||
IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
|
||||
WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR
|
||||
REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES,
|
||||
INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING
|
||||
OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED
|
||||
TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY
|
||||
YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER
|
||||
PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE
|
||||
POSSIBILITY OF SUCH DAMAGES.
|
||||
@end enumerate
|
||||
|
||||
@iftex
|
||||
@heading END OF TERMS AND CONDITIONS
|
||||
@end iftex
|
||||
@ifinfo
|
||||
@center END OF TERMS AND CONDITIONS
|
||||
@end ifinfo
|
||||
|
||||
@page
|
||||
@unnumberedsec How to Apply These Terms to Your New Programs
|
||||
|
||||
If you develop a new program, and you want it to be of the greatest
|
||||
possible use to the public, the best way to achieve this is to make it
|
||||
free software which everyone can redistribute and change under these terms.
|
||||
|
||||
To do so, attach the following notices to the program. It is safest
|
||||
to attach them to the start of each source file to most effectively
|
||||
convey the exclusion of warranty; and each file should have at least
|
||||
the ``copyright'' line and a pointer to where the full notice is found.
|
||||
|
||||
@smallexample
|
||||
@var{one line to give the program's name and an idea of what it does.}
|
||||
Copyright (C) 19@var{yy} @var{name of author}
|
||||
|
||||
This program is free software; you can redistribute it and/or
|
||||
modify it under the terms of the GNU General Public License
|
||||
as published by the Free Software Foundation; either version 2
|
||||
of the License, or (at your option) any later version.
|
||||
|
||||
This program is distributed in the hope that it will be useful,
|
||||
but WITHOUT ANY WARRANTY; without even the implied warranty of
|
||||
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE@. See the
|
||||
GNU General Public License for more details.
|
||||
|
||||
You should have received a copy of the GNU General Public License
|
||||
along with this program; if not, write to the Free Software
|
||||
Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
|
||||
@end smallexample
|
||||
|
||||
Also add information on how to contact you by electronic and paper mail.
|
||||
|
||||
If the program is interactive, make it output a short notice like this
|
||||
when it starts in an interactive mode:
|
||||
|
||||
@smallexample
|
||||
Gnomovision version 69, Copyright (C) 19@var{yy} @var{name of author}
|
||||
Gnomovision comes with ABSOLUTELY NO WARRANTY; for details
|
||||
type `show w'. This is free software, and you are welcome
|
||||
to redistribute it under certain conditions; type `show c'
|
||||
for details.
|
||||
@end smallexample
|
||||
|
||||
The hypothetical commands @samp{show w} and @samp{show c} should show
|
||||
the appropriate parts of the General Public License. Of course, the
|
||||
commands you use may be called something other than @samp{show w} and
|
||||
@samp{show c}; they could even be mouse-clicks or menu items---whatever
|
||||
suits your program.
|
||||
|
||||
You should also get your employer (if you work as a programmer) or your
|
||||
school, if any, to sign a ``copyright disclaimer'' for the program, if
|
||||
necessary. Here is a sample; alter the names:
|
||||
|
||||
@smallexample
|
||||
@group
|
||||
Yoyodyne, Inc., hereby disclaims all copyright
|
||||
interest in the program `Gnomovision'
|
||||
(which makes passes at compilers) written
|
||||
by James Hacker.
|
||||
|
||||
@var{signature of Ty Coon}, 1 April 1989
|
||||
Ty Coon, President of Vice
|
||||
@end group
|
||||
@end smallexample
|
||||
|
||||
This General Public License does not permit incorporating your program into
|
||||
proprietary programs. If your program is a subroutine library, you may
|
||||
consider it more useful to permit linking proprietary applications with the
|
||||
library. If this is what you want to do, use the GNU Library General
|
||||
Public License instead of this License.
|
||||
|
||||
@node Introduction, Types of Lisp Object, Copying, Top
|
||||
@chapter Introduction
|
||||
|
||||
Most of the GNU Emacs text editor is written in the programming
|
||||
language called Emacs Lisp. You can write new code in Emacs Lisp and
|
||||
install it as an extension to the editor. However, Emacs Lisp is more
|
||||
than a mere ``extension language''; it is a full computer programming
|
||||
language in its own right. You can use it as you would any other
|
||||
programming language.
|
||||
|
||||
Because Emacs Lisp is designed for use in an editor, it has special
|
||||
features for scanning and parsing text as well as features for handling
|
||||
files, buffers, displays, subprocesses, and so on. Emacs Lisp is
|
||||
closely integrated with the editing facilities; thus, editing commands
|
||||
are functions that can also conveniently be called from Lisp programs,
|
||||
and parameters for customization are ordinary Lisp variables.
|
||||
|
||||
This manual describes Emacs Lisp, presuming considerable familiarity
|
||||
with the use of Emacs for editing. (See @cite{The GNU Emacs Manual},
|
||||
for this basic information.) Generally speaking, the earlier chapters
|
||||
describe features of Emacs Lisp that have counterparts in many
|
||||
programming languages, and later chapters describe features that are
|
||||
peculiar to Emacs Lisp or relate specifically to editing.
|
||||
|
||||
This is edition 2.3.
|
||||
|
||||
@menu
|
||||
* Caveats:: Flaws and a request for help.
|
||||
* Lisp History:: Emacs Lisp is descended from Maclisp.
|
||||
* Conventions:: How the manual is formatted.
|
||||
* Acknowledgements:: The authors, editors, and sponsors of this manual.
|
||||
@end menu
|
||||
|
||||
@node Caveats
|
||||
@section Caveats
|
||||
|
||||
This manual has gone through numerous drafts. It is nearly complete
|
||||
but not flawless. There are a few sections which are not included,
|
||||
either because we consider them secondary (such as most of the
|
||||
individual modes) or because they are yet to be written.
|
||||
|
||||
Because we are not able to deal with them completely, we have left out
|
||||
several parts intentionally. This includes most information about usage
|
||||
on VMS.
|
||||
|
||||
The manual should be fully correct in what it does cover, and it is
|
||||
therefore open to criticism on anything it says---from specific examples
|
||||
and descriptive text, to the ordering of chapters and sections. If
|
||||
something is confusing, or you find that you have to look at the sources
|
||||
or experiment to learn something not covered in the manual, then perhaps
|
||||
the manual should be fixed. Please let us know.
|
||||
|
||||
@iftex
|
||||
As you use the manual, we ask that you mark pages with corrections so
|
||||
you can later look them up and send them in. If you think of a simple,
|
||||
real life example for a function or group of functions, please make an
|
||||
effort to write it up and send it in. Please reference any comments to
|
||||
the chapter name, section name, and function name, as appropriate, since
|
||||
page numbers and chapter and section numbers will change. Also state
|
||||
the number of the edition which you are criticizing.
|
||||
@end iftex
|
||||
@ifinfo
|
||||
|
||||
As you use this manual, we ask that you send corrections as soon as you
|
||||
find them. If you think of a simple, real life example for a function
|
||||
or group of functions, please make an effort to write it up and send it
|
||||
in. Please reference any comments to the node name and function or
|
||||
variable name, as appropriate. Also state the number of the edition
|
||||
which you are criticizing.
|
||||
@end ifinfo
|
||||
|
||||
Please mail comments and corrections to
|
||||
|
||||
@example
|
||||
bug-lisp-manual@@prep.ai.mit.edu
|
||||
@end example
|
||||
|
||||
@noindent
|
||||
We let mail to this list accumulate unread until someone decides to
|
||||
apply the corrections. Months, and sometimes years, go by between
|
||||
updates. So please attach no significance to the lack of a reply---your
|
||||
mail @emph{will} be acted on in due time. If you want to contact the
|
||||
Emacs maintainers more quickly, send mail to
|
||||
@code{bug-gnu-emacs@@prep.ai.mit.edu}.
|
||||
|
||||
@display
|
||||
--Bil Lewis, Dan LaLiberte, Richard Stallman
|
||||
@end display
|
||||
|
||||
@node Lisp History
|
||||
@section Lisp History
|
||||
@cindex Lisp history
|
||||
|
||||
Lisp (LISt Processing language) was first developed in the late 1950s
|
||||
at the Massachusetts Institute of Technology for research in artificial
|
||||
intelligence. The great power of the Lisp language makes it superior
|
||||
for other purposes as well, such as writing editing commands.
|
||||
|
||||
@cindex Maclisp
|
||||
@cindex Common Lisp
|
||||
Dozens of Lisp implementations have been built over the years, each
|
||||
with its own idiosyncrasies. Many of them were inspired by Maclisp,
|
||||
which was written in the 1960's at MIT's Project MAC. Eventually the
|
||||
implementors of the descendents of Maclisp came together and developed a
|
||||
standard for Lisp systems, called Common Lisp.
|
||||
|
||||
GNU Emacs Lisp is largely inspired by Maclisp, and a little by Common
|
||||
Lisp. If you know Common Lisp, you will notice many similarities.
|
||||
However, many of the features of Common Lisp have been omitted or
|
||||
simplified in order to reduce the memory requirements of GNU Emacs.
|
||||
Sometimes the simplifications are so drastic that a Common Lisp user
|
||||
might be very confused. We will occasionally point out how GNU Emacs
|
||||
Lisp differs from Common Lisp. If you don't know Common Lisp, don't
|
||||
worry about it; this manual is self-contained.
|
||||
|
||||
@node Conventions
|
||||
@section Conventions
|
||||
|
||||
This section explains the notational conventions that are used in this
|
||||
manual. You may want to skip this section and refer back to it later.
|
||||
|
||||
@menu
|
||||
* Some Terms:: Explanation of terms we use in this manual.
|
||||
* nil and t:: How the symbols @code{nil} and @code{t} are used.
|
||||
* Evaluation Notation:: The format we use for examples of evaluation.
|
||||
* Printing Notation:: The format we use for examples that print output.
|
||||
* Error Messages:: The format we use for examples of errors.
|
||||
* Buffer Text Notation:: The format we use for buffer contents in examples.
|
||||
* Format of Descriptions:: Notation for describing functions, variables, etc.
|
||||
@end menu
|
||||
|
||||
@node Some Terms
|
||||
@subsection Some Terms
|
||||
|
||||
Throughout this manual, the phrases ``the Lisp reader'' and ``the Lisp
|
||||
printer'' are used to refer to those routines in Lisp that convert
|
||||
textual representations of Lisp objects into actual objects, and vice
|
||||
versa. @xref{Printed Representation}, for more details. You, the
|
||||
person reading this manual, are thought of as ``the programmer'' and are
|
||||
addressed as ``you''. ``The user'' is the person who uses Lisp programs
|
||||
including those you write.
|
||||
|
||||
@cindex fonts
|
||||
Examples of Lisp code appear in this font or form: @code{(list 1 2
|
||||
3)}. Names that represent arguments or metasyntactic variables appear
|
||||
in this font or form: @var{first-number}.
|
||||
|
||||
@node nil and t
|
||||
@subsection @code{nil} and @code{t}
|
||||
@cindex @code{nil}, uses of
|
||||
@cindex truth value
|
||||
@cindex boolean
|
||||
@cindex false
|
||||
|
||||
In Lisp, the symbol @code{nil} is overloaded with three meanings: it
|
||||
is a symbol with the name @samp{nil}; it is the logical truth value
|
||||
@var{false}; and it is the empty list---the list of zero elements.
|
||||
When used as a variable, @code{nil} always has the value @code{nil}.
|
||||
|
||||
As far as the Lisp reader is concerned, @samp{()} and @samp{nil} are
|
||||
identical: they stand for the same object, the symbol @code{nil}. The
|
||||
different ways of writing the symbol are intended entirely for human
|
||||
readers. After the Lisp reader has read either @samp{()} or @samp{nil},
|
||||
there is no way to determine which representation was actually written
|
||||
by the programmer.
|
||||
|
||||
In this manual, we use @code{()} when we wish to emphasize that it
|
||||
means the empty list, and we use @code{nil} when we wish to emphasize
|
||||
that it means the truth value @var{false}. That is a good convention to use
|
||||
in Lisp programs also.
|
||||
|
||||
@example
|
||||
(cons 'foo ()) ; @r{Emphasize the empty list}
|
||||
(not nil) ; @r{Emphasize the truth value @var{false}}
|
||||
@end example
|
||||
|
||||
@cindex @code{t} and truth
|
||||
@cindex true
|
||||
In contexts where a truth value is expected, any non-@code{nil} value
|
||||
is considered to be @var{true}. However, @code{t} is the preferred way
|
||||
to represent the truth value @var{true}. When you need to choose a
|
||||
value which represents @var{true}, and there is no other basis for
|
||||
choosing, use @code{t}. The symbol @code{t} always has value @code{t}.
|
||||
|
||||
In Emacs Lisp, @code{nil} and @code{t} are special symbols that always
|
||||
evaluate to themselves. This is so that you do not need to quote them
|
||||
to use them as constants in a program. An attempt to change their
|
||||
values results in a @code{setting-constant} error. @xref{Accessing
|
||||
Variables}.
|
||||
|
||||
@node Evaluation Notation
|
||||
@subsection Evaluation Notation
|
||||
@cindex evaluation notation
|
||||
@cindex documentation notation
|
||||
|
||||
A Lisp expression that you can evaluate is called a @dfn{form}.
|
||||
Evaluating a form always produces a result, which is a Lisp object. In
|
||||
the examples in this manual, this is indicated with @samp{@result{}}:
|
||||
|
||||
@example
|
||||
(car '(1 2))
|
||||
@result{} 1
|
||||
@end example
|
||||
|
||||
@noindent
|
||||
You can read this as ``@code{(car '(1 2))} evaluates to 1''.
|
||||
|
||||
When a form is a macro call, it expands into a new form for Lisp to
|
||||
evaluate. We show the result of the expansion with
|
||||
@samp{@expansion{}}. We may or may not show the actual result of the
|
||||
evaluation of the expanded form.
|
||||
|
||||
@example
|
||||
(third '(a b c))
|
||||
@expansion{} (car (cdr (cdr '(a b c))))
|
||||
@result{} c
|
||||
@end example
|
||||
|
||||
Sometimes to help describe one form we show another form which
|
||||
produces identical results. The exact equivalence of two forms is
|
||||
indicated with @samp{@equiv{}}.
|
||||
|
||||
@example
|
||||
(make-sparse-keymap) @equiv{} (list 'keymap)
|
||||
@end example
|
||||
|
||||
@node Printing Notation
|
||||
@subsection Printing Notation
|
||||
@cindex printing notation
|
||||
|
||||
Many of the examples in this manual print text when they are
|
||||
evaluated. If you execute the code from an example in a Lisp
|
||||
Interaction buffer (such as the buffer @samp{*scratch*}), the printed
|
||||
text is inserted into the buffer. If you execute the example by other
|
||||
means (such as by evaluating the function @code{eval-region}), it prints
|
||||
text by displaying it in the echo area. You should be aware that text
|
||||
displayed in the echo area is truncated to a single line.
|
||||
|
||||
Examples in this manual indicate printed text with @samp{@print{}},
|
||||
irrespective of where that text goes. The value returned by evaluating
|
||||
the form (here @code{bar}) follows on a separate line.
|
||||
|
||||
@example
|
||||
@group
|
||||
(progn (print 'foo) (print 'bar))
|
||||
@print{} foo
|
||||
@print{} bar
|
||||
@result{} bar
|
||||
@end group
|
||||
@end example
|
||||
|
||||
@node Error Messages
|
||||
@subsection Error Messages
|
||||
@cindex error message notation
|
||||
|
||||
Some examples signal errors. This normally displays an error message
|
||||
in the echo area. We show the error message on a line starting with
|
||||
@samp{@error{}}. Note that @samp{@error{}} itself does not appear in
|
||||
the echo area.
|
||||
|
||||
@example
|
||||
(+ 23 'x)
|
||||
@error{} Wrong type argument: integer-or-marker-p, x
|
||||
@end example
|
||||
|
||||
@node Buffer Text Notation
|
||||
@subsection Buffer Text Notation
|
||||
@cindex buffer text notation
|
||||
|
||||
Some examples show modifications to text in a buffer, with ``before''
|
||||
and ``after'' versions of the text. These examples show the contents of
|
||||
the buffer in question between two lines of dashes containing the buffer
|
||||
name. In addition, @samp{@point{}} indicates the location of point.
|
||||
(The symbol for point, of course, is not part of the text in the buffer;
|
||||
it indicates the place @emph{between} two characters where point is
|
||||
located.)
|
||||
|
||||
@example
|
||||
---------- Buffer: foo ----------
|
||||
This is the @point{}contents of foo.
|
||||
---------- Buffer: foo ----------
|
||||
|
||||
(insert "changed ")
|
||||
@result{} nil
|
||||
---------- Buffer: foo ----------
|
||||
This is the changed @point{}contents of foo.
|
||||
---------- Buffer: foo ----------
|
||||
@end example
|
||||
|
||||
@node Format of Descriptions
|
||||
@subsection Format of Descriptions
|
||||
@cindex description format
|
||||
|
||||
Functions, variables, macros, commands, user options, and special
|
||||
forms are described in this manual in a uniform format. The first
|
||||
line of a description contains the name of the item followed by its
|
||||
arguments, if any.
|
||||
@ifinfo
|
||||
The category---function, variable, or whatever---appears at the
|
||||
beginning of the line.
|
||||
@end ifinfo
|
||||
@iftex
|
||||
The category---function, variable, or whatever---is printed next to the
|
||||
right margin.
|
||||
@end iftex
|
||||
The description follows on succeeding lines, sometimes with examples.
|
||||
|
||||
@menu
|
||||
* A Sample Function Description:: A description of an imaginary
|
||||
function, @code{foo}.
|
||||
* A Sample Variable Description:: A description of an imaginary
|
||||
variable,
|
||||
@code{electric-future-map}.
|
||||
@end menu
|
||||
|
||||
@node A Sample Function Description
|
||||
@subsubsection A Sample Function Description
|
||||
@cindex function descriptions
|
||||
@cindex command descriptions
|
||||
@cindex macro descriptions
|
||||
@cindex special form descriptions
|
||||
|
||||
In a function description, the name of the function being described
|
||||
appears first. It is followed on the same line by a list of parameters.
|
||||
The names used for the parameters are also used in the body of the
|
||||
description.
|
||||
|
||||
The appearance of the keyword @code{&optional} in the parameter list
|
||||
indicates that the arguments for subsequent parameters may be omitted
|
||||
(omitted parameters default to @code{nil}). Do not write
|
||||
@code{&optional} when you call the function.
|
||||
|
||||
The keyword @code{&rest} (which will always be followed by a single
|
||||
parameter) indicates that any number of arguments can follow. The value
|
||||
of the single following parameter will be a list of all these arguments.
|
||||
Do not write @code{&rest} when you call the function.
|
||||
|
||||
Here is a description of an imaginary function @code{foo}:
|
||||
|
||||
@defun foo integer1 &optional integer2 &rest integers
|
||||
The function @code{foo} subtracts @var{integer1} from @var{integer2},
|
||||
then adds all the rest of the arguments to the result. If @var{integer2}
|
||||
is not supplied, then the number 19 is used by default.
|
||||
|
||||
@example
|
||||
(foo 1 5 3 9)
|
||||
@result{} 16
|
||||
(foo 5)
|
||||
@result{} 14
|
||||
@end example
|
||||
|
||||
More generally,
|
||||
|
||||
@example
|
||||
(foo @var{w} @var{x} @var{y}@dots{})
|
||||
@equiv{}
|
||||
(+ (- @var{x} @var{w}) @var{y}@dots{})
|
||||
@end example
|
||||
@end defun
|
||||
|
||||
Any parameter whose name contains the name of a type (e.g.,
|
||||
@var{integer}, @var{integer1} or @var{buffer}) is expected to be of that
|
||||
type. A plural of a type (such as @var{buffers}) often means a list of
|
||||
objects of that type. Parameters named @var{object} may be of any type.
|
||||
(@xref{Types of Lisp Object}, for a list of Emacs object types.)
|
||||
Parameters with other sorts of names (e.g., @var{new-file}) are
|
||||
discussed specifically in the description of the function. In some
|
||||
sections, features common to parameters of several functions are
|
||||
described at the beginning.
|
||||
|
||||
@xref{Lambda Expressions}, for a more complete description of optional
|
||||
and rest arguments.
|
||||
|
||||
Command, macro, and special form descriptions have the same format,
|
||||
but the word `Function' is replaced by `Command', `Macro', or `Special
|
||||
Form', respectively. Commands are simply functions that may be called
|
||||
interactively; macros process their arguments differently from functions
|
||||
(the arguments are not evaluated), but are presented the same way.
|
||||
|
||||
Special form descriptions use a more complex notation to specify
|
||||
optional and repeated parameters because they can break the argument
|
||||
list down into separate arguments in more complicated ways.
|
||||
@samp{@code{@r{[}@var{optional-arg}@r{]}}} means that @var{optional-arg} is
|
||||
optional and @samp{@var{repeated-args}@dots{}} stands for zero or more
|
||||
arguments. Parentheses are used when several arguments are grouped into
|
||||
additional levels of list structure. Here is an example:
|
||||
|
||||
@defspec count-loop (@var{var} [@var{from} @var{to} [@var{inc}]]) @var{body}@dots{}
|
||||
This imaginary special form implements a loop that executes the
|
||||
@var{body} forms and then increments the variable @var{var} on each
|
||||
iteration. On the first iteration, the variable has the value
|
||||
@var{from}; on subsequent iterations, it is incremented by 1 (or by
|
||||
@var{inc} if that is given). The loop exits before executing @var{body}
|
||||
if @var{var} equals @var{to}. Here is an example:
|
||||
|
||||
@example
|
||||
(count-loop (i 0 10)
|
||||
(prin1 i) (princ " ")
|
||||
(prin1 (aref vector i)) (terpri))
|
||||
@end example
|
||||
|
||||
If @var{from} and @var{to} are omitted, then @var{var} is bound to
|
||||
@code{nil} before the loop begins, and the loop exits if @var{var} is
|
||||
non-@code{nil} at the beginning of an iteration. Here is an example:
|
||||
|
||||
@example
|
||||
(count-loop (done)
|
||||
(if (pending)
|
||||
(fixit)
|
||||
(setq done t)))
|
||||
@end example
|
||||
|
||||
In this special form, the arguments @var{from} and @var{to} are
|
||||
optional, but must both be present or both absent. If they are present,
|
||||
@var{inc} may optionally be specified as well. These arguments are
|
||||
grouped with the argument @var{var} into a list, to distinguish them
|
||||
from @var{body}, which includes all remaining elements of the form.
|
||||
@end defspec
|
||||
|
||||
@node A Sample Variable Description
|
||||
@subsubsection A Sample Variable Description
|
||||
@cindex variable descriptions
|
||||
@cindex option descriptions
|
||||
|
||||
A @dfn{variable} is a name that can hold a value. Although any
|
||||
variable can be set by the user, certain variables that exist
|
||||
specifically so that users can change them are called @dfn{user
|
||||
options}. Ordinary variables and user options are described using a
|
||||
format like that for functions except that there are no arguments.
|
||||
|
||||
Here is a description of the imaginary @code{electric-future-map}
|
||||
variable.@refill
|
||||
|
||||
@defvar electric-future-map
|
||||
The value of this variable is a full keymap used by Electric Command
|
||||
Future mode. The functions in this map allow you to edit commands you
|
||||
have not yet thought about executing.
|
||||
@end defvar
|
||||
|
||||
User option descriptions have the same format, but `Variable' is
|
||||
replaced by `User Option'.
|
||||
|
||||
@node Acknowledgements
|
||||
@section Acknowledgements
|
||||
|
||||
This manual was written by Robert Krawitz, Bil Lewis, Dan LaLiberte,
|
||||
Richard M. Stallman and Chris Welty, the volunteers of the GNU manual
|
||||
group, in an effort extending over several years. Robert J. Chassell
|
||||
helped to review and edit the manual, with the support of the Defense
|
||||
Advanced Research Projects Agency, ARPA Order 6082, arranged by Warren
|
||||
A. Hunt, Jr. of Computational Logic, Inc.
|
||||
|
||||
Corrections were supplied by Karl Berry, Jim Blandy, Bard Bloom,
|
||||
Stephane Boucher, David Boyes, Alan Carroll, Richard Davis, Lawrence
|
||||
R. Dodd, Peter Doornbosch, David A. Duff, Chris Eich, Beverly
|
||||
Erlebacher, David Eckelkamp, Ralf Fassel, Eirik Fuller, Stephen Gildea,
|
||||
Bob Glickstein, Eric Hanchrow, George Hartzell, Nathan Hess, Masayuki
|
||||
Ida, Dan Jacobson, Jak Kirman, Bob Knighten, Frederick M. Korz, Joe
|
||||
Lammens, Glenn M. Lewis, K. Richard Magill, Brian Marick, Roland
|
||||
McGrath, Skip Montanaro, John Gardiner Myers, Thomas A. Peterson,
|
||||
Francesco Potorti, Friedrich Pukelsheim, Arnold D. Robbins, Raul
|
||||
Rockwell, Per Starback, Shinichirou Sugou, Kimmo Suominen, Edward Tharp,
|
||||
Bill Trost, Rickard Westman, Jean White, Matthew Wilding, Carl Witty,
|
||||
Dale Worley, Rusty Wright, and David D. Zuhn.
|
582
lispref/loading.texi
Normal file
582
lispref/loading.texi
Normal file
|
@ -0,0 +1,582 @@
|
|||
@c -*-texinfo-*-
|
||||
@c This is part of the GNU Emacs Lisp Reference Manual.
|
||||
@c Copyright (C) 1990, 1991, 1992, 1993, 1994 Free Software Foundation, Inc.
|
||||
@c See the file elisp.texi for copying conditions.
|
||||
@setfilename ../info/loading
|
||||
@node Loading, Byte Compilation, Macros, Top
|
||||
@chapter Loading
|
||||
@cindex loading
|
||||
@cindex library
|
||||
@cindex Lisp library
|
||||
|
||||
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.
|
||||
|
||||
The load functions evaluate all the expressions in a file just
|
||||
as the @code{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.
|
||||
|
||||
@cindex top-level form
|
||||
The loaded file must contain Lisp expressions, either as source code
|
||||
or, optionally, as byte-compiled code. Each form in the file is called
|
||||
a @dfn{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 @dfn{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 @code{load} function and others.
|
||||
* Autoload:: Setting up a function to autoload.
|
||||
* Repeated Loading:: Precautions about loading a file twice.
|
||||
* 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.
|
||||
@end menu
|
||||
|
||||
@node How Programs Do Loading
|
||||
@section How Programs Do Loading
|
||||
|
||||
Emacs Lisp has several interfaces for loading. For example,
|
||||
@code{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 (@pxref{Autoload}). @code{require} loads a
|
||||
file if it isn't already loaded (@pxref{Features}). Ultimately, all
|
||||
these facilities call the @code{load} function to do the work.
|
||||
|
||||
@defun 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, @code{load} first looks for a file named
|
||||
@file{@var{filename}.elc}, that is, for a file whose name is
|
||||
@var{filename} with @samp{.elc} appended. If such a file exists, it is
|
||||
loaded. If there is no file by that name, then @code{load} looks for a
|
||||
file names @file{@var{filename}.el}. If that file exists, it is loaded.
|
||||
Finally, if neither of those names is found, @code{load} looks for a
|
||||
file named @var{filename} with nothing appended, and loads it if it
|
||||
exists. (The @code{load} function is not clever about looking at
|
||||
@var{filename}. In the perverse case of a file named @file{foo.el.el},
|
||||
evaluation of @code{(load "foo.el")} will indeed find it.)
|
||||
|
||||
If the optional argument @var{nosuffix} is non-@code{nil}, then the
|
||||
suffixes @samp{.elc} and @samp{.el} are not tried. In this case, you
|
||||
must specify the precise file name you want.
|
||||
|
||||
If @var{filename} is a relative file name, such as @file{foo} or
|
||||
@file{baz/foo.bar}, @code{load} searches for the file using the variable
|
||||
@code{load-path}. It appends @var{filename} to each of the directories
|
||||
listed in @code{load-path}, and loads the first file it finds whose name
|
||||
matches. The current default directory is tried only if it is specified
|
||||
in @code{load-path}, where @code{nil} stands for the default directory.
|
||||
@code{load} tries all three possible suffixes in the first directory in
|
||||
@code{load-path}, then all three suffixes in the second directory, and
|
||||
so on.
|
||||
|
||||
If you get a warning that @file{foo.elc} is older than @file{foo.el}, it
|
||||
means you should consider recompiling @file{foo.el}. @xref{Byte
|
||||
Compilation}.
|
||||
|
||||
Messages like @samp{Loading foo...} and @samp{Loading foo...done} appear
|
||||
in the echo area during loading unless @var{nomessage} is
|
||||
non-@code{nil}.
|
||||
|
||||
@cindex load errors
|
||||
Any unhandled errors while loading a file terminate loading. If the
|
||||
load was done for the sake of @code{autoload}, certain kinds of
|
||||
top-level forms, those which define functions, are undone.
|
||||
|
||||
@kindex file-error
|
||||
If @code{load} can't find the file to load, then normally it signals the
|
||||
error @code{file-error} (with @samp{Cannot open load file
|
||||
@var{filename}}). But if @var{missing-ok} is non-@code{nil}, then
|
||||
@code{load} just returns @code{nil}.
|
||||
|
||||
@code{load} returns @code{t} if the file loads successfully.
|
||||
@end defun
|
||||
|
||||
@ignore
|
||||
@deffn Command load-file filename
|
||||
This function loads the file @var{filename}. If @var{filename} is an
|
||||
absolute file name, then it is loaded. If it is relative, then the
|
||||
current default directory is assumed. @code{load-path} is not used, and
|
||||
suffixes are not appended. Use this function if you wish to specify
|
||||
the file to be loaded exactly.
|
||||
@end deffn
|
||||
|
||||
@deffn Command load-library library
|
||||
This function loads the library named @var{library}. A library is
|
||||
nothing more than a file that may be loaded as described earlier. This
|
||||
function is identical to @code{load}, save that it reads a file name
|
||||
interactively with completion.
|
||||
@end deffn
|
||||
@end ignore
|
||||
|
||||
@defopt load-path
|
||||
@cindex @code{EMACSLOADPATH} environment variable
|
||||
The value of this variable is a list of directories to search when
|
||||
loading files with @code{load}. Each element is a string (which must be
|
||||
a directory name) or @code{nil} (which stands for the current working
|
||||
directory). The value of @code{load-path} is initialized from the
|
||||
environment variable @code{EMACSLOADPATH}, if that exists; otherwise its
|
||||
default value is specified in @file{emacs/src/paths.h} when Emacs is
|
||||
built.
|
||||
|
||||
The syntax of @code{EMACSLOADPATH} is the same as used for @code{PATH};
|
||||
@samp{:} separates directory names, and @samp{.} is used for the current
|
||||
default directory. Here is an example of how to set your
|
||||
@code{EMACSLOADPATH} variable from a @code{csh} @file{.login} file:
|
||||
|
||||
@c This overfull hbox is OK. --rjc 16mar92
|
||||
@smallexample
|
||||
setenv EMACSLOADPATH .:/user/bil/emacs:/usr/lib/emacs/lisp
|
||||
@end smallexample
|
||||
|
||||
Here is how to set it using @code{sh}:
|
||||
|
||||
@smallexample
|
||||
export EMACSLOADPATH
|
||||
EMACSLOADPATH=.:/user/bil/emacs:/usr/local/lib/emacs/lisp
|
||||
@end smallexample
|
||||
|
||||
Here is an example of code you can place in a @file{.emacs} file to add
|
||||
several directories to the front of your default @code{load-path}:
|
||||
|
||||
@smallexample
|
||||
(setq load-path
|
||||
(append (list nil "/user/bil/emacs"
|
||||
"/usr/local/lisplib"
|
||||
(expand-file-name "~/emacs"))
|
||||
load-path))
|
||||
@end smallexample
|
||||
|
||||
@c Wordy to rid us of an overfull hbox. --rjc 15mar92
|
||||
@noindent
|
||||
In this example, the path searches the current working directory first,
|
||||
followed then by the @file{/user/bil/emacs} directory and then by
|
||||
the @file{/usr/local/lisplib} directory,
|
||||
which are then followed by the standard directories for Lisp code.
|
||||
|
||||
The command line options @samp{-l} or @samp{-load} specify Lispa library
|
||||
to load. Since this file might be in the current directory, Emacs 18
|
||||
temporarily adds the current directory to the front of @code{load-path}
|
||||
so the file can be found there. Newer Emacs versions also find such
|
||||
files in the current directory, but without altering @code{load-path}.
|
||||
@end defopt
|
||||
|
||||
@defvar load-in-progress
|
||||
This variable is non-@code{nil} if Emacs is in the process of loading a
|
||||
file, and it is @code{nil} otherwise. This is how @code{defun} and
|
||||
@code{provide} determine whether a load is in progress, so that their
|
||||
effect can be undone if the load fails.
|
||||
@end defvar
|
||||
|
||||
To learn how @code{load} is used to build Emacs, see @ref{Building Emacs}.
|
||||
|
||||
@node Autoload
|
||||
@section Autoload
|
||||
@cindex autoload
|
||||
|
||||
The @dfn{autoload} facility allows you to make a function or macro
|
||||
available but put off loading its actual definition. 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
|
||||
@code{autoload}, and by writing a special ``magic'' comment in the
|
||||
source before the real definition. @code{autoload} is the low-level
|
||||
primitive for autoloading; any Lisp program can call @code{autoload} at
|
||||
any time. Magic comments do nothing on their own; they serve as a guide
|
||||
for the command @code{update-file-autoloads}, which constructs calls to
|
||||
@code{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.
|
||||
|
||||
@defun autoload symbol filename &optional docstring interactive type
|
||||
This function defines the function (or macro) named @var{symbol} so as
|
||||
to load automatically from @var{filename}. The string @var{filename}
|
||||
specifies the file to load to get the real definition of @var{function}.
|
||||
|
||||
The argument @var{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 @code{autoload} makes it possible to look at the
|
||||
documentation without loading the function's real definition.
|
||||
|
||||
If @var{interactive} is non-@code{nil}, then the function can be called
|
||||
interactively. This lets completion in @kbd{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
|
||||
@var{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 @var{type} as @code{macro} if @var{function} is really a macro.
|
||||
Specify @var{type} as @code{keymap} if @var{function} is really a
|
||||
keymap. Various parts of Emacs need to know this information without
|
||||
loading the real definition.
|
||||
|
||||
@cindex function cell in autoload
|
||||
If @var{symbol} already has a non-void function definition that is not
|
||||
an autoload object, @code{autoload} does nothing and returns @code{nil}.
|
||||
If the function cell of @var{symbol} is void, or is already an autoload
|
||||
object, then it is defined as an autoload object like this:
|
||||
|
||||
@example
|
||||
(autoload @var{filename} @var{docstring} @var{interactive} @var{type})
|
||||
@end example
|
||||
|
||||
For example,
|
||||
|
||||
@example
|
||||
(symbol-function 'run-prolog)
|
||||
@result{} (autoload "prolog" 169681 t nil)
|
||||
@end example
|
||||
|
||||
@noindent
|
||||
In this case, @code{"prolog"} is the name of the file to load, 169681
|
||||
refers to the documentation string in the @file{emacs/etc/DOC} file
|
||||
(@pxref{Documentation Basics}), @code{t} means the function is
|
||||
interactive, and @code{nil} that it is not a macro or a keymap.
|
||||
@end defun
|
||||
|
||||
@cindex autoload errors
|
||||
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 @code{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.
|
||||
|
||||
If the autoloaded file fails to define the desired Lisp function or
|
||||
macro, then an error is signaled with data @code{"Autoloading failed to
|
||||
define function @var{function-name}"}.
|
||||
|
||||
@findex update-file-autoloads
|
||||
@findex update-directory-autoloads
|
||||
A magic autoload comment looks like @samp{;;;###autoload}, on a line
|
||||
by itself, just before the real definition of the function in its
|
||||
autoloadable source file. The command @kbd{M-x update-file-autoloads}
|
||||
writes a corresponding @code{autoload} call into @file{loaddefs.el}.
|
||||
Building Emacs loads @file{loaddefs.el} and thus calls @code{autoload}.
|
||||
@kbd{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
|
||||
@file{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 executing it when the file
|
||||
itself is loaded. To do this, write the form @dfn{on the same line} as
|
||||
the magic comment. Since it is in a comment, it does nothing when you
|
||||
load the source file; but @code{update-file-autoloads} copies it to
|
||||
@file{loaddefs.el}, where it is executed while building Emacs.
|
||||
|
||||
The following example shows how @code{doctor} is prepared for
|
||||
autoloading with a magic comment:
|
||||
|
||||
@smallexample
|
||||
;;;###autoload
|
||||
(defun doctor ()
|
||||
"Switch to *doctor* buffer and start giving psychotherapy."
|
||||
(interactive)
|
||||
(switch-to-buffer "*doctor*")
|
||||
(doctor-mode))
|
||||
@end smallexample
|
||||
|
||||
@noindent
|
||||
Here's what that produces in @file{loaddefs.el}:
|
||||
|
||||
@smallexample
|
||||
(autoload 'doctor "doctor"
|
||||
"\
|
||||
Switch to *doctor* buffer and start giving psychotherapy."
|
||||
t)
|
||||
@end smallexample
|
||||
|
||||
@noindent
|
||||
The backslash and newline immediately following the double-quote are a
|
||||
convention used only in the preloaded Lisp files such as
|
||||
@file{loaddefs.el}; they tell @code{make-docfile} to put the
|
||||
documentation string in the @file{etc/DOC} file. @xref{Building Emacs}.
|
||||
|
||||
@node Repeated Loading
|
||||
@comment node-name, next, previous, up
|
||||
@section Repeated Loading
|
||||
@cindex 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 @code{load} and
|
||||
@code{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
|
||||
@code{defvar} vs.@: @code{defconst} for defining a variable depends on
|
||||
whether it is desirable to reinitialize the variable if the library is
|
||||
reloaded: @code{defconst} does so, and @code{defvar} does not.
|
||||
(@xref{Defining Variables}.)
|
||||
|
||||
The simplest way to add an element to an alist is like this:
|
||||
|
||||
@example
|
||||
(setq minor-mode-alist
|
||||
(cons '(leif-mode " Leif") minor-mode-alist))
|
||||
@end example
|
||||
|
||||
@noindent
|
||||
But this would add multiple elements if the library is reloaded.
|
||||
To avoid the problem, write this:
|
||||
|
||||
@example
|
||||
(or (assq 'leif-mode minor-mode-alist)
|
||||
(setq minor-mode-alist
|
||||
(cons '(leif-mode " Leif") minor-mode-alist)))
|
||||
@end example
|
||||
|
||||
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:
|
||||
|
||||
@example
|
||||
(if (not (boundp 'foo-was-loaded))
|
||||
@var{execute-first-time-only})
|
||||
|
||||
(setq foo-was-loaded t)
|
||||
@end example
|
||||
|
||||
@noindent
|
||||
If the library uses @code{provide} to provide a named feature, you can
|
||||
use @code{featurep} to test whether the library has been loaded.
|
||||
@xref{Features}.
|
||||
|
||||
@node Features
|
||||
@section Features
|
||||
@cindex features
|
||||
@cindex requiring features
|
||||
@cindex providing features
|
||||
|
||||
@code{provide} and @code{require} are an alternative to
|
||||
@code{autoload} for loading files automatically. They work in terms of
|
||||
named @dfn{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 @dfn{provide} the
|
||||
feature. Another program that uses them may ensure they are defined by
|
||||
@dfn{requiring} the feature. This loads the file of definitions if it
|
||||
hasn't been loaded already.
|
||||
|
||||
To require the presence of a feature, call @code{require} with the
|
||||
feature name as argument. @code{require} looks in the global variable
|
||||
@code{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 @code{provide} at the top-level to add the feature to
|
||||
@code{features}; if it fails to do so, @code{require} signals an error.
|
||||
@cindex load error with require
|
||||
|
||||
Features are normally named after the files that provide them, so that
|
||||
@code{require} need not be given the file name.
|
||||
|
||||
For example, in @file{emacs/lisp/prolog.el},
|
||||
the definition for @code{run-prolog} includes the following code:
|
||||
|
||||
@smallexample
|
||||
(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))
|
||||
@end smallexample
|
||||
|
||||
@noindent
|
||||
The expression @code{(require 'comint)} loads the file @file{comint.el}
|
||||
if it has not yet been loaded. This ensures that @code{make-comint} is
|
||||
defined.
|
||||
|
||||
The @file{comint.el} file contains the following top-level expression:
|
||||
|
||||
@smallexample
|
||||
(provide 'comint)
|
||||
@end smallexample
|
||||
|
||||
@noindent
|
||||
This adds @code{comint} to the global @code{features} list, so that
|
||||
@code{(require 'comint)} will henceforth know that nothing needs to be
|
||||
done.
|
||||
|
||||
@cindex byte-compiling @code{require}
|
||||
When @code{require} is used at top-level in a file, it takes effect
|
||||
when you byte-compile that file (@pxref{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 @code{require} are evaluated during
|
||||
byte compilation, @code{provide} calls are not. Therefore, you can
|
||||
ensure that a file of definitions is loaded before it is byte-compiled
|
||||
by including a @code{provide} followed by a @code{require} for the same
|
||||
feature, as in the following example.
|
||||
|
||||
@smallexample
|
||||
@group
|
||||
(provide 'my-feature) ; @r{Ignored by byte compiler,}
|
||||
; @r{evaluated by @code{load}.}
|
||||
(require 'my-feature) ; @r{Evaluated by byte compiler.}
|
||||
@end group
|
||||
@end smallexample
|
||||
|
||||
@defun provide feature
|
||||
This function announces that @var{feature} is now loaded, or being
|
||||
loaded, into the current Emacs session. This means that the facilities
|
||||
associated with @var{feature} are or will be available for other Lisp
|
||||
programs.
|
||||
|
||||
The direct effect of calling @code{provide} is to add @var{feature} to
|
||||
the front of the list @code{features} if it is not already in the list.
|
||||
The argument @var{feature} must be a symbol. @code{provide} returns
|
||||
@var{feature}.
|
||||
|
||||
@smallexample
|
||||
features
|
||||
@result{} (bar bish)
|
||||
|
||||
(provide 'foo)
|
||||
@result{} foo
|
||||
features
|
||||
@result{} (foo bar bish)
|
||||
@end smallexample
|
||||
|
||||
If the file isn't completely loaded, due to an error in the evaluating
|
||||
its contents, any function definitions or @code{provide} calls that
|
||||
occurred during the load are undone. @xref{Autoload}.
|
||||
@end defun
|
||||
|
||||
@defun require feature &optional filename
|
||||
This function checks whether @var{feature} is present in the current
|
||||
Emacs session (using @code{(featurep @var{feature})}; see below). If it
|
||||
is not, then @code{require} loads @var{filename} with @code{load}. If
|
||||
@var{filename} is not supplied, then the name of the symbol
|
||||
@var{feature} is used as the file name to load.
|
||||
|
||||
If loading the file fails to provide @var{feature}, @code{require}
|
||||
signals an error, @samp{Required feature @var{feature} was not
|
||||
provided}.
|
||||
@end defun
|
||||
|
||||
@defun featurep feature
|
||||
This function returns @code{t} if @var{feature} has been provided in the
|
||||
current Emacs session (i.e., @var{feature} is a member of
|
||||
@code{features}.)
|
||||
@end defun
|
||||
|
||||
@defvar 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 @code{provide}. The order of the elements in the
|
||||
@code{features} list is not significant.
|
||||
@end defvar
|
||||
|
||||
@node Unloading
|
||||
@section Unloading
|
||||
@cindex unloading
|
||||
|
||||
@c Emacs 19 feature
|
||||
You can discard the functions and variables loaded by a library to
|
||||
reclaim memory for other Lisp objects. To do this, use the function
|
||||
@code{unload-feature}:
|
||||
|
||||
@deffn Command unload-feature feature
|
||||
This command unloads the library that provided feature @var{feature}.
|
||||
It undefines all functions and variables defined with @code{defvar},
|
||||
@code{defmacro}, @code{defconst}, @code{defsubst} and @code{defalias} by
|
||||
that library. It then restores any autoloads associated with those
|
||||
symbols.
|
||||
@end deffn
|
||||
|
||||
The @code{unload-feature} function is written in Lisp; its actions are
|
||||
based on the variable @code{load-history}.
|
||||
|
||||
@defvar 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 @sc{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:
|
||||
|
||||
@itemize @bullet
|
||||
@item
|
||||
Symbols, which were defined as functions or variables.
|
||||
@item
|
||||
Lists of the form @code{(require . @var{feature})} indicating
|
||||
features that were required.
|
||||
@item
|
||||
Lists of the form @code{(provide . @var{feature})} indicating
|
||||
features that were provided.
|
||||
@end itemize
|
||||
|
||||
The value of @code{load-history} may have one element whose @sc{car} is
|
||||
@code{nil}. This element describes definitions made with
|
||||
@code{eval-buffer} on a buffer that is not visiting a file.
|
||||
@end defvar
|
||||
|
||||
The command @code{eval-region} updates @code{load-history}, but does so
|
||||
by adding the symbols defined to the element for the file being visited,
|
||||
rather than replacing that element.
|
||||
|
||||
@node Hooks for Loading
|
||||
@section Hooks for Loading
|
||||
@cindex loading hooks
|
||||
@cindex hooks for loading
|
||||
|
||||
You can ask for code to be executed if and when a particular library is
|
||||
loaded, by calling @code{eval-after-load}.
|
||||
|
||||
@defun eval-after-load library form
|
||||
This function arranges to evaluate @var{form} at the end of loading the
|
||||
library @var{library}, if and when @var{library} is loaded.
|
||||
|
||||
The library name @var{library} must exactly match the argument of
|
||||
@code{load}. To get the proper results when an installed library is
|
||||
found by searching @code{load-path}, you should not include any
|
||||
directory names in @var{library}.
|
||||
|
||||
An error in @var{form} does not undo the load, but does prevent
|
||||
execution of the rest of @var{form}.
|
||||
@end defun
|
||||
|
||||
@defvar after-load-alist
|
||||
An alist of expressions to evaluate if and when particular libraries are
|
||||
loaded. Each element looks like this:
|
||||
|
||||
@example
|
||||
(@var{filename} @var{forms}@dots{})
|
||||
@end example
|
||||
|
||||
The function @code{load} checks @code{after-load-alist} in order to
|
||||
implement @code{eval-after-load}.
|
||||
@end defvar
|
||||
|
||||
@c Emacs 19 feature
|
Loading…
Add table
Add a link
Reference in a new issue