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