Next: Writing Dynamic Modules, Previous: C Dialect, Up: GNU Emacs Internals
Lisp primitives are Lisp functions implemented in C. The details of interfacing the C function so that Lisp can call it are handled by a few C macros. The only way to really understand how to write new C code is to read the source, but we can explain some things here.
An example of a special form is the definition of or
, from
eval.c. (An ordinary function would have the same general
appearance.)
DEFUN ("or", For, Sor, 0, UNEVALLED, 0, doc: /* Eval args until one of them yields non-nil, then return that value. The remaining args are not evalled at all. If all args return nil, return nil. usage: (or CONDITIONS...) */) (Lisp_Object args) { Lisp_Object val = Qnil; while (CONSP (args)) { val = eval_sub (XCAR (args)); if (!NILP (val)) break; args = XCDR (args); maybe_quit (); } return val; }
Let's start with a precise explanation of the arguments to the
DEFUN
macro. Here is a template for them:
DEFUN (lname, fname, sname, min, max, interactive, doc)
or
.
For
.
or
allows a minimum of zero arguments.
UNEVALLED
,
indicating a special form that receives unevaluated arguments, or
MANY
, indicating an unlimited number of evaluated arguments (the
equivalent of &rest
). Both UNEVALLED
and MANY
are
macros. If max is a number, it must be more than min but
less than 8.
interactive
in a Lisp function
(see Using Interactive). In the case
of or
, it is 0
(a null pointer), indicating that or
cannot be called interactively. A value of ""
indicates a
function that should receive no arguments when called interactively.
If the value begins with a ‘"(’, the string is evaluated as a
Lisp form. For example:
DEFUN ("foo", Ffoo, Sfoo, 0, 3, "(list (read-char-by-name \"Insert character: \")\ (prefix-numeric-value current-prefix-arg)\ t)", doc: /* ... */)
If the last line of the documentation string begins with the keyword ‘usage:’, the rest of the line is treated as the argument list for documentation purposes. This way, you can use different argument names in the documentation string from the ones used in the C code. ‘usage:’ is required if the function has an unlimited number of arguments.
All the usual rules for documentation strings in Lisp code (see Documentation Tips) apply to C code documentation strings too.
The documentation string can be followed by a list of C function attributes for the C function that implements the primitive, like this:
DEFUN ("bar", Fbar, Sbar, 0, UNEVALLED, 0 doc: /* ... */ attributes: attr1 attr2 ...)
You can specify more than a single attribute, one after the other. Currently, only the following attributes are recognized:
noreturn
_Noreturn
and to __attribute__ ((__noreturn__))
attribute of GCC (see Function Attributes).
const
__attribute__ ((__const__))
attribute of
GCC.
noinline
__attribute__ ((__noinline__))
attribute of GCC, which prevents the function from being considered
for inlining. This might be needed, e.g., to countermand effects of
link-time optimizations on stack-based variables.
After the call to the DEFUN
macro, you must write the
argument list for the C function, including the types for the
arguments. If the primitive accepts a fixed maximum number of Lisp
arguments, there must be one C argument for each Lisp argument, and
each argument must be of type Lisp_Object
. (Various macros and
functions for creating values of type Lisp_Object
are declared
in the file lisp.h.) If the primitive is a special form, it
must accept a Lisp list containing its unevaluated Lisp arguments as a
single argument of type Lisp_Object
. If the primitive has no
upper limit on the number of evaluated Lisp arguments, it must have
exactly two C arguments: the first is the number of Lisp arguments,
and the second is the address of a block containing their values.
These have types ptrdiff_t
and Lisp_Object *
,
respectively. Since Lisp_Object
can hold any Lisp object of
any data type, you can determine the actual data type only at run
time; so if you want a primitive to accept only a certain type of
argument, you must check the type explicitly using a suitable
predicate (see Type Predicates).
Within the function For
itself, the local variable
args
refers to objects controlled by Emacs's stack-marking
garbage collector. Although the garbage collector does not reclaim
objects reachable from C Lisp_Object
stack variables, it may
move some of the components of an object, such as the contents of a
string or the text of a buffer. Therefore, functions that access
these components must take care to refetch their addresses after
performing Lisp evaluation. This means that instead of keeping C
pointers to string contents or buffer text, the code should keep the
buffer or string position, and recompute the C pointer from the
position after performing Lisp evaluation. Lisp evaluation can occur
via calls to eval_sub
or Feval
, either directly or
indirectly.
Note the call to maybe_quit
inside the loop: this function
checks whether the user pressed C-g, and if so, aborts the
processing. You should do that in any loop that can potentially
require a large number of iterations; in this case, the list of
arguments could be very long. This increases Emacs responsiveness and
improves user experience.
You must not use C initializers for static or global variables unless the variables are never written once Emacs is dumped. These variables with initializers are allocated in an area of memory that becomes read-only (on certain operating systems) as a result of dumping Emacs. See Pure Storage.
Defining the C function is not enough to make a Lisp primitive available; you must also create the Lisp symbol for the primitive and store a suitable subr object in its function cell. The code looks like this:
defsubr (&sname);
Here sname is the name you used as the third argument to DEFUN
.
If you add a new primitive to a file that already has Lisp primitives
defined in it, find the function (near the end of the file) named
syms_of_
something, and add the call to defsubr
there. If the file doesn't have this function, or if you create a new
file, add to it a syms_of_
filename (e.g.,
syms_of_myfile
). Then find the spot in emacs.c where all
of these functions are called, and add a call to
syms_of_
filename there.
The function syms_of_
filename is also the place to define
any C variables that are to be visible as Lisp variables.
DEFVAR_LISP
makes a C variable of type Lisp_Object
visible
in Lisp. DEFVAR_INT
makes a C variable of type int
visible in Lisp with a value that is always an integer.
DEFVAR_BOOL
makes a C variable of type int
visible in Lisp
with a value that is either t
or nil
. Note that variables
defined with DEFVAR_BOOL
are automatically added to the list
byte-boolean-vars
used by the byte compiler.
If you want to make a Lisp variable that is defined in C behave
like one declared with defcustom
, add an appropriate entry to
cus-start.el.
If you define a file-scope C variable of type Lisp_Object
,
you must protect it from garbage-collection by calling staticpro
in syms_of_
filename, like this:
staticpro (&variable);
Here is another example function, with more complicated arguments. This comes from the code in window.c, and it demonstrates the use of macros and functions to manipulate Lisp objects.
DEFUN ("coordinates-in-window-p", Fcoordinates_in_window_p, Scoordinates_in_window_p, 2, 2, 0, doc: /* Return non-nil if COORDINATES are in WINDOW. ... or `right-margin' is returned. */) (register Lisp_Object coordinates, Lisp_Object window) { struct window *w; struct frame *f; int x, y; Lisp_Object lx, ly; w = decode_live_window (window); f = XFRAME (w->frame); CHECK_CONS (coordinates); lx = Fcar (coordinates); ly = Fcdr (coordinates); CHECK_NUMBER (lx); CHECK_NUMBER (ly); x = FRAME_PIXEL_X_FROM_CANON_X (f, lx) + FRAME_INTERNAL_BORDER_WIDTH (f); y = FRAME_PIXEL_Y_FROM_CANON_Y (f, ly) + FRAME_INTERNAL_BORDER_WIDTH (f); switch (coordinates_in_window (w, x, y)) { case ON_NOTHING: /* NOT in window at all. */ return Qnil; ... case ON_MODE_LINE: /* In mode line of window. */ return Qmode_line; ... case ON_SCROLL_BAR: /* On scroll-bar of window. */ /* Historically we are supposed to return nil in this case. */ return Qnil; default: emacs_abort (); } }
Note that C code cannot call functions by name unless they are defined
in C. The way to call a function written in Lisp is to use
Ffuncall
, which embodies the Lisp function funcall
. Since
the Lisp function funcall
accepts an unlimited number of
arguments, in C it takes two: the number of Lisp-level arguments, and a
one-dimensional array containing their values. The first Lisp-level
argument is the Lisp function to call, and the rest are the arguments to
pass to it.
The C functions call0
, call1
, call2
, and so on,
provide handy ways to call a Lisp function conveniently with a fixed
number of arguments. They work by calling Ffuncall
.
eval.c is a very good file to look through for examples; lisp.h contains the definitions for some important macros and functions.
If you define a function which is side-effect free or pure, give it
a non-nil
side-effect-free
or pure
property,
respectively (see Standard Properties).