*** empty log message ***
[emacs.git] / lispref / intro.texi
blobfd383d3a647754c4cddde0c3abd513281bc381b2
1 @c -*-texinfo-*-
2 @c This is part of the GNU Emacs Lisp Reference Manual.
3 @c Copyright (C) 1990, 1991, 1992, 1993, 1994 Free Software Foundation, Inc. 
4 @c See the file elisp.texi for copying conditions.
5 @setfilename ../info/intro
7 @node Introduction, Lisp Data Types, Top, Top
8 @comment  node-name,  next,  previous,  up
9 @chapter Introduction
11   Most of the GNU Emacs text editor is written in the programming
12 language called Emacs Lisp.  You can write new code in Emacs Lisp and
13 install it as an extension to the editor.  However, Emacs Lisp is more
14 than a mere ``extension language''; it is a full computer programming
15 language in its own right.  You can use it as you would any other
16 programming language.
18   Because Emacs Lisp is designed for use in an editor, it has special
19 features for scanning and parsing text as well as features for handling
20 files, buffers, displays, subprocesses, and so on.  Emacs Lisp is
21 closely integrated with the editing facilities; thus, editing commands
22 are functions that can also conveniently be called from Lisp programs,
23 and parameters for customization are ordinary Lisp variables.
25   This manual attempts to be a full description of Emacs Lisp.  For a
26 beginner's introduction to Emacs Lisp, see @cite{An Introduction to
27 Emacs Lisp Programming}, by Bob Chassell, also published by the Free
28 Software Foundation.  This manual presumes considerable familiarity with
29 the use of Emacs for editing; see @cite{The GNU Emacs Manual} for this
30 basic information.
32   Generally speaking, the earlier chapters describe features of Emacs
33 Lisp that have counterparts in many programming languages, and later
34 chapters describe features that are peculiar to Emacs Lisp or relate
35 specifically to editing.
37   This is edition 2.6.
39 @menu
40 * Caveats::             Flaws and a request for help.
41 * Lisp History::        Emacs Lisp is descended from Maclisp.
42 * Conventions::         How the manual is formatted.
43 * Version Info::        Which Emacs version is running?
44 * Acknowledgements::    The authors, editors, and sponsors of this manual.
45 @end menu
47 @node Caveats
48 @section Caveats
50   This manual has gone through numerous drafts.  It is nearly complete
51 but not flawless.  There are a few topics that are not covered, either
52 because we consider them secondary (such as most of the individual
53 modes) or because they are yet to be written.  Because we are not able
54 to deal with them completely, we have left out several parts
55 intentionally.  This includes most information about usage on VMS.
57   The manual should be fully correct in what it does cover, and it is
58 therefore open to criticism on anything it says---from specific examples
59 and descriptive text, to the ordering of chapters and sections.  If
60 something is confusing, or you find that you have to look at the sources
61 or experiment to learn something not covered in the manual, then perhaps
62 the manual should be fixed.  Please let us know.
64 @iftex
65   As you use this manual, we ask that you mark pages with corrections so
66 you can later look them up and send them to us.  If you think of a simple,
67 real-life example for a function or group of functions, please make an
68 effort to write it up and send it in.  Please reference any comments to
69 the chapter name, section name, and function name, as appropriate, since
70 page numbers and chapter and section numbers will change and we may have
71 trouble finding the text you are talking about.  Also state the number
72 of the edition you are criticizing.
73 @end iftex
74 @ifnottex
76 As you use this manual, we ask that you send corrections as soon as you
77 find them.  If you think of a simple, real life example for a function
78 or group of functions, please make an effort to write it up and send it
79 in.  Please reference any comments to the node name and function or
80 variable name, as appropriate.  Also state the number of the edition
81 you are criticizing.
82 @end ifnottex
84 Please mail comments and corrections to
86 @example
87 bug-lisp-manual@@gnu.org
88 @end example
90 @noindent
91 We let mail to this list accumulate unread until someone decides to
92 apply the corrections.  Months, and sometimes years, go by between
93 updates.  So please attach no significance to the lack of a reply---your
94 mail @emph{will} be acted on in due time.  If you want to contact the
95 Emacs maintainers more quickly, send mail to
96 @code{bug-gnu-emacs@@gnu.org}.
98 @node Lisp History
99 @section Lisp History
100 @cindex Lisp history
102   Lisp (LISt Processing language) was first developed in the late 1950s
103 at the Massachusetts Institute of Technology for research in artificial
104 intelligence.  The great power of the Lisp language makes it ideal
105 for other purposes as well, such as writing editing commands.
107 @cindex Maclisp
108 @cindex Common Lisp
109   Dozens of Lisp implementations have been built over the years, each
110 with its own idiosyncrasies.  Many of them were inspired by Maclisp,
111 which was written in the 1960s at MIT's Project MAC.  Eventually the
112 implementors of the descendants of Maclisp came together and developed a
113 standard for Lisp systems, called Common Lisp.  In the meantime, Gerry
114 Sussman and Guy Steele at MIT developed a simplified but very powerful
115 dialect of Lisp, called Scheme.
117   GNU Emacs Lisp is largely inspired by Maclisp, and a little by Common
118 Lisp.  If you know Common Lisp, you will notice many similarities.
119 However, many features of Common Lisp have been omitted or
120 simplified in order to reduce the memory requirements of GNU Emacs.
121 Sometimes the simplifications are so drastic that a Common Lisp user
122 might be very confused.  We will occasionally point out how GNU Emacs
123 Lisp differs from Common Lisp.  If you don't know Common Lisp, don't
124 worry about it; this manual is self-contained.
126 @pindex cl
127   A certain amount of Common Lisp emulation is available via the
128 @file{cl} library.  @xref{Top,, Common Lisp Extension, cl, Common Lisp
129 Extensions}.
131   Emacs Lisp is not at all influenced by Scheme; but the GNU project has
132 an implementation of Scheme, called Guile.  We use Guile in all new GNU
133 software that calls for extensibility.
135 @node Conventions
136 @section Conventions
138 This section explains the notational conventions that are used in this
139 manual.  You may want to skip this section and refer back to it later.
141 @menu
142 * Some Terms::               Explanation of terms we use in this manual.
143 * nil and t::                How the symbols @code{nil} and @code{t} are used.
144 * Evaluation Notation::      The format we use for examples of evaluation.
145 * Printing Notation::        The format we use when examples print text.
146 * Error Messages::           The format we use for examples of errors.
147 * Buffer Text Notation::     The format we use for buffer contents in examples.
148 * Format of Descriptions::   Notation for describing functions, variables, etc.
149 @end menu
151 @node Some Terms
152 @subsection Some Terms
154   Throughout this manual, the phrases ``the Lisp reader'' and ``the Lisp
155 printer'' refer to those routines in Lisp that convert textual
156 representations of Lisp objects into actual Lisp objects, and vice
157 versa.  @xref{Printed Representation}, for more details.  You, the
158 person reading this manual, are thought of as ``the programmer'' and are
159 addressed as ``you''.  ``The user'' is the person who uses Lisp
160 programs, including those you write.
162 @cindex fonts
163   Examples of Lisp code are formatted like this: @code{(list 1 2 3)}.
164 Names that represent metasyntactic variables, or arguments to a function
165 being described, are formatted like this: @var{first-number}.
167 @node nil and t
168 @subsection @code{nil} and @code{t}
169 @cindex @code{nil}, uses of
170 @cindex truth value
171 @cindex boolean
172 @cindex false
174   In Lisp, the symbol @code{nil} has three separate meanings: it
175 is a symbol with the name @samp{nil}; it is the logical truth value
176 @var{false}; and it is the empty list---the list of zero elements.
177 When used as a variable, @code{nil} always has the value @code{nil}.
179   As far as the Lisp reader is concerned, @samp{()} and @samp{nil} are
180 identical: they stand for the same object, the symbol @code{nil}.  The
181 different ways of writing the symbol are intended entirely for human
182 readers.  After the Lisp reader has read either @samp{()} or @samp{nil},
183 there is no way to determine which representation was actually written
184 by the programmer.
186   In this manual, we use @code{()} when we wish to emphasize that it
187 means the empty list, and we use @code{nil} when we wish to emphasize
188 that it means the truth value @var{false}.  That is a good convention to use
189 in Lisp programs also.
191 @example
192 (cons 'foo ())                ; @r{Emphasize the empty list}
193 (not nil)                     ; @r{Emphasize the truth value @var{false}}
194 @end example
196 @cindex @code{t} and truth
197 @cindex true
198   In contexts where a truth value is expected, any non-@code{nil} value
199 is considered to be @var{true}.  However, @code{t} is the preferred way
200 to represent the truth value @var{true}.  When you need to choose a
201 value which represents @var{true}, and there is no other basis for
202 choosing, use @code{t}.  The symbol @code{t} always has the value
203 @code{t}.
205   In Emacs Lisp, @code{nil} and @code{t} are special symbols that always
206 evaluate to themselves.  This is so that you do not need to quote them
207 to use them as constants in a program.  An attempt to change their
208 values results in a @code{setting-constant} error.  The same is true of
209 any symbol whose name starts with a colon (@samp{:}).  @xref{Constant
210 Variables}.
212 @node Evaluation Notation
213 @subsection Evaluation Notation
214 @cindex evaluation notation
215 @cindex documentation notation
217   A Lisp expression that you can evaluate is called a @dfn{form}.
218 Evaluating a form always produces a result, which is a Lisp object.  In
219 the examples in this manual, this is indicated with @samp{@result{}}:
221 @example
222 (car '(1 2))
223      @result{} 1
224 @end example
226 @noindent
227 You can read this as ``@code{(car '(1 2))} evaluates to 1''.
229   When a form is a macro call, it expands into a new form for Lisp to
230 evaluate.  We show the result of the expansion with
231 @samp{@expansion{}}.  We may or may not show the result of the
232 evaluation of the expanded form.
234 @example
235 (third '(a b c))
236      @expansion{} (car (cdr (cdr '(a b c))))
237      @result{} c
238 @end example
240   Sometimes to help describe one form we show another form that
241 produces identical results.  The exact equivalence of two forms is
242 indicated with @samp{@equiv{}}.
244 @example
245 (make-sparse-keymap) @equiv{} (list 'keymap)
246 @end example
248 @node Printing Notation
249 @subsection Printing Notation
250 @cindex printing notation
252   Many of the examples in this manual print text when they are
253 evaluated.  If you execute example code in a Lisp Interaction buffer
254 (such as the buffer @samp{*scratch*}), the printed text is inserted into
255 the buffer.  If you execute the example by other means (such as by
256 evaluating the function @code{eval-region}), the printed text is
257 displayed in the echo area.
259   Examples in this manual indicate printed text with @samp{@print{}},
260 irrespective of where that text goes.  The value returned by evaluating
261 the form (here @code{bar}) follows on a separate line.
263 @example
264 @group
265 (progn (print 'foo) (print 'bar))
266      @print{} foo
267      @print{} bar
268      @result{} bar
269 @end group
270 @end example
272 @node Error Messages
273 @subsection Error Messages
274 @cindex error message notation
276   Some examples signal errors.  This normally displays an error message
277 in the echo area.  We show the error message on a line starting with
278 @samp{@error{}}.  Note that @samp{@error{}} itself does not appear in
279 the echo area.
281 @example
282 (+ 23 'x)
283 @error{} Wrong type argument: number-or-marker-p, x
284 @end example
286 @node Buffer Text Notation
287 @subsection Buffer Text Notation
288 @cindex buffer text notation
290   Some examples describe modifications to the contents of a buffer, by
291 showing the ``before'' and ``after'' versions of the text.  These
292 examples show the contents of the buffer in question between two lines
293 of dashes containing the buffer name.  In addition, @samp{@point{}}
294 indicates the location of point.  (The symbol for point, of course, is
295 not part of the text in the buffer; it indicates the place
296 @emph{between} two characters where point is currently located.)
298 @example
299 ---------- Buffer: foo ----------
300 This is the @point{}contents of foo.
301 ---------- Buffer: foo ----------
303 (insert "changed ")
304      @result{} nil
305 ---------- Buffer: foo ----------
306 This is the changed @point{}contents of foo.
307 ---------- Buffer: foo ----------
308 @end example
310 @node Format of Descriptions
311 @subsection Format of Descriptions
312 @cindex description format
314   Functions, variables, macros, commands, user options, and special
315 forms are described in this manual in a uniform format.  The first
316 line of a description contains the name of the item followed by its
317 arguments, if any.
318 @ifnottex
319 The category---function, variable, or whatever---appears at the
320 beginning of the line.
321 @end ifnottex
322 @iftex
323 The category---function, variable, or whatever---is printed next to the
324 right margin.
325 @end iftex
326 The description follows on succeeding lines, sometimes with examples.
328 @menu
329 * A Sample Function Description::       A description of an imaginary
330                                           function, @code{foo}.
331 * A Sample Variable Description::       A description of an imaginary
332                                           variable,
333                                           @code{electric-future-map}.  
334 @end menu
336 @node A Sample Function Description
337 @subsubsection A Sample Function Description
338 @cindex function descriptions
339 @cindex command descriptions
340 @cindex macro descriptions
341 @cindex special form descriptions
343   In a function description, the name of the function being described
344 appears first.  It is followed on the same line by a list of argument
345 names.  These names are also used in the body of the description, to
346 stand for the values of the arguments.
348   The appearance of the keyword @code{&optional} in the argument list
349 indicates that the subsequent arguments may be omitted (omitted
350 arguments default to @code{nil}).  Do not write @code{&optional} when
351 you call the function.
353   The keyword @code{&rest} (which must be followed by a single argument
354 name) indicates that any number of arguments can follow.  The single
355 following argument name will have a value, as a variable, which is a
356 list of all these remaining arguments.  Do not write @code{&rest} when
357 you call the function.
359   Here is a description of an imaginary function @code{foo}:
361 @defun foo integer1 &optional integer2 &rest integers
362 The function @code{foo} subtracts @var{integer1} from @var{integer2},
363 then adds all the rest of the arguments to the result.  If @var{integer2}
364 is not supplied, then the number 19 is used by default.
366 @example
367 (foo 1 5 3 9)
368      @result{} 16
369 (foo 5)
370      @result{} 14
371 @end example
373 @need 1500
374 More generally,
376 @example
377 (foo @var{w} @var{x} @var{y}@dots{})
378 @equiv{}
379 (+ (- @var{x} @var{w}) @var{y}@dots{})
380 @end example
381 @end defun
383   Any argument whose name contains the name of a type (e.g.,
384 @var{integer}, @var{integer1} or @var{buffer}) is expected to be of that
385 type.  A plural of a type (such as @var{buffers}) often means a list of
386 objects of that type.  Arguments named @var{object} may be of any type.
387 (@xref{Lisp Data Types}, for a list of Emacs object types.)  Arguments
388 with other sorts of names (e.g., @var{new-file}) are discussed
389 specifically in the description of the function.  In some sections,
390 features common to the arguments of several functions are described at
391 the beginning.
393   @xref{Lambda Expressions}, for a more complete description of optional
394 and rest arguments.
396   Command, macro, and special form descriptions have the same format,
397 but the word `Function' is replaced by `Command', `Macro', or `Special
398 Form', respectively.  Commands are simply functions that may be called
399 interactively; macros process their arguments differently from functions
400 (the arguments are not evaluated), but are presented the same way.
402   Special form descriptions use a more complex notation to specify
403 optional and repeated arguments because they can break the argument
404 list down into separate arguments in more complicated ways.
405 @samp{@r{[}@var{optional-arg}@r{]}} means that @var{optional-arg} is
406 optional and @samp{@var{repeated-args}@dots{}} stands for zero or more
407 arguments.  Parentheses are used when several arguments are grouped into
408 additional levels of list structure.  Here is an example:
410 @defspec count-loop (@var{var} [@var{from} @var{to} [@var{inc}]]) @var{body}@dots{}
411 This imaginary special form implements a loop that executes the
412 @var{body} forms and then increments the variable @var{var} on each
413 iteration.  On the first iteration, the variable has the value
414 @var{from}; on subsequent iterations, it is incremented by one (or by
415 @var{inc} if that is given).  The loop exits before executing @var{body}
416 if @var{var} equals @var{to}.  Here is an example:
418 @example
419 (count-loop (i 0 10)
420   (prin1 i) (princ " ")
421   (prin1 (aref vector i))
422   (terpri))
423 @end example
425 If @var{from} and @var{to} are omitted, @var{var} is bound to
426 @code{nil} before the loop begins, and the loop exits if @var{var} is
427 non-@code{nil} at the beginning of an iteration.  Here is an example:
429 @example
430 (count-loop (done)
431   (if (pending)
432       (fixit)
433     (setq done t)))
434 @end example
436 In this special form, the arguments @var{from} and @var{to} are
437 optional, but must both be present or both absent.  If they are present,
438 @var{inc} may optionally be specified as well.  These arguments are
439 grouped with the argument @var{var} into a list, to distinguish them
440 from @var{body}, which includes all remaining elements of the form.
441 @end defspec
443 @node A Sample Variable Description
444 @subsubsection A Sample Variable Description
445 @cindex variable descriptions
446 @cindex option descriptions
448   A @dfn{variable} is a name that can hold a value.  Although any
449 variable can be set by the user, certain variables that exist
450 specifically so that users can change them are called @dfn{user
451 options}.  Ordinary variables and user options are described using a
452 format like that for functions except that there are no arguments.
454   Here is a description of the imaginary @code{electric-future-map}
455 variable.@refill
457 @defvar electric-future-map
458 The value of this variable is a full keymap used by Electric Command
459 Future mode.  The functions in this map allow you to edit commands you
460 have not yet thought about executing.
461 @end defvar
463   User option descriptions have the same format, but `Variable' is
464 replaced by `User Option'.
466 @node Version Info
467 @section Version Information
469   These facilities provide information about which version of Emacs is
470 in use.
472 @deffn Command emacs-version
473 This function returns a string describing the version of Emacs that is
474 running.  It is useful to include this string in bug reports.
476 @smallexample
477 @group
478 (emacs-version)
479   @result{} "GNU Emacs 20.3.5 (i486-pc-linux-gnulibc1, X toolkit)
480  of Sat Feb 14 1998 on psilocin.gnu.org"
481 @end group
482 @end smallexample
484 Called interactively, the function prints the same information in the
485 echo area.
486 @end deffn
488 @defvar emacs-build-time
489 The value of this variable indicates the time at which Emacs was built
490 at the local site.  It is a list of three integers, like the value
491 of @code{current-time} (@pxref{Time of Day}).
493 @example
494 @group
495 emacs-build-time
496      @result{} (13623 62065 344633)
497 @end group
498 @end example
499 @end defvar
501 @defvar emacs-version
502 The value of this variable is the version of Emacs being run.  It is a
503 string such as @code{"20.3.1"}.  The last number in this string is not
504 really part of the Emacs release version number; it is incremented each
505 time you build Emacs in any given directory.  A value with three numeric
506 components, such as @code{"20.3.9.1"}, indicates an unreleased test
507 version.
508 @end defvar
510   The following two variables have existed since Emacs version 19.23:
512 @defvar emacs-major-version
513 The major version number of Emacs, as an integer.  For Emacs version
514 20.3, the value is 20.
515 @end defvar
517 @defvar emacs-minor-version
518 The minor version number of Emacs, as an integer.  For Emacs version
519 20.3, the value is 3.
520 @end defvar
522 @node Acknowledgements
523 @section Acknowledgements
525   This manual was written by Robert Krawitz, Bil Lewis, Dan LaLiberte,
526 Richard M. Stallman and Chris Welty, the volunteers of the GNU manual
527 group, in an effort extending over several years.  Robert J. Chassell
528 helped to review and edit the manual, with the support of the Defense
529 Advanced Research Projects Agency, ARPA Order 6082, arranged by Warren
530 A. Hunt, Jr.@: of Computational Logic, Inc.
532   Corrections were supplied by Karl Berry, Jim Blandy, Bard Bloom,
533 Stephane Boucher, David Boyes, Alan Carroll, Richard Davis, Lawrence
534 R. Dodd, Peter Doornbosch, David A. Duff, Chris Eich, Beverly
535 Erlebacher, David Eckelkamp, Ralf Fassel, Eirik Fuller, Stephen Gildea,
536 Bob Glickstein, Eric Hanchrow, George Hartzell, Nathan Hess, Masayuki
537 Ida, Dan Jacobson, Jak Kirman, Bob Knighten, Frederick M. Korz, Joe
538 Lammens, Glenn M. Lewis, K. Richard Magill, Brian Marick, Roland
539 McGrath, Skip Montanaro, John Gardiner Myers, Thomas A. Peterson,
540 Francesco Potorti, Friedrich Pukelsheim, Arnold D. Robbins, Raul
541 Rockwell, Per Starb@"ack, Shinichirou Sugou, Kimmo Suominen, Edward Tharp,
542 Bill Trost, Rickard Westman, Jean White, Matthew Wilding, Carl Witty,
543 Dale Worley, Rusty Wright, and David D. Zuhn.