1. Introduction

Most of the XEmacs text editor is written in the programming language called XEmacs Lisp. You can write new code in XEmacs Lisp and install it as an extension to the editor. However, XEmacs Lisp is more than a mere “extension language”; it is a full computer programming language in its own right. You can use it as you would any other programming language.

Because XEmacs Lisp is designed for use in an editor, it has special features for scanning and parsing text as well as features for handling files, buffers, displays, subprocesses, and so on. XEmacs Lisp is closely integrated with the editing facilities; thus, editing commands are functions that can also conveniently be called from Lisp programs, and parameters for customization are ordinary Lisp variables.

This manual describes XEmacs Lisp, presuming considerable familiarity with the use of XEmacs for editing. (See The XEmacs Reference Manual, for this basic information.) Generally speaking, the earlier chapters describe features of XEmacs Lisp that have counterparts in many programming languages, and later chapters describe features that are peculiar to XEmacs Lisp or relate specifically to editing.

This is edition 3.3.

1.1 Caveats

This manual has gone through numerous drafts. It is nearly complete but not flawless. There are a few topics that are not covered, either because we consider them secondary (such as most of the individual modes) or because they are yet to be written. Because we are not able to deal with them completely, we have left out several parts intentionally.

The manual should be fully correct in what it does cover, and it is therefore open to criticism on anything it says—from specific examples and descriptive text, to the ordering of chapters and sections. If something is confusing, or you find that you have to look at the sources or experiment to learn something not covered in the manual, then perhaps the manual should be fixed. Please let us know.

This manual was originally written for FSF Emacs 19 and was updated by Ben Wing (ben@xemacs.org) for Lucid Emacs 19.10 and later for XEmacs 19.12, 19.13, 19.14, and 20.0. It was further updated by the XEmacs Development Team for 19.15 and 20.1. Please send comments and corrections relating to XEmacs-specific portions of this manual to

xemacs@xemacs.org

or post to the newsgroup

comp.emacs.xemacs

 –Ben Wing

1.2 Lisp History

Lisp (LISt Processing language) was first developed in the late 1950’s at the Massachusetts Institute of Technology for research in artificial intelligence. The great power of the Lisp language makes it superior for other purposes as well, such as writing editing commands.

Dozens of Lisp implementations have been built over the years, each with its own idiosyncrasies. Many of them were inspired by Maclisp, which was written in the 1960’s at MIT’s Project MAC. Eventually the implementors of the descendants of Maclisp came together and developed a standard for Lisp systems, called Common Lisp.

XEmacs Lisp is largely inspired by Maclisp, and a little by Common Lisp. If you know Common Lisp, you will notice many similarities. However, many of the features of Common Lisp have been omitted or simplified in order to reduce the memory requirements of XEmacs. Sometimes the simplifications are so drastic that a Common Lisp user might be very confused. We will occasionally point out how XEmacs Lisp differs from Common Lisp. If you don’t know Common Lisp, don’t worry about it; this manual is self-contained.

1.3 Conventions

This section explains the notational conventions that are used in this manual. You may want to skip this section and refer back to it later.

1.3.1 Some Terms

Throughout this manual, the phrases “the Lisp reader” and “the Lisp printer” are used to refer to those routines in Lisp that convert textual representations of Lisp objects into actual Lisp objects, and vice versa. See section Printed Representation and Read Syntax, for more details. You, the person reading this manual, are thought of as “the programmer” and are addressed as “you”. “The user” is the person who uses Lisp programs, including those you write.

Examples of Lisp code appear in this font or form: (list 1 2 3). Names that represent arguments or metasyntactic variables appear in this font or form: first-number.

1.3.2 nil and t

In Lisp, the symbol nil has three separate meanings: it is a symbol with the name ‘nil’; it is the logical truth value false; and it is the empty list—the list of zero elements. When used as a variable, nil always has the value nil.

As far as the Lisp reader is concerned, ‘()’ and ‘nil’ are identical: they stand for the same object, the symbol nil. The different ways of writing the symbol are intended entirely for human readers. After the Lisp reader has read either ‘()’ or ‘nil’, there is no way to determine which representation was actually written by the programmer.

In this manual, we use () when we wish to emphasize that it means the empty list, and we use nil when we wish to emphasize that it means the truth value false. That is a good convention to use in Lisp programs also.

