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