@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 Introduction, Lisp Data Types, Top, Top@comment node-name, next, previous, up@chapter Introduction Most of the GNU Emacs text editor is written in the programminglanguage called Emacs Lisp. You can write new code in Emacs Lisp andinstall it as an extension to the editor. However, Emacs Lisp is morethan a mere ``extension language''; it is a full computer programminglanguage in its own right. You can use it as you would any otherprogramming language. Because Emacs Lisp is designed for use in an editor, it has specialfeatures for scanning and parsing text as well as features for handlingfiles, buffers, displays, subprocesses, and so on. Emacs Lisp isclosely integrated with the editing facilities; thus, editing commandsare functions that can also conveniently be called from Lisp programs,and parameters for customization are ordinary Lisp variables. This manual attempts to be a full description of Emacs Lisp. For abeginner's introduction to Emacs Lisp, see @cite{An Introduction toEmacs Lisp Programming}, by Bob Chassell, also published by the FreeSoftware Foundation. This manual presumes considerable familiarity withthe use of Emacs for editing; see @cite{The GNU Emacs Manual} for thisbasic information. Generally speaking, the earlier chapters describe features of EmacsLisp that have counterparts in many programming languages, and laterchapters describe features that are peculiar to Emacs Lisp or relatespecifically to editing. This is edition 2.6.@menu* Caveats:: Flaws and a request for help.* Lisp History:: Emacs Lisp is descended from Maclisp.* Conventions:: How the manual is formatted.* Version Info:: Which Emacs version is running?* 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 completebut not flawless. There are a few topics that are not covered, eitherbecause we consider them secondary (such as most of the individualmodes) or because they are yet to be written. Because we are not ableto deal with them completely, we have left out several partsintentionally. This includes most information about usage on VMS. The manual should be fully correct in what it does cover, and it istherefore open to criticism on anything it says---from specific examplesand descriptive text, to the ordering of chapters and sections. Ifsomething is confusing, or you find that you have to look at the sourcesor experiment to learn something not covered in the manual, then perhapsthe manual should be fixed. Please let us know.@iftex As you use this manual, we ask that you mark pages with corrections soyou can later look them up and send them to us. If you think of a simple,real-life example for a function or group of functions, please make aneffort to write it up and send it in. Please reference any comments tothe chapter name, section name, and function name, as appropriate, sincepage numbers and chapter and section numbers will change and we may havetrouble finding the text you are talking about. Also state the numberof the edition you are criticizing.@end iftex@ifnottexAs you use this manual, we ask that you send corrections as soon as youfind them. If you think of a simple, real life example for a functionor group of functions, please make an effort to write it up and send itin. Please reference any comments to the node name and function orvariable name, as appropriate. Also state the number of the editionyou are criticizing.@end ifnottexPlease mail comments and corrections to@examplebug-lisp-manual@@gnu.org@end example@noindentWe let mail to this list accumulate unread until someone decides toapply the corrections. Months, and sometimes years, go by betweenupdates. So please attach no significance to the lack of a reply---yourmail @emph{will} be acted on in due time. If you want to contact theEmacs maintainers more quickly, send mail to@code{bug-gnu-emacs@@gnu.org}.@node Lisp History@section Lisp History@cindex Lisp history Lisp (LISt Processing language) was first developed in the late 1950sat the Massachusetts Institute of Technology for research in artificialintelligence. The great power of the Lisp language makes it idealfor other purposes as well, such as writing editing commands.@cindex Maclisp@cindex Common Lisp Dozens of Lisp implementations have been built over the years, eachwith its own idiosyncrasies. Many of them were inspired by Maclisp,which was written in the 1960s at MIT's Project MAC. Eventually theimplementors of the descendants of Maclisp came together and developed astandard for Lisp systems, called Common Lisp. In the meantime, GerrySussman and Guy Steele at MIT developed a simplified but very powerfuldialect of Lisp, called Scheme. GNU Emacs Lisp is largely inspired by Maclisp, and a little by CommonLisp. If you know Common Lisp, you will notice many similarities.However, many features of Common Lisp have been omitted orsimplified in order to reduce the memory requirements of GNU Emacs.Sometimes the simplifications are so drastic that a Common Lisp usermight be very confused. We will occasionally point out how GNU EmacsLisp differs from Common Lisp. If you don't know Common Lisp, don'tworry about it; this manual is self-contained.@pindex cl A certain amount of Common Lisp emulation is available via the@file{cl} library. @xref{Top,, Common Lisp Extension, cl, Common LispExtensions}. Emacs Lisp is not at all influenced by Scheme; but the GNU project hasan implementation of Scheme, called Guile. We use Guile in all new GNUsoftware that calls for extensibility.@node Conventions@section ConventionsThis section explains the notational conventions that are used in thismanual. 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 when examples print text.* 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 Lispprinter'' refer to those routines in Lisp that convert textualrepresentations of Lisp objects into actual Lisp objects, and viceversa. @xref{Printed Representation}, for more details. You, theperson reading this manual, are thought of as ``the programmer'' and areaddressed as ``you''. ``The user'' is the person who uses Lispprograms, including those you write.@cindex fonts Examples of Lisp code are formatted like this: @code{(list 1 2 3)}.Names that represent metasyntactic variables, or arguments to a functionbeing described, are formatted like this: @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} has three separate meanings: itis 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} areidentical: they stand for the same object, the symbol @code{nil}. Thedifferent ways of writing the symbol are intended entirely for humanreaders. After the Lisp reader has read either @samp{()} or @samp{nil},there is no way to determine which representation was actually writtenby the programmer. In this manual, we use @code{()} when we wish to emphasize that itmeans the empty list, and we use @code{nil} when we wish to emphasizethat it means the truth value @var{false}. That is a good convention to usein 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} valueis considered to be @var{true}. However, @code{t} is the preferred wayto represent the truth value @var{true}. When you need to choose avalue which represents @var{true}, and there is no other basis forchoosing, use @code{t}. The symbol @code{t} always has the value@code{t}. In Emacs Lisp, @code{nil} and @code{t} are special symbols that alwaysevaluate to themselves. This is so that you do not need to quote themto use them as constants in a program. An attempt to change theirvalues results in a @code{setting-constant} error. The same is true ofany symbol whose name starts with a colon (@samp{:}). @xref{ConstantVariables}.@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. Inthe examples in this manual, this is indicated with @samp{@result{}}:@example(car '(1 2)) @result{} 1@end example@noindentYou 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 toevaluate. We show the result of the expansion with@samp{@expansion{}}. We may or may not show the result of theevaluation 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 thatproduces identical results. The exact equivalence of two forms isindicated 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 areevaluated. If you execute example code in a Lisp Interaction buffer(such as the buffer @samp{*scratch*}), the printed text is inserted intothe buffer. If you execute the example by other means (such as byevaluating the function @code{eval-region}), the printed text isdisplayed in the echo area. Examples in this manual indicate printed text with @samp{@print{}},irrespective of where that text goes. The value returned by evaluatingthe 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 messagein the echo area. We show the error message on a line starting with@samp{@error{}}. Note that @samp{@error{}} itself does not appear inthe echo area.@example(+ 23 'x)@error{} Wrong type argument: number-or-marker-p, x@end example@node Buffer Text Notation@subsection Buffer Text Notation@cindex buffer text notation Some examples describe modifications to the contents of a buffer, byshowing the ``before'' and ``after'' versions of the text. Theseexamples show the contents of the buffer in question between two linesof dashes containing the buffer name. In addition, @samp{@point{}}indicates the location of point. (The symbol for point, of course, isnot part of the text in the buffer; it indicates the place@emph{between} two characters where point is currently 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 specialforms are described in this manual in a uniform format. The firstline of a description contains the name of the item followed by itsarguments, if any.@ifnottexThe category---function, variable, or whatever---appears at thebeginning of the line.@end ifnottex@iftexThe category---function, variable, or whatever---is printed next to theright margin.@end iftexThe 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 describedappears first. It is followed on the same line by a list of argumentnames. These names are also used in the body of the description, tostand for the values of the arguments. The appearance of the keyword @code{&optional} in the argument listindicates that the subsequent arguments may be omitted (omittedarguments default to @code{nil}). Do not write @code{&optional} whenyou call the function. The keyword @code{&rest} (which must be followed by a single argumentname) indicates that any number of arguments can follow. The singlefollowing argument name will have a value, as a variable, which is alist of all these remaining arguments. Do not write @code{&rest} whenyou call the function. Here is a description of an imaginary function @code{foo}:@defun foo integer1 &optional integer2 &rest integersThe 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@need 1500More generally,@example(foo @var{w} @var{x} @var{y}@dots{})@equiv{}(+ (- @var{x} @var{w}) @var{y}@dots{})@end example@end defun Any argument whose name contains the name of a type (e.g.,@var{integer}, @var{integer1} or @var{buffer}) is expected to be of thattype. A plural of a type (such as @var{buffers}) often means a list ofobjects of that type. Arguments named @var{object} may be of any type.(@xref{Lisp Data Types}, for a list of Emacs object types.) Argumentswith other sorts of names (e.g., @var{new-file}) are discussedspecifically in the description of the function. In some sections,features common to the arguments of several functions are described atthe beginning. @xref{Lambda Expressions}, for a more complete description of optionaland rest arguments. Command, macro, and special form descriptions have the same format,but the word `Function' is replaced by `Command', `Macro', or `SpecialForm', respectively. Commands are simply functions that may be calledinteractively; 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 specifyoptional and repeated arguments because they can break the argumentlist down into separate arguments in more complicated ways.@samp{@r{[}@var{optional-arg}@r{]}} means that @var{optional-arg} isoptional and @samp{@var{repeated-args}@dots{}} stands for zero or morearguments. Parentheses are used when several arguments are grouped intoadditional 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 eachiteration. On the first iteration, the variable has the value@var{from}; on subsequent iterations, it is incremented by one (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 exampleIf @var{from} and @var{to} are omitted, @var{var} is bound to@code{nil} before the loop begins, and the loop exits if @var{var} isnon-@code{nil} at the beginning of an iteration. Here is an example:@example(count-loop (done) (if (pending) (fixit) (setq done t)))@end exampleIn this special form, the arguments @var{from} and @var{to} areoptional, but must both be present or both absent. If they are present,@var{inc} may optionally be specified as well. These arguments aregrouped with the argument @var{var} into a list, to distinguish themfrom @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 anyvariable can be set by the user, certain variables that existspecifically so that users can change them are called @dfn{useroptions}. Ordinary variables and user options are described using aformat 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-mapThe value of this variable is a full keymap used by Electric CommandFuture mode. The functions in this map allow you to edit commands youhave not yet thought about executing.@end defvar User option descriptions have the same format, but `Variable' isreplaced by `User Option'.@node Version Info@section Version Information These facilities provide information about which version of Emacs isin use.@deffn Command emacs-versionThis function returns a string describing the version of Emacs that isrunning. It is useful to include this string in bug reports.@smallexample@group(emacs-version) @result{} "GNU Emacs 20.3.5 (i486-pc-linux-gnulibc1, X toolkit) of Sat Feb 14 1998 on psilocin.gnu.org"@end group@end smallexampleCalled interactively, the function prints the same information in theecho area.@end deffn@defvar emacs-build-timeThe value of this variable indicates the time at which Emacs was builtat the local site. It is a list of three integers, like the valueof @code{current-time} (@pxref{Time of Day}).@example@groupemacs-build-time @result{} (13623 62065 344633)@end group@end example@end defvar@defvar emacs-versionThe value of this variable is the version of Emacs being run. It is astring such as @code{"20.3.1"}. The last number in this string is notreally part of the Emacs release version number; it is incremented eachtime you build Emacs in any given directory. A value with three numericcomponents, such as @code{"20.3.9.1"}, indicates an unreleased testversion.@end defvar The following two variables have existed since Emacs version 19.23:@defvar emacs-major-versionThe major version number of Emacs, as an integer. For Emacs version20.3, the value is 20.@end defvar@defvar emacs-minor-versionThe minor version number of Emacs, as an integer. For Emacs version20.3, the value is 3.@end defvar@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 manualgroup, in an effort extending over several years. Robert J. Chassellhelped to review and edit the manual, with the support of the DefenseAdvanced Research Projects Agency, ARPA Order 6082, arranged by WarrenA. Hunt, Jr.@: of Computational Logic, Inc. Corrections were supplied by Karl Berry, Jim Blandy, Bard Bloom,Stephane Boucher, David Boyes, Alan Carroll, Richard Davis, LawrenceR. Dodd, Peter Doornbosch, David A. Duff, Chris Eich, BeverlyErlebacher, David Eckelkamp, Ralf Fassel, Eirik Fuller, Stephen Gildea,Bob Glickstein, Eric Hanchrow, George Hartzell, Nathan Hess, MasayukiIda, Dan Jacobson, Jak Kirman, Bob Knighten, Frederick M. Korz, JoeLammens, Glenn M. Lewis, K. Richard Magill, Brian Marick, RolandMcGrath, Skip Montanaro, John Gardiner Myers, Thomas A. Peterson,Francesco Potorti, Friedrich Pukelsheim, Arnold D. Robbins, RaulRockwell, Per Starb@"ack, Shinichirou Sugou, Kimmo Suominen, Edward Tharp,Bill Trost, Rickard Westman, Jean White, Matthew Wilding, Carl Witty,Dale Worley, Rusty Wright, and David D. Zuhn.