(cons 'foo ())                ; Emphasize the empty list
(not nil)                     ; Emphasize the truth value false

In contexts where a truth value is expected, any non-nil value is considered to be true. However, t is the preferred way to represent the truth value true. When you need to choose a value which represents true, and there is no other basis for choosing, use t. The symbol t always has value t.

In XEmacs Lisp, nil and t are special symbols that always evaluate to themselves. This is so that you do not need to quote them to use them as constants in a program. An attempt to change their values results in a setting-constant error. See section Accessing Variable Values.

1.3.3 Evaluation Notation

A Lisp expression that you can evaluate is called a form. Evaluating a form always produces a result, which is a Lisp object. In the examples in this manual, this is indicated with ‘⇒’:

(car '(1 2))
     ⇒ 1

You can read this as “(car '(1 2)) evaluates to 1”.

When a form is a macro call, it expands into a new form for Lisp to evaluate. We show the result of the expansion with ‘→’. We may or may not show the actual result of the evaluation of the expanded form.

(news-cadr '(a b c))
     → (car (cdr '(a b c)))
     ⇒ b

Sometimes to help describe one form we show another form that produces identical results. The exact equivalence of two forms is indicated with ‘≡’.

(cons 'a nil) ≡ (list 'a)

1.3.4 Printing Notation

Many of the examples in this manual print text when they are evaluated. If you execute example code in a Lisp Interaction buffer (such as the buffer ‘*scratch*’), the printed text is inserted into the buffer. If you execute the example by other means (such as by evaluating the function eval-region), the printed text is displayed in the echo area. You should be aware that text displayed in the echo area is truncated to a single line.

Examples in this manual indicate printed text with ‘-|’, irrespective of where that text goes. The value returned by evaluating the form (here bar) follows on a separate line.

(progn (print 'foo) (print 'bar))
     -| foo
     -| bar
     ⇒ bar

1.3.5 Error Messages

Some examples signal errors. This normally displays an error message in the echo area. We show the error message on a line starting with ‘error-->’. Note that ‘error-->’ itself does not appear in the echo area.

(+ 23 'x)
error--> Wrong type argument: integer-or-marker-p, x

1.3.6 Buffer Text Notation

Some examples show modifications to text in a buffer, with “before” and “after” versions of the text. These examples show the contents of the buffer in question between two lines of dashes containing the buffer name. In addition, ‘∗’ indicates the location of point. (The symbol for point, of course, is not part of the text in the buffer; it indicates the place between two characters where point is located.)

---------- Buffer: foo ----------
This is the ∗contents of foo.
---------- Buffer: foo ----------

(insert "changed ")
     ⇒ nil
---------- Buffer: foo ----------
This is the changed ∗contents of foo.
---------- Buffer: foo ----------

1.3.7 Format of Descriptions

Functions, variables, macros, commands, user options, and special forms are described in this manual in a uniform format. The first line of a description contains the name of the item followed by its arguments, if any. The description follows on succeeding lines, sometimes with examples.

1.3.7.1 A Sample Function Description

In a function description, the name of the function being described appears first. It is followed on the same line by a list of parameters. The names used for the parameters are also used in the body of the description.

The appearance of the keyword &optional in the parameter list indicates that the arguments for subsequent parameters may be omitted (omitted parameters default to nil). Do not write &optional when you call the function.

The keyword &rest (which will always be followed by a single parameter) indicates that any number of arguments can follow. The value of the single following parameter will be a list of all these arguments. Do not write &rest when you call the function.

Here is a description of an imaginary function foo:

Function: foo integer1 &optional integer2 &rest integers

The function foo subtracts integer1 from integer2, then adds all the rest of the arguments to the result. If integer2 is not supplied, then the number 19 is used by default.

(foo 1 5 3 9) ⇒ 16 (foo 5) ⇒ 14

More generally,

(foo w x y…) ≡ (+ (- x w) y…)

Any parameter whose name contains the name of a type (e.g., integer, integer1 or buffer) is expected to be of that type. A plural of a type (such as buffers) often means a list of objects of that type. Parameters named object may be of any type. (See section Lisp Data Types, for a list of XEmacs object types.) Parameters with other sorts of names (e.g., new-file) are discussed specifically in the description of the function. In some sections, features common to parameters of several functions are described at the beginning.

See section Lambda Expressions, for a more complete description of optional and rest arguments.

Command, macro, and special operator descriptions have the same format, but the word ‘Function’ is replaced by ‘Command’, ‘Macro’, or ‘Special Form’, respectively. Commands are simply functions that may be called interactively; macros process their arguments differently from functions (the arguments are not evaluated), but are presented the same way.

Special operator descriptions use a more complex notation to specify optional and repeated parameters because they can break the argument list down into separate arguments in more complicated ways. ‘[optional-arg]’ means that optional-arg is optional and ‘repeated-args…’ stands for zero or more arguments. Parentheses are used when several arguments are grouped into additional levels of list structure. Here is an example:

Special Operator: count-loop (var [from to [inc]]) body…

This imaginary special operator implements a loop that executes the body forms and then increments the variable var on each iteration. On the first iteration, the variable has the value from; on subsequent iterations, it is incremented by 1 (or by inc if that is given). The loop exits before executing body if var equals to. Here is an example:

(count-loop (i 0 10) (prin1 i) (princ " ") (prin1 (aref vector i)) (terpri))

If from and to are omitted, then var is bound to nil before the loop begins, and the loop exits if var is non-nil at the beginning of an iteration. Here is an example:

(count-loop (done) (if (pending) (fixit) (setq done t)))

With this special operator, the arguments from and to are optional, but must both be present or both absent. If they are present, inc may optionally be specified as well. These arguments are grouped with the argument var into a list, to distinguish them from body, which includes all remaining elements of the form.

1.3.7.2 A Sample Variable Description

A variable is a name that can hold a value. Although any variable can be set by the user, certain variables that exist specifically so that users can change them are called user options. Ordinary variables and user options are described using a format like that for functions except that there are no arguments.

Here is a description of the imaginary electric-future-map variable.

Variable: electric-future-map

The value of this variable is a full keymap used by Electric Command Future mode. The functions in this map allow you to edit commands you have not yet thought about executing.

User option descriptions have the same format, but ‘Variable’ is replaced by ‘User Option’.

This document was generated by Aidan Kehoe on December 27, 2016 using texi2html 1.82.