intro.texi 21 KB

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