Mercurial > emacs
annotate doc/lispref/intro.texi @ 101327:b0eef2ac5a59
(completion--insert-strings): Fix up computation of
column position which manifested e.g. in proced's signal completion.
author | Stefan Monnier <monnier@iro.umontreal.ca> |
---|---|
date | Wed, 21 Jan 2009 21:20:55 +0000 |
parents | cb5d2387102c |
children | 47ff541effb4 |
rev | line source |
---|---|
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, | |
100974 | 4 @c 2005, 2006, 2007, 2008, 2009 Free Software Foundation, Inc. |
84077 | 5 @c See the file elisp.texi for copying conditions. |
84116
0ba80d073e27
(setfilename): Go up one more level to ../../info.
Glenn Morris <rgm@gnu.org>
parents:
84077
diff
changeset
|
6 @setfilename ../../info/intro |
84077 | 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 | |
97142 | 58 intentionally. |
84077 | 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 | |
95947
de02caa08f70
Report bugs using M-x report-emacs-bug.
Glenn Morris <rgm@gnu.org>
parents:
93814
diff
changeset
|
89 Please send comments and corrections using @kbd{M-x report-emacs-bug}. |
84077 | 90 |
91 @node Lisp History | |
92 @section Lisp History | |
93 @cindex Lisp history | |
94 | |
95 Lisp (LISt Processing language) was first developed in the late 1950s | |
96 at the Massachusetts Institute of Technology for research in artificial | |
97 intelligence. The great power of the Lisp language makes it ideal | |
98 for other purposes as well, such as writing editing commands. | |
99 | |
100 @cindex Maclisp | |
101 @cindex Common Lisp | |
102 Dozens of Lisp implementations have been built over the years, each | |
103 with its own idiosyncrasies. Many of them were inspired by Maclisp, | |
104 which was written in the 1960s at MIT's Project MAC. Eventually the | |
105 implementors of the descendants of Maclisp came together and developed a | |
106 standard for Lisp systems, called Common Lisp. In the meantime, Gerry | |
107 Sussman and Guy Steele at MIT developed a simplified but very powerful | |
108 dialect of Lisp, called Scheme. | |
109 | |
110 GNU Emacs Lisp is largely inspired by Maclisp, and a little by Common | |
111 Lisp. If you know Common Lisp, you will notice many similarities. | |
112 However, many features of Common Lisp have been omitted or | |
113 simplified in order to reduce the memory requirements of GNU Emacs. | |
114 Sometimes the simplifications are so drastic that a Common Lisp user | |
115 might be very confused. We will occasionally point out how GNU Emacs | |
116 Lisp differs from Common Lisp. If you don't know Common Lisp, don't | |
117 worry about it; this manual is self-contained. | |
118 | |
119 @pindex cl | |
120 A certain amount of Common Lisp emulation is available via the | |
121 @file{cl} library. @inforef{Top, Overview, cl}. | |
122 | |
123 Emacs Lisp is not at all influenced by Scheme; but the GNU project has | |
124 an implementation of Scheme, called Guile. We use Guile in all new GNU | |
125 software that calls for extensibility. | |
126 | |
127 @node Conventions | |
128 @section Conventions | |
129 | |
130 This section explains the notational conventions that are used in this | |
131 manual. You may want to skip this section and refer back to it later. | |
132 | |
133 @menu | |
134 * Some Terms:: Explanation of terms we use in this manual. | |
135 * nil and t:: How the symbols @code{nil} and @code{t} are used. | |
136 * Evaluation Notation:: The format we use for examples of evaluation. | |
137 * Printing Notation:: The format we use when examples print text. | |
138 * Error Messages:: The format we use for examples of errors. | |
139 * Buffer Text Notation:: The format we use for buffer contents in examples. | |
140 * Format of Descriptions:: Notation for describing functions, variables, etc. | |
141 @end menu | |
142 | |
143 @node Some Terms | |
144 @subsection Some Terms | |
145 | |
146 Throughout this manual, the phrases ``the Lisp reader'' and ``the Lisp | |
147 printer'' refer to those routines in Lisp that convert textual | |
148 representations of Lisp objects into actual Lisp objects, and vice | |
149 versa. @xref{Printed Representation}, for more details. You, the | |
150 person reading this manual, are thought of as ``the programmer'' and are | |
151 addressed as ``you.'' ``The user'' is the person who uses Lisp | |
152 programs, including those you write. | |
153 | |
93814
e024e293c965
(Some Terms): Change "fonts in this manual" index entry to
Chong Yidong <cyd@stupidchicken.com>
parents:
87649
diff
changeset
|
154 @cindex typographic conventions |
84077 | 155 Examples of Lisp code are formatted like this: @code{(list 1 2 3)}. |
156 Names that represent metasyntactic variables, or arguments to a function | |
157 being described, are formatted like this: @var{first-number}. | |
158 | |
159 @node nil and t | |
160 @subsection @code{nil} and @code{t} | |
161 @cindex truth value | |
162 @cindex boolean | |
163 | |
164 @cindex @code{nil} | |
165 @cindex false | |
166 In Lisp, the symbol @code{nil} has three separate meanings: it | |
167 is a symbol with the name @samp{nil}; it is the logical truth value | |
168 @var{false}; and it is the empty list---the list of zero elements. | |
169 When used as a variable, @code{nil} always has the value @code{nil}. | |
170 | |
171 As far as the Lisp reader is concerned, @samp{()} and @samp{nil} are | |
172 identical: they stand for the same object, the symbol @code{nil}. The | |
173 different ways of writing the symbol are intended entirely for human | |
174 readers. After the Lisp reader has read either @samp{()} or @samp{nil}, | |
175 there is no way to determine which representation was actually written | |
176 by the programmer. | |
177 | |
178 In this manual, we write @code{()} when we wish to emphasize that it | |
179 means the empty list, and we write @code{nil} when we wish to emphasize | |
180 that it means the truth value @var{false}. That is a good convention to use | |
181 in Lisp programs also. | |
182 | |
183 @example | |
184 (cons 'foo ()) ; @r{Emphasize the empty list} | |
185 (setq foo-flag nil) ; @r{Emphasize the truth value @var{false}} | |
186 @end example | |
187 | |
188 @cindex @code{t} | |
189 @cindex true | |
190 In contexts where a truth value is expected, any non-@code{nil} value | |
191 is considered to be @var{true}. However, @code{t} is the preferred way | |
192 to represent the truth value @var{true}. When you need to choose a | |
193 value which represents @var{true}, and there is no other basis for | |
194 choosing, use @code{t}. The symbol @code{t} always has the value | |
195 @code{t}. | |
196 | |
197 In Emacs Lisp, @code{nil} and @code{t} are special symbols that always | |
198 evaluate to themselves. This is so that you do not need to quote them | |
199 to use them as constants in a program. An attempt to change their | |
200 values results in a @code{setting-constant} error. @xref{Constant | |
201 Variables}. | |
202 | |
203 @defun booleanp object | |
99916
99af427b4d7f
(nil and t): Fix typo.
Chong Yidong <cyd@stupidchicken.com>
parents:
97142
diff
changeset
|
204 Return non-@code{nil} if @var{object} is one of the two canonical |
99af427b4d7f
(nil and t): Fix typo.
Chong Yidong <cyd@stupidchicken.com>
parents:
97142
diff
changeset
|
205 boolean values: @code{t} or @code{nil}. |
84077 | 206 @end defun |
207 | |
208 @node Evaluation Notation | |
209 @subsection Evaluation Notation | |
210 @cindex evaluation notation | |
211 @cindex documentation notation | |
212 @cindex notation | |
213 | |
214 A Lisp expression that you can evaluate is called a @dfn{form}. | |
215 Evaluating a form always produces a result, which is a Lisp object. In | |
216 the examples in this manual, this is indicated with @samp{@result{}}: | |
217 | |
218 @example | |
219 (car '(1 2)) | |
220 @result{} 1 | |
221 @end example | |
222 | |
223 @noindent | |
224 You can read this as ``@code{(car '(1 2))} evaluates to 1.'' | |
225 | |
226 When a form is a macro call, it expands into a new form for Lisp to | |
227 evaluate. We show the result of the expansion with | |
228 @samp{@expansion{}}. We may or may not show the result of the | |
229 evaluation of the expanded form. | |
230 | |
231 @example | |
232 (third '(a b c)) | |
233 @expansion{} (car (cdr (cdr '(a b c)))) | |
234 @result{} c | |
235 @end example | |
236 | |
237 Sometimes to help describe one form we show another form that | |
238 produces identical results. The exact equivalence of two forms is | |
239 indicated with @samp{@equiv{}}. | |
240 | |
241 @example | |
242 (make-sparse-keymap) @equiv{} (list 'keymap) | |
243 @end example | |
244 | |
245 @node Printing Notation | |
246 @subsection Printing Notation | |
247 @cindex printing notation | |
248 | |
249 Many of the examples in this manual print text when they are | |
250 evaluated. If you execute example code in a Lisp Interaction buffer | |
251 (such as the buffer @samp{*scratch*}), the printed text is inserted into | |
252 the buffer. If you execute the example by other means (such as by | |
253 evaluating the function @code{eval-region}), the printed text is | |
254 displayed in the echo area. | |
255 | |
256 Examples in this manual indicate printed text with @samp{@print{}}, | |
257 irrespective of where that text goes. The value returned by | |
258 evaluating the form (here @code{bar}) follows on a separate line with | |
259 @samp{@result{}}. | |
260 | |
261 @example | |
262 @group | |
263 (progn (prin1 'foo) (princ "\n") (prin1 'bar)) | |
264 @print{} foo | |
265 @print{} bar | |
266 @result{} bar | |
267 @end group | |
268 @end example | |
269 | |
270 @node Error Messages | |
271 @subsection Error Messages | |
272 @cindex error message notation | |
273 | |
274 Some examples signal errors. This normally displays an error message | |
275 in the echo area. We show the error message on a line starting with | |
276 @samp{@error{}}. Note that @samp{@error{}} itself does not appear in | |
277 the echo area. | |
278 | |
279 @example | |
280 (+ 23 'x) | |
281 @error{} Wrong type argument: number-or-marker-p, x | |
282 @end example | |
283 | |
284 @node Buffer Text Notation | |
285 @subsection Buffer Text Notation | |
286 @cindex buffer text notation | |
287 | |
288 Some examples describe modifications to the contents of a buffer, by | |
289 showing the ``before'' and ``after'' versions of the text. These | |
290 examples show the contents of the buffer in question between two lines | |
291 of dashes containing the buffer name. In addition, @samp{@point{}} | |
292 indicates the location of point. (The symbol for point, of course, is | |
293 not part of the text in the buffer; it indicates the place | |
294 @emph{between} two characters where point is currently located.) | |
295 | |
296 @example | |
297 ---------- Buffer: foo ---------- | |
298 This is the @point{}contents of foo. | |
299 ---------- Buffer: foo ---------- | |
300 | |
301 (insert "changed ") | |
302 @result{} nil | |
303 ---------- Buffer: foo ---------- | |
304 This is the changed @point{}contents of foo. | |
305 ---------- Buffer: foo ---------- | |
306 @end example | |
307 | |
308 @node Format of Descriptions | |
309 @subsection Format of Descriptions | |
310 @cindex description format | |
311 | |
312 Functions, variables, macros, commands, user options, and special | |
313 forms are described in this manual in a uniform format. The first | |
314 line of a description contains the name of the item followed by its | |
315 arguments, if any. | |
316 @ifnottex | |
317 The category---function, variable, or whatever---appears at the | |
318 beginning of the line. | |
319 @end ifnottex | |
320 @iftex | |
321 The category---function, variable, or whatever---is printed next to the | |
322 right margin. | |
323 @end iftex | |
324 The description follows on succeeding lines, sometimes with examples. | |
325 | |
326 @menu | |
327 * A Sample Function Description:: A description of an imaginary | |
328 function, @code{foo}. | |
329 * A Sample Variable Description:: A description of an imaginary | |
330 variable, | |
331 @code{electric-future-map}. | |
332 @end menu | |
333 | |
334 @node A Sample Function Description | |
335 @subsubsection A Sample Function Description | |
336 @cindex function descriptions | |
337 @cindex command descriptions | |
338 @cindex macro descriptions | |
339 @cindex special form descriptions | |
340 | |
341 In a function description, the name of the function being described | |
342 appears first. It is followed on the same line by a list of argument | |
343 names. These names are also used in the body of the description, to | |
344 stand for the values of the arguments. | |
345 | |
346 The appearance of the keyword @code{&optional} in the argument list | |
347 indicates that the subsequent arguments may be omitted (omitted | |
348 arguments default to @code{nil}). Do not write @code{&optional} when | |
349 you call the function. | |
350 | |
351 The keyword @code{&rest} (which must be followed by a single | |
352 argument name) indicates that any number of arguments can follow. The | |
353 single argument name following @code{&rest} will receive, as its | |
354 value, a list of all the remaining arguments passed to the function. | |
355 Do not write @code{&rest} when you call the function. | |
356 | |
357 Here is a description of an imaginary function @code{foo}: | |
358 | |
359 @defun foo integer1 &optional integer2 &rest integers | |
360 The function @code{foo} subtracts @var{integer1} from @var{integer2}, | |
361 then adds all the rest of the arguments to the result. If @var{integer2} | |
362 is not supplied, then the number 19 is used by default. | |
363 | |
364 @example | |
365 (foo 1 5 3 9) | |
366 @result{} 16 | |
367 (foo 5) | |
368 @result{} 14 | |
369 @end example | |
370 | |
371 @need 1500 | |
372 More generally, | |
373 | |
374 @example | |
375 (foo @var{w} @var{x} @var{y}@dots{}) | |
376 @equiv{} | |
377 (+ (- @var{x} @var{w}) @var{y}@dots{}) | |
378 @end example | |
379 @end defun | |
380 | |
381 Any argument whose name contains the name of a type (e.g., | |
382 @var{integer}, @var{integer1} or @var{buffer}) is expected to be of that | |
383 type. A plural of a type (such as @var{buffers}) often means a list of | |
384 objects of that type. Arguments named @var{object} may be of any type. | |
385 (@xref{Lisp Data Types}, for a list of Emacs object types.) Arguments | |
386 with other sorts of names (e.g., @var{new-file}) are discussed | |
387 specifically in the description of the function. In some sections, | |
388 features common to the arguments of several functions are described at | |
389 the beginning. | |
390 | |
391 @xref{Lambda Expressions}, for a more complete description of optional | |
392 and rest arguments. | |
393 | |
394 Command, macro, and special form descriptions have the same format, | |
395 but the word `Function' is replaced by `Command', `Macro', or `Special | |
396 Form', respectively. Commands are simply functions that may be called | |
397 interactively; macros process their arguments differently from functions | |
398 (the arguments are not evaluated), but are presented the same way. | |
399 | |
400 Special form descriptions use a more complex notation to specify | |
401 optional and repeated arguments because they can break the argument | |
402 list down into separate arguments in more complicated ways. | |
403 @samp{@r{[}@var{optional-arg}@r{]}} means that @var{optional-arg} is | |
404 optional and @samp{@var{repeated-args}@dots{}} stands for zero or more | |
405 arguments. Parentheses are used when several arguments are grouped into | |
406 additional levels of list structure. Here is an example: | |
407 | |
408 @defspec count-loop (@var{var} [@var{from} @var{to} [@var{inc}]]) @var{body}@dots{} | |
409 This imaginary special form implements a loop that executes the | |
410 @var{body} forms and then increments the variable @var{var} on each | |
411 iteration. On the first iteration, the variable has the value | |
412 @var{from}; on subsequent iterations, it is incremented by one (or by | |
413 @var{inc} if that is given). The loop exits before executing @var{body} | |
414 if @var{var} equals @var{to}. Here is an example: | |
415 | |
416 @example | |
417 (count-loop (i 0 10) | |
418 (prin1 i) (princ " ") | |
419 (prin1 (aref vector i)) | |
420 (terpri)) | |
421 @end example | |
422 | |
423 If @var{from} and @var{to} are omitted, @var{var} is bound to | |
424 @code{nil} before the loop begins, and the loop exits if @var{var} is | |
425 non-@code{nil} at the beginning of an iteration. Here is an example: | |
426 | |
427 @example | |
428 (count-loop (done) | |
429 (if (pending) | |
430 (fixit) | |
431 (setq done t))) | |
432 @end example | |
433 | |
434 In this special form, the arguments @var{from} and @var{to} are | |
435 optional, but must both be present or both absent. If they are present, | |
436 @var{inc} may optionally be specified as well. These arguments are | |
437 grouped with the argument @var{var} into a list, to distinguish them | |
438 from @var{body}, which includes all remaining elements of the form. | |
439 @end defspec | |
440 | |
441 @node A Sample Variable Description | |
442 @subsubsection A Sample Variable Description | |
443 @cindex variable descriptions | |
444 @cindex option descriptions | |
445 | |
446 A @dfn{variable} is a name that can hold a value. Although nearly | |
447 all variables can be set by the user, certain variables exist | |
448 specifically so that users can change them; these are called @dfn{user | |
449 options}. Ordinary variables and user options are described using a | |
450 format like that for functions except that there are no arguments. | |
451 | |
452 Here is a description of the imaginary @code{electric-future-map} | |
453 variable.@refill | |
454 | |
455 @defvar electric-future-map | |
456 The value of this variable is a full keymap used by Electric Command | |
457 Future mode. The functions in this map allow you to edit commands you | |
458 have not yet thought about executing. | |
459 @end defvar | |
460 | |
461 User option descriptions have the same format, but `Variable' is | |
462 replaced by `User Option'. | |
463 | |
464 @node Version Info | |
465 @section Version Information | |
466 | |
467 These facilities provide information about which version of Emacs is | |
468 in use. | |
469 | |
470 @deffn Command emacs-version &optional here | |
471 This function returns a string describing the version of Emacs that is | |
472 running. It is useful to include this string in bug reports. | |
473 | |
474 @smallexample | |
475 @group | |
476 (emacs-version) | |
477 @result{} "GNU Emacs 20.3.5 (i486-pc-linux-gnulibc1, X toolkit) | |
478 of Sat Feb 14 1998 on psilocin.gnu.org" | |
479 @end group | |
480 @end smallexample | |
481 | |
482 If @var{here} is non-@code{nil}, it inserts the text in the buffer | |
483 before point, and returns @code{nil}. Called interactively, the | |
484 function prints the same information in the echo area, but giving a | |
485 prefix argument makes @var{here} non-@code{nil}. | |
486 @end deffn | |
487 | |
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}). | |
492 | |
493 @example | |
494 @group | |
495 emacs-build-time | |
496 @result{} (13623 62065 344633) | |
497 @end group | |
498 @end example | |
499 @end defvar | |
500 | |
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 four numeric | |
506 components, such as @code{"20.3.9.1"}, indicates an unreleased test | |
507 version. | |
508 @end defvar | |
509 | |
510 The following two variables have existed since Emacs version 19.23: | |
511 | |
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 | |
516 | |
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 | |
521 | |
522 @node Acknowledgements | |
523 @section Acknowledgements | |
524 | |
525 This manual was written by Robert Krawitz, Bil Lewis, Dan LaLiberte, | |
526 Richard@tie{}M. Stallman and Chris Welty, the volunteers of the GNU | |
527 manual group, in an effort extending over several years. | |
528 Robert@tie{}J. Chassell helped to review and edit the manual, with the | |
529 support of the Defense Advanced Research Projects Agency, ARPA Order | |
530 6082, arranged by Warren@tie{}A. Hunt, Jr.@: of Computational Logic, | |
531 Inc. | |
532 | |
533 Corrections were supplied by Karl Berry, Jim Blandy, Bard Bloom, | |
534 Stephane Boucher, David Boyes, Alan Carroll, Richard Davis, Lawrence | |
535 R. Dodd, Peter Doornbosch, David A. Duff, Chris Eich, Beverly | |
536 Erlebacher, David Eckelkamp, Ralf Fassel, Eirik Fuller, Stephen Gildea, | |
537 Bob Glickstein, Eric Hanchrow, George Hartzell, Nathan Hess, Masayuki | |
538 Ida, Dan Jacobson, Jak Kirman, Bob Knighten, Frederick M. Korz, Joe | |
539 Lammens, Glenn M. Lewis, K. Richard Magill, Brian Marick, Roland | |
540 McGrath, Skip Montanaro, John Gardiner Myers, Thomas A. Peterson, | |
541 Francesco Potorti, Friedrich Pukelsheim, Arnold D. Robbins, Raul | |
542 Rockwell, Per Starb@"ack, Shinichirou Sugou, Kimmo Suominen, Edward Tharp, | |
543 Bill Trost, Rickard Westman, Jean White, Matthew Wilding, Carl Witty, | |
544 Dale Worley, Rusty Wright, and David D. Zuhn. | |
545 | |
546 @ignore | |
547 arch-tag: d156593f-82f8-4708-a844-204e48f7f2aa | |
548 @end ignore |