1994-03-21 07:49:21 +00:00
|
|
|
@c -*-texinfo-*-
|
|
|
|
@c This is part of the GNU Emacs Lisp Reference Manual.
|
|
|
|
@c Copyright (C) 1990, 1991, 1992, 1993 Free Software Foundation, Inc.
|
|
|
|
@c See the file elisp.texi for copying conditions.
|
|
|
|
@setfilename ../info/internals
|
|
|
|
@node GNU Emacs Internals, Standard Errors, Tips, Top
|
|
|
|
@comment node-name, next, previous, up
|
|
|
|
@appendix GNU Emacs Internals
|
|
|
|
|
|
|
|
This chapter describes how the runnable Emacs executable is dumped with
|
|
|
|
the preloaded Lisp libraries in it, how storage is allocated, and some
|
|
|
|
internal aspects of GNU Emacs that may be of interest to C programmers.
|
|
|
|
|
|
|
|
@menu
|
|
|
|
* Building Emacs:: How to preload Lisp libraries into Emacs.
|
|
|
|
* Pure Storage:: A kludge to make preloaded Lisp functions sharable.
|
|
|
|
* Garbage Collection:: Reclaiming space for Lisp objects no longer used.
|
|
|
|
* Writing Emacs Primitives:: Writing C code for Emacs.
|
|
|
|
* Object Internals:: Data formats of buffers, windows, processes.
|
|
|
|
@end menu
|
|
|
|
|
|
|
|
@node Building Emacs, Pure Storage, GNU Emacs Internals, GNU Emacs Internals
|
|
|
|
@appendixsec Building Emacs
|
|
|
|
@cindex building Emacs
|
|
|
|
@pindex temacs
|
|
|
|
|
|
|
|
This section explains the steps involved in building the Emacs
|
|
|
|
executable. You don't have to know this material to build and install
|
|
|
|
Emacs, since the makefiles do all these things automatically. This
|
|
|
|
information is pertinent to Emacs maintenance.
|
|
|
|
|
|
|
|
Compilation of the C source files in the @file{src} directory
|
|
|
|
produces an executable file called @file{temacs}, also called a
|
|
|
|
@dfn{bare impure Emacs}. It contains the Emacs Lisp interpreter and I/O
|
|
|
|
routines, but not the editing commands.
|
|
|
|
|
|
|
|
@cindex @file{loadup.el}
|
|
|
|
The command @w{@samp{temacs -l loadup}} uses @file{temacs} to create
|
|
|
|
the real runnable Emacs executable. These arguments direct
|
|
|
|
@file{temacs} to evaluate the Lisp files specified in the file
|
|
|
|
@file{loadup.el}. These files set up the normal Emacs editing
|
1994-05-21 02:28:15 +00:00
|
|
|
environment, resulting in an Emacs that is still impure but no longer
|
1994-03-21 07:49:21 +00:00
|
|
|
bare.
|
|
|
|
|
|
|
|
It takes a substantial time to load the standard Lisp files. Luckily,
|
|
|
|
you don't have to do this each time you run Emacs; @file{temacs} can
|
1994-05-21 02:28:15 +00:00
|
|
|
dump out an executable program called @file{emacs} that has these files
|
1994-03-21 07:49:21 +00:00
|
|
|
preloaded. @file{emacs} starts more quickly because it does not need to
|
|
|
|
load the files. This is the Emacs executable that is normally
|
|
|
|
installed.
|
|
|
|
|
|
|
|
To create @file{emacs}, use the command @samp{temacs -batch -l loadup
|
|
|
|
dump}. The purpose of @samp{-batch} here is to prevent @file{temacs}
|
|
|
|
from trying to initialize any of its data on the terminal; this ensures
|
|
|
|
that the tables of terminal information are empty in the dumped Emacs.
|
|
|
|
The argument @samp{dump} tells @file{loadup.el} to dump a new executable
|
|
|
|
named @file{emacs}.
|
|
|
|
|
|
|
|
Some operating systems don't support dumping. On those systems, you
|
|
|
|
must start Emacs with the @samp{temacs -l loadup} command each time you
|
1994-04-24 21:47:17 +00:00
|
|
|
use it. This takes a substantial time, but since you need to start
|
|
|
|
Emacs once a day at most---or once a week if you never log out---the
|
|
|
|
extra time is not too severe a problem.
|
1994-03-21 07:49:21 +00:00
|
|
|
|
|
|
|
@cindex @file{site-load.el}
|
|
|
|
You can specify additional files to preload by writing a library named
|
1994-05-21 02:28:15 +00:00
|
|
|
@file{site-load.el} that loads them. You may need to increase the
|
1994-03-21 07:49:21 +00:00
|
|
|
value of @code{PURESIZE}, in @file{src/puresize.h}, to make room for the
|
|
|
|
additional files. (Try adding increments of 20000 until it is big
|
|
|
|
enough.) However, the advantage of preloading additional files
|
|
|
|
decreases as machines get faster. On modern machines, it is usually not
|
|
|
|
advisable.
|
|
|
|
|
|
|
|
@cindex @file{site-init.el}
|
1994-04-24 21:47:17 +00:00
|
|
|
You can specify other Lisp expressions to execute just before dumping
|
|
|
|
by putting them in a library named @file{site-init.el}. However, if
|
|
|
|
they might alter the behavior that users expect from an ordinary
|
|
|
|
unmodified Emacs, it is better to put them in @file{default.el}, so that
|
1994-03-21 07:49:21 +00:00
|
|
|
users can override them if they wish. @xref{Start-up Summary}.
|
|
|
|
|
1994-04-24 21:47:17 +00:00
|
|
|
Before @file{loadup.el} dumps the new executable, it finds the
|
|
|
|
documentation strings for primitive and preloaded functions (and
|
|
|
|
variables) in the file where they are stored, by calling
|
1994-03-21 07:49:21 +00:00
|
|
|
@code{Snarf-documentation} (@pxref{Accessing Documentation}). These
|
1994-04-24 21:47:17 +00:00
|
|
|
strings were moved out of the @file{emacs} executable to make it
|
|
|
|
smaller. @xref{Documentation Basics}.
|
1994-03-21 07:49:21 +00:00
|
|
|
|
|
|
|
@defun dump-emacs to-file from-file
|
|
|
|
@cindex unexec
|
|
|
|
This function dumps the current state of Emacs into an executable file
|
|
|
|
@var{to-file}. It takes symbols from @var{from-file} (this is normally
|
|
|
|
the executable file @file{temacs}).
|
|
|
|
|
|
|
|
If you use this function in an Emacs that was already dumped, you must
|
|
|
|
set @code{command-line-processed} to @code{nil} first for good results.
|
|
|
|
@xref{Command Line Arguments}.
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
@deffn Command emacs-version
|
|
|
|
This function returns a string describing the version of Emacs that is
|
|
|
|
running. It is useful to include this string in bug reports.
|
|
|
|
|
|
|
|
@example
|
|
|
|
@group
|
|
|
|
(emacs-version)
|
1995-06-06 19:21:15 +00:00
|
|
|
@result{} "GNU Emacs 19.29.1 (i386-debian-linux) \
|
|
|
|
of Tue Jun 6 1995 on balloon"
|
1994-03-21 07:49:21 +00:00
|
|
|
@end group
|
|
|
|
@end example
|
|
|
|
|
|
|
|
Called interactively, the function prints the same information in the
|
|
|
|
echo area.
|
|
|
|
@end deffn
|
|
|
|
|
|
|
|
@defvar emacs-build-time
|
1995-06-06 19:21:15 +00:00
|
|
|
The value of this variable is the time at which Emacs was built at the
|
1994-03-21 07:49:21 +00:00
|
|
|
local site.
|
|
|
|
|
|
|
|
@example
|
|
|
|
@group
|
|
|
|
emacs-build-time
|
1995-06-06 19:21:15 +00:00
|
|
|
@result{} "Tue Jun 6 14:55:57 1995"
|
1994-03-21 07:49:21 +00:00
|
|
|
@end group
|
|
|
|
@end example
|
|
|
|
@end defvar
|
|
|
|
|
|
|
|
@defvar emacs-version
|
|
|
|
The value of this variable is the version of Emacs being run. It is a
|
1995-06-06 19:21:15 +00:00
|
|
|
string such as @code{"19.29.1"}.
|
1994-04-24 21:47:17 +00:00
|
|
|
@end defvar
|
|
|
|
|
|
|
|
The following two variables did not exist before Emacs version 19.23,
|
|
|
|
which reduces their usefulness at present, but we hope they will be
|
|
|
|
convenient in the future.
|
|
|
|
|
|
|
|
@defvar emacs-major-version
|
1994-05-21 02:28:15 +00:00
|
|
|
The major version number of Emacs, as an integer. For Emacs version
|
1995-06-06 19:21:15 +00:00
|
|
|
19.29, the value is 19.
|
1994-04-24 21:47:17 +00:00
|
|
|
@end defvar
|
|
|
|
|
|
|
|
@defvar emacs-minor-version
|
|
|
|
The minor version number of Emacs, as an integer. For Emacs version
|
1995-06-06 19:21:15 +00:00
|
|
|
19.29, the value is 29.
|
1994-03-21 07:49:21 +00:00
|
|
|
@end defvar
|
|
|
|
|
|
|
|
@node Pure Storage, Garbage Collection, Building Emacs, GNU Emacs Internals
|
|
|
|
@appendixsec Pure Storage
|
|
|
|
@cindex pure storage
|
|
|
|
|
1994-04-24 21:47:17 +00:00
|
|
|
Emacs Lisp uses two kinds of storage for user-created Lisp objects:
|
|
|
|
@dfn{normal storage} and @dfn{pure storage}. Normal storage is where
|
1994-05-21 02:28:15 +00:00
|
|
|
all the new data created during an Emacs session is kept; see the
|
|
|
|
following section for information on normal storage. Pure storage is
|
|
|
|
used for certain data in the preloaded standard Lisp files---data that
|
|
|
|
should never change during actual use of Emacs.
|
1994-03-21 07:49:21 +00:00
|
|
|
|
|
|
|
Pure storage is allocated only while @file{temacs} is loading the
|
|
|
|
standard preloaded Lisp libraries. In the file @file{emacs}, it is
|
1994-05-21 02:28:15 +00:00
|
|
|
marked as read-only (on operating systems that permit this), so that
|
1994-03-21 07:49:21 +00:00
|
|
|
the memory space can be shared by all the Emacs jobs running on the
|
|
|
|
machine at once. Pure storage is not expandable; a fixed amount is
|
|
|
|
allocated when Emacs is compiled, and if that is not sufficient for the
|
1994-04-24 21:47:17 +00:00
|
|
|
preloaded libraries, @file{temacs} crashes. If that happens, you must
|
|
|
|
increase the compilation parameter @code{PURESIZE} in the file
|
1994-03-21 07:49:21 +00:00
|
|
|
@file{src/puresize.h}. This normally won't happen unless you try to
|
|
|
|
preload additional libraries or add features to the standard ones.
|
|
|
|
|
|
|
|
@defun purecopy object
|
1994-04-24 21:47:17 +00:00
|
|
|
This function makes a copy of @var{object} in pure storage and returns
|
1994-03-21 07:49:21 +00:00
|
|
|
it. It copies strings by simply making a new string with the same
|
|
|
|
characters in pure storage. It recursively copies the contents of
|
1994-04-24 21:47:17 +00:00
|
|
|
vectors and cons cells. It does not make copies of other objects such
|
|
|
|
as symbols, but just returns them unchanged. It signals an error if
|
1994-03-21 07:49:21 +00:00
|
|
|
asked to copy markers.
|
|
|
|
|
1995-03-27 23:39:32 +00:00
|
|
|
This function is a no-op except while Emacs is being built and dumped;
|
|
|
|
it is usually called only in the file @file{emacs/lisp/loaddefs.el}, but
|
|
|
|
a few packages call it just in case you decide to preload them.
|
1994-03-21 07:49:21 +00:00
|
|
|
@end defun
|
|
|
|
|
|
|
|
@defvar pure-bytes-used
|
1994-04-24 21:47:17 +00:00
|
|
|
The value of this variable is the number of bytes of pure storage
|
1994-03-21 07:49:21 +00:00
|
|
|
allocated so far. Typically, in a dumped Emacs, this number is very
|
|
|
|
close to the total amount of pure storage available---if it were not,
|
|
|
|
we would preallocate less.
|
|
|
|
@end defvar
|
|
|
|
|
|
|
|
@defvar purify-flag
|
1994-04-24 21:47:17 +00:00
|
|
|
This variable determines whether @code{defun} should make a copy of the
|
1994-03-21 07:49:21 +00:00
|
|
|
function definition in pure storage. If it is non-@code{nil}, then the
|
|
|
|
function definition is copied into pure storage.
|
|
|
|
|
1994-04-24 21:47:17 +00:00
|
|
|
This flag is @code{t} while loading all of the basic functions for
|
1994-03-21 07:49:21 +00:00
|
|
|
building Emacs initially (allowing those functions to be sharable and
|
1994-04-24 21:47:17 +00:00
|
|
|
non-collectible). Dumping Emacs as an executable always writes
|
|
|
|
@code{nil} in this variable, regardless of the value it actually has
|
|
|
|
before and after dumping.
|
1994-03-21 07:49:21 +00:00
|
|
|
|
1994-04-24 21:47:17 +00:00
|
|
|
You should not change this flag in a running Emacs.
|
1994-03-21 07:49:21 +00:00
|
|
|
@end defvar
|
|
|
|
|
|
|
|
@node Garbage Collection, Writing Emacs Primitives, Pure Storage, GNU Emacs Internals
|
|
|
|
@appendixsec Garbage Collection
|
|
|
|
@cindex garbage collector
|
|
|
|
|
|
|
|
@cindex memory allocation
|
|
|
|
When a program creates a list or the user defines a new function (such
|
1994-04-24 21:47:17 +00:00
|
|
|
as by loading a library), that data is placed in normal storage. If
|
|
|
|
normal storage runs low, then Emacs asks the operating system to
|
1994-03-21 07:49:21 +00:00
|
|
|
allocate more memory in blocks of 1k bytes. Each block is used for one
|
1994-04-24 21:47:17 +00:00
|
|
|
type of Lisp object, so symbols, cons cells, markers, etc., are
|
|
|
|
segregated in distinct blocks in memory. (Vectors, long strings,
|
|
|
|
buffers and certain other editing types, which are fairly large, are
|
|
|
|
allocated in individual blocks, one per object, while small strings are
|
|
|
|
packed into blocks of 8k bytes.)
|
|
|
|
|
|
|
|
It is quite common to use some storage for a while, then release it by
|
|
|
|
(for example) killing a buffer or deleting the last pointer to an
|
1994-03-21 07:49:21 +00:00
|
|
|
object. Emacs provides a @dfn{garbage collector} to reclaim this
|
|
|
|
abandoned storage. (This name is traditional, but ``garbage recycler''
|
|
|
|
might be a more intuitive metaphor for this facility.)
|
|
|
|
|
1994-04-24 21:47:17 +00:00
|
|
|
The garbage collector operates by finding and marking all Lisp objects
|
|
|
|
that are still accessible to Lisp programs. To begin with, it assumes
|
|
|
|
all the symbols, their values and associated function definitions, and
|
1994-05-21 02:28:15 +00:00
|
|
|
any data presently on the stack, are accessible. Any objects that can
|
1994-04-24 21:47:17 +00:00
|
|
|
be reached indirectly through other accessible objects are also
|
|
|
|
accessible.
|
1994-03-21 07:49:21 +00:00
|
|
|
|
1994-04-24 21:47:17 +00:00
|
|
|
When marking is finished, all objects still unmarked are garbage. No
|
1994-03-21 07:49:21 +00:00
|
|
|
matter what the Lisp program or the user does, it is impossible to refer
|
1994-04-24 21:47:17 +00:00
|
|
|
to them, since there is no longer a way to reach them. Their space
|
1994-05-21 02:28:15 +00:00
|
|
|
might as well be reused, since no one will miss them. The second
|
|
|
|
(``sweep'') phase of the garbage collector arranges to reuse them.
|
1994-03-21 07:49:21 +00:00
|
|
|
|
|
|
|
@cindex free list
|
1994-04-24 21:47:17 +00:00
|
|
|
The sweep phase puts unused cons cells onto a @dfn{free list}
|
|
|
|
for future allocation; likewise for symbols and markers. It compacts
|
|
|
|
the accessible strings so they occupy fewer 8k blocks; then it frees the
|
1994-05-21 02:28:15 +00:00
|
|
|
other 8k blocks. Vectors, buffers, windows, and other large objects are
|
1994-04-24 21:47:17 +00:00
|
|
|
individually allocated and freed using @code{malloc} and @code{free}.
|
1994-03-21 07:49:21 +00:00
|
|
|
|
|
|
|
@cindex CL note---allocate more storage
|
|
|
|
@quotation
|
1994-05-21 02:28:15 +00:00
|
|
|
@b{Common Lisp note:} Unlike other Lisps, GNU Emacs Lisp does not
|
1994-03-21 07:49:21 +00:00
|
|
|
call the garbage collector when the free list is empty. Instead, it
|
|
|
|
simply requests the operating system to allocate more storage, and
|
|
|
|
processing continues until @code{gc-cons-threshold} bytes have been
|
|
|
|
used.
|
|
|
|
|
|
|
|
This means that you can make sure that the garbage collector will not
|
|
|
|
run during a certain portion of a Lisp program by calling the garbage
|
|
|
|
collector explicitly just before it (provided that portion of the
|
|
|
|
program does not use so much space as to force a second garbage
|
|
|
|
collection).
|
|
|
|
@end quotation
|
|
|
|
|
|
|
|
@deffn Command garbage-collect
|
1994-04-24 21:47:17 +00:00
|
|
|
This command runs a garbage collection, and returns information on
|
1994-03-21 07:49:21 +00:00
|
|
|
the amount of space in use. (Garbage collection can also occur
|
|
|
|
spontaneously if you use more than @code{gc-cons-threshold} bytes of
|
|
|
|
Lisp data since the previous garbage collection.)
|
|
|
|
|
1994-04-24 21:47:17 +00:00
|
|
|
@code{garbage-collect} returns a list containing the following
|
1994-03-21 07:49:21 +00:00
|
|
|
information:
|
|
|
|
|
1994-04-24 21:47:17 +00:00
|
|
|
@example
|
1994-03-21 07:49:21 +00:00
|
|
|
@group
|
|
|
|
((@var{used-conses} . @var{free-conses})
|
|
|
|
(@var{used-syms} . @var{free-syms})
|
1994-04-24 21:47:17 +00:00
|
|
|
@end group
|
1994-03-21 07:49:21 +00:00
|
|
|
(@var{used-markers} . @var{free-markers})
|
|
|
|
@var{used-string-chars}
|
|
|
|
@var{used-vector-slots}
|
|
|
|
(@var{used-floats} . @var{free-floats}))
|
|
|
|
|
1994-04-24 21:47:17 +00:00
|
|
|
@group
|
1994-03-21 07:49:21 +00:00
|
|
|
(garbage-collect)
|
|
|
|
@result{} ((3435 . 2332) (1688 . 0)
|
|
|
|
(57 . 417) 24510 3839 (4 . 1))
|
|
|
|
@end group
|
1994-04-24 21:47:17 +00:00
|
|
|
@end example
|
1994-03-21 07:49:21 +00:00
|
|
|
|
|
|
|
Here is a table explaining each element:
|
|
|
|
|
|
|
|
@table @var
|
|
|
|
@item used-conses
|
|
|
|
The number of cons cells in use.
|
|
|
|
|
|
|
|
@item free-conses
|
|
|
|
The number of cons cells for which space has been obtained from the
|
|
|
|
operating system, but that are not currently being used.
|
|
|
|
|
|
|
|
@item used-syms
|
|
|
|
The number of symbols in use.
|
|
|
|
|
|
|
|
@item free-syms
|
|
|
|
The number of symbols for which space has been obtained from the
|
|
|
|
operating system, but that are not currently being used.
|
|
|
|
|
|
|
|
@item used-markers
|
|
|
|
The number of markers in use.
|
|
|
|
|
|
|
|
@item free-markers
|
|
|
|
The number of markers for which space has been obtained from the
|
|
|
|
operating system, but that are not currently being used.
|
|
|
|
|
|
|
|
@item used-string-chars
|
|
|
|
The total size of all strings, in characters.
|
|
|
|
|
|
|
|
@item used-vector-slots
|
|
|
|
The total number of elements of existing vectors.
|
|
|
|
|
|
|
|
@item used-floats
|
|
|
|
@c Emacs 19 feature
|
|
|
|
The number of floats in use.
|
|
|
|
|
|
|
|
@item free-floats
|
|
|
|
@c Emacs 19 feature
|
|
|
|
The number of floats for which space has been obtained from the
|
|
|
|
operating system, but that are not currently being used.
|
|
|
|
@end table
|
|
|
|
@end deffn
|
|
|
|
|
|
|
|
@defopt gc-cons-threshold
|
1994-04-24 21:47:17 +00:00
|
|
|
The value of this variable is the number of bytes of storage that must
|
1994-03-21 07:49:21 +00:00
|
|
|
be allocated for Lisp objects after one garbage collection in order to
|
1994-04-24 21:47:17 +00:00
|
|
|
trigger another garbage collection. A cons cell counts as eight bytes,
|
1994-03-21 07:49:21 +00:00
|
|
|
a string as one byte per character plus a few bytes of overhead, and so
|
1994-04-24 21:47:17 +00:00
|
|
|
on; space allocated to the contents of buffers does not count. Note
|
|
|
|
that the subsequent garbage collection does not happen immediately when
|
|
|
|
the threshold is exhausted, but only the next time the Lisp evaluator is
|
1994-03-21 07:49:21 +00:00
|
|
|
called.
|
|
|
|
|
1995-06-06 19:21:15 +00:00
|
|
|
The initial threshold value is 300,000. If you specify a larger
|
1994-03-21 07:49:21 +00:00
|
|
|
value, garbage collection will happen less often. This reduces the
|
|
|
|
amount of time spent garbage collecting, but increases total memory use.
|
1994-05-21 02:28:15 +00:00
|
|
|
You may want to do this when running a program that creates lots of
|
1994-03-21 07:49:21 +00:00
|
|
|
Lisp data.
|
|
|
|
|
1994-04-24 21:47:17 +00:00
|
|
|
You can make collections more frequent by specifying a smaller value,
|
1994-03-21 07:49:21 +00:00
|
|
|
down to 10,000. A value less than 10,000 will remain in effect only
|
|
|
|
until the subsequent garbage collection, at which time
|
|
|
|
@code{garbage-collect} will set the threshold back to 10,000.
|
|
|
|
@end defopt
|
|
|
|
|
|
|
|
@c Emacs 19 feature
|
|
|
|
@defun memory-limit
|
|
|
|
This function returns the address of the last byte Emacs has allocated,
|
|
|
|
divided by 1024. We divide the value by 1024 to make sure it fits in a
|
|
|
|
Lisp integer.
|
|
|
|
|
|
|
|
You can use this to get a general idea of how your actions affect the
|
|
|
|
memory usage.
|
|
|
|
@end defun
|
|
|
|
|
|
|
|
@node Writing Emacs Primitives, Object Internals, Garbage Collection, GNU Emacs Internals
|
|
|
|
@appendixsec Writing Emacs Primitives
|
|
|
|
@cindex primitive function 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 @code{or}, from
|
|
|
|
@file{eval.c}. (An ordinary function would have the same general
|
|
|
|
appearance.)
|
|
|
|
|
|
|
|
@cindex garbage collection protection
|
|
|
|
@smallexample
|
|
|
|
@group
|
|
|
|
DEFUN ("or", For, Sor, 0, UNEVALLED, 0,
|
1994-04-24 21:47:17 +00:00
|
|
|
"Eval args until one of them yields non-nil, then return that value.\n\
|
1994-03-21 07:49:21 +00:00
|
|
|
The remaining args are not evalled at all.\n\
|
|
|
|
@end group
|
|
|
|
@group
|
1994-04-24 21:47:17 +00:00
|
|
|
If all args return nil, return nil.")
|
1994-03-21 07:49:21 +00:00
|
|
|
(args)
|
|
|
|
Lisp_Object args;
|
|
|
|
@{
|
|
|
|
register Lisp_Object val;
|
|
|
|
Lisp_Object args_left;
|
|
|
|
struct gcpro gcpro1;
|
|
|
|
@end group
|
|
|
|
|
|
|
|
@group
|
1994-04-24 21:47:17 +00:00
|
|
|
if (NULL (args))
|
1994-03-21 07:49:21 +00:00
|
|
|
return Qnil;
|
|
|
|
|
|
|
|
args_left = args;
|
|
|
|
GCPRO1 (args_left);
|
|
|
|
@end group
|
|
|
|
|
|
|
|
@group
|
|
|
|
do
|
|
|
|
@{
|
|
|
|
val = Feval (Fcar (args_left));
|
|
|
|
if (!NULL (val))
|
|
|
|
break;
|
|
|
|
args_left = Fcdr (args_left);
|
|
|
|
@}
|
1994-04-24 21:47:17 +00:00
|
|
|
while (!NULL (args_left));
|
1994-03-21 07:49:21 +00:00
|
|
|
@end group
|
|
|
|
|
|
|
|
@group
|
|
|
|
UNGCPRO;
|
|
|
|
return val;
|
|
|
|
@}
|
|
|
|
@end group
|
|
|
|
@end smallexample
|
|
|
|
|
|
|
|
Let's start with a precise explanation of the arguments to the
|
1994-04-24 21:47:17 +00:00
|
|
|
@code{DEFUN} macro. Here is a template for them:
|
1994-03-21 07:49:21 +00:00
|
|
|
|
|
|
|
@example
|
|
|
|
DEFUN (@var{lname}, @var{fname}, @var{sname}, @var{min}, @var{max}, @var{interactive}, @var{doc})
|
|
|
|
@end example
|
|
|
|
|
|
|
|
@table @var
|
|
|
|
@item lname
|
1994-04-24 21:47:17 +00:00
|
|
|
This is the name of the Lisp symbol to define as the function name; in
|
|
|
|
the example above, it is @code{or}.
|
1994-03-21 07:49:21 +00:00
|
|
|
|
|
|
|
@item fname
|
|
|
|
This is the C function name for this function. This is
|
|
|
|
the name that is used in C code for calling the function. The name is,
|
|
|
|
by convention, @samp{F} prepended to the Lisp name, with all dashes
|
|
|
|
(@samp{-}) in the Lisp name changed to underscores. Thus, to call this
|
|
|
|
function from C code, call @code{For}. Remember that the arguments must
|
|
|
|
be of type @code{Lisp_Object}; various macros and functions for creating
|
|
|
|
values of type @code{Lisp_Object} are declared in the file
|
|
|
|
@file{lisp.h}.
|
|
|
|
|
|
|
|
@item sname
|
|
|
|
This is a C variable name to use for a structure that holds the data for
|
|
|
|
the subr object that represents the function in Lisp. This structure
|
|
|
|
conveys the Lisp symbol name to the initialization routine that will
|
|
|
|
create the symbol and store the subr object as its definition. By
|
|
|
|
convention, this name is always @var{fname} with @samp{F} replaced with
|
|
|
|
@samp{S}.
|
|
|
|
|
|
|
|
@item min
|
1994-04-24 21:47:17 +00:00
|
|
|
This is the minimum number of arguments that the function requires. The
|
|
|
|
function @code{or} allows a minimum of zero arguments.
|
1994-03-21 07:49:21 +00:00
|
|
|
|
|
|
|
@item max
|
1994-04-24 21:47:17 +00:00
|
|
|
This is the maximum number of arguments that the function accepts, if
|
|
|
|
there is a fixed maximum. Alternatively, it can be @code{UNEVALLED},
|
|
|
|
indicating a special form that receives unevaluated arguments, or
|
|
|
|
@code{MANY}, indicating an unlimited number of evaluated arguments (the
|
|
|
|
equivalent of @code{&rest}). Both @code{UNEVALLED} and @code{MANY} are
|
|
|
|
macros. If @var{max} is a number, it may not be less than @var{min} and
|
|
|
|
it may not be greater than seven.
|
1994-03-21 07:49:21 +00:00
|
|
|
|
|
|
|
@item interactive
|
|
|
|
This is an interactive specification, a string such as might be used as
|
|
|
|
the argument of @code{interactive} in a Lisp function. In the case of
|
|
|
|
@code{or}, it is 0 (a null pointer), indicating that @code{or} cannot be
|
1994-04-24 21:47:17 +00:00
|
|
|
called interactively. A value of @code{""} indicates a function that
|
|
|
|
should receive no arguments when called interactively.
|
1994-03-21 07:49:21 +00:00
|
|
|
|
|
|
|
@item doc
|
|
|
|
This is the documentation string. It is written just like a
|
|
|
|
documentation string for a function defined in Lisp, except you must
|
|
|
|
write @samp{\n\} at the end of each line. In particular, the first line
|
|
|
|
should be a single sentence.
|
|
|
|
@end table
|
|
|
|
|
1994-04-24 21:47:17 +00:00
|
|
|
After the call to the @code{DEFUN} macro, you must write the argument
|
|
|
|
name list that every C function must have, followed by ordinary C
|
|
|
|
declarations for the arguments. For a function with a fixed maximum
|
|
|
|
number of arguments, declare a C argument for each Lisp argument, and
|
1994-05-21 02:28:15 +00:00
|
|
|
give them all type @code{Lisp_Object}. When a Lisp function has no
|
|
|
|
upper limit on the number of arguments, its implementation in C actually
|
|
|
|
receives exactly two arguments: the first is the number of Lisp
|
|
|
|
arguments, and the second is the address of a block containing their
|
|
|
|
values. They have types @code{int} and @w{@code{Lisp_Object *}}.
|
1994-03-21 07:49:21 +00:00
|
|
|
|
|
|
|
Within the function @code{For} itself, note the use of the macros
|
|
|
|
@code{GCPRO1} and @code{UNGCPRO}. @code{GCPRO1} is used to ``protect''
|
|
|
|
a variable from garbage collection---to inform the garbage collector that
|
|
|
|
it must look in that variable and regard its contents as an accessible
|
|
|
|
object. This is necessary whenever you call @code{Feval} or anything
|
|
|
|
that can directly or indirectly call @code{Feval}. At such a time, any
|
|
|
|
Lisp object that you intend to refer to again must be protected somehow.
|
|
|
|
@code{UNGCPRO} cancels the protection of the variables that are
|
|
|
|
protected in the current function. It is necessary to do this explicitly.
|
|
|
|
|
1994-04-24 21:47:17 +00:00
|
|
|
For most data types, it suffices to protect at least one pointer to
|
|
|
|
the object; as long as the object is not recycled, all pointers to it
|
|
|
|
remain valid. This is not so for strings, because the garbage collector
|
|
|
|
can move them. When the garbage collector moves a string, it relocates
|
|
|
|
all the pointers it knows about; any other pointers become invalid.
|
|
|
|
Therefore, you must protect all pointers to strings across any point
|
|
|
|
where garbage collection may be possible.
|
|
|
|
|
|
|
|
The macro @code{GCPRO1} protects just one local variable. If you want
|
|
|
|
to protect two, use @code{GCPRO2} instead; repeating @code{GCPRO1} will
|
|
|
|
not work. Macros @code{GCPRO3} and @code{GCPRO4} also exist.
|
|
|
|
|
|
|
|
These macros implicitly use local variables such as @code{gcpro1}; you
|
|
|
|
must declare these explicitly, with type @code{struct gcpro}. Thus, if
|
|
|
|
you use @code{GCPRO2}, you must declare @code{gcpro1} and @code{gcpro2}.
|
|
|
|
Alas, we can't explain all the tricky details here.
|
|
|
|
|
1995-01-20 00:57:39 +00:00
|
|
|
You must not use C initializers for static or global variables unless
|
|
|
|
they 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. @xref{Pure
|
|
|
|
Storage}.
|
|
|
|
|
|
|
|
Do not use static variables within functions---place all static
|
|
|
|
variables at top level in the file. This is necessary because Emacs on
|
|
|
|
some operating systems defines the keyword @code{static} as a null
|
|
|
|
macro. (This definition is used because those systems put all variables
|
|
|
|
declared static in a place that becomes read-only after dumping, whether
|
|
|
|
they have initializers or not.)
|
1995-01-19 07:25:03 +00:00
|
|
|
|
1994-04-24 21:47:17 +00:00
|
|
|
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:
|
1994-03-21 07:49:21 +00:00
|
|
|
|
|
|
|
@example
|
|
|
|
defsubr (&@var{subr-structure-name});
|
|
|
|
@end example
|
|
|
|
|
|
|
|
@noindent
|
1994-04-24 21:47:17 +00:00
|
|
|
Here @var{subr-structure-name} is the name you used as the third
|
|
|
|
argument to @code{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
|
|
|
|
@code{syms_of_@var{something}}, and add the call to @code{defsubr}
|
|
|
|
there. If the file doesn't have this function, or if you create a new
|
|
|
|
file, add to it a @code{syms_of_@var{filename}} (e.g.,
|
|
|
|
@code{syms_of_myfile}). Then find the spot in @file{emacs.c} where all
|
|
|
|
of these functions are called, and add a call to
|
|
|
|
@code{syms_of_@var{filename}} there.
|
1994-03-21 07:49:21 +00:00
|
|
|
|
1994-05-21 02:28:15 +00:00
|
|
|
The function @code{syms_of_@var{filename}} is also the place to define
|
|
|
|
any C variables that are to be visible as Lisp variables.
|
1994-04-24 21:47:17 +00:00
|
|
|
@code{DEFVAR_LISP} makes a C variable of type @code{Lisp_Object} visible
|
|
|
|
in Lisp. @code{DEFVAR_INT} makes a C variable of type @code{int}
|
|
|
|
visible in Lisp with a value that is always an integer.
|
|
|
|
@code{DEFVAR_BOOL} makes a C variable of type @code{int} visible in Lisp
|
|
|
|
with a value that is either @code{t} or @code{nil}.
|
1994-03-21 07:49:21 +00:00
|
|
|
|
1994-04-24 21:47:17 +00:00
|
|
|
Here is another example function, with more complicated arguments.
|
|
|
|
This comes from the code for the X Window System, and it demonstrates
|
|
|
|
the use of macros and functions to manipulate Lisp objects.
|
1994-03-21 07:49:21 +00:00
|
|
|
|
|
|
|
@smallexample
|
|
|
|
@group
|
|
|
|
DEFUN ("coordinates-in-window-p", Fcoordinates_in_window_p,
|
|
|
|
Scoordinates_in_window_p, 2, 2,
|
|
|
|
"xSpecify coordinate pair: \nXExpression which evals to window: ",
|
|
|
|
"Return non-nil if POSITIONS is in WINDOW.\n\
|
|
|
|
\(POSITIONS is a list, (SCREEN-X SCREEN-Y)\)\n\
|
|
|
|
@end group
|
|
|
|
@group
|
|
|
|
Returned value is list of positions expressed\n\
|
|
|
|
relative to window upper left corner.")
|
|
|
|
(coordinate, window)
|
|
|
|
register Lisp_Object coordinate, window;
|
|
|
|
@{
|
|
|
|
register Lisp_Object xcoord, ycoord;
|
|
|
|
@end group
|
|
|
|
|
|
|
|
@group
|
|
|
|
if (!CONSP (coordinate)) wrong_type_argument (Qlistp, coordinate);
|
|
|
|
CHECK_WINDOW (window, 2);
|
|
|
|
xcoord = Fcar (coordinate);
|
|
|
|
ycoord = Fcar (Fcdr (coordinate));
|
|
|
|
CHECK_NUMBER (xcoord, 0);
|
|
|
|
CHECK_NUMBER (ycoord, 1);
|
|
|
|
@end group
|
|
|
|
@group
|
|
|
|
if ((XINT (xcoord) < XINT (XWINDOW (window)->left))
|
|
|
|
|| (XINT (xcoord) >= (XINT (XWINDOW (window)->left)
|
|
|
|
+ XINT (XWINDOW (window)->width))))
|
1994-04-24 21:47:17 +00:00
|
|
|
return Qnil;
|
1994-03-21 07:49:21 +00:00
|
|
|
XFASTINT (xcoord) -= XFASTINT (XWINDOW (window)->left);
|
|
|
|
@end group
|
|
|
|
@group
|
|
|
|
if (XINT (ycoord) == (screen_height - 1))
|
|
|
|
return Qnil;
|
|
|
|
@end group
|
|
|
|
@group
|
|
|
|
if ((XINT (ycoord) < XINT (XWINDOW (window)->top))
|
|
|
|
|| (XINT (ycoord) >= (XINT (XWINDOW (window)->top)
|
|
|
|
+ XINT (XWINDOW (window)->height)) - 1))
|
1994-04-24 21:47:17 +00:00
|
|
|
return Qnil;
|
1994-03-21 07:49:21 +00:00
|
|
|
@end group
|
|
|
|
@group
|
|
|
|
XFASTINT (ycoord) -= XFASTINT (XWINDOW (window)->top);
|
|
|
|
return (Fcons (xcoord, Fcons (ycoord, Qnil)));
|
|
|
|
@}
|
|
|
|
@end group
|
|
|
|
@end smallexample
|
|
|
|
|
1994-04-24 21:47:17 +00:00
|
|
|
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
|
|
|
|
@code{Ffuncall}, which embodies the Lisp function @code{funcall}. Since
|
|
|
|
the Lisp function @code{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. Since @code{Ffuncall} can call the evaluator, you must
|
|
|
|
protect pointers from garbage collection around the call to
|
|
|
|
@code{Ffuncall}.
|
|
|
|
|
|
|
|
The C functions @code{call0}, @code{call1}, @code{call2}, and so on,
|
|
|
|
provide handy ways to call a Lisp function conveniently with a fixed
|
|
|
|
number of arguments. They work by calling @code{Ffuncall}.
|
1994-03-21 07:49:21 +00:00
|
|
|
|
|
|
|
@file{eval.c} is a very good file to look through for examples;
|
|
|
|
@file{lisp.h} contains the definitions for some important macros and
|
|
|
|
functions.
|
|
|
|
|
|
|
|
@node Object Internals, , Writing Emacs Primitives, GNU Emacs Internals
|
|
|
|
@appendixsec Object Internals
|
|
|
|
@cindex object internals
|
|
|
|
|
|
|
|
GNU Emacs Lisp manipulates many different types of data. The actual
|
|
|
|
data are stored in a heap and the only access that programs have to it is
|
|
|
|
through pointers. Pointers are thirty-two bits wide in most
|
|
|
|
implementations. Depending on the operating system and type of machine
|
|
|
|
for which you compile Emacs, twenty-four to twenty-six bits are used to
|
|
|
|
address the object, and the remaining six to eight bits are used for a
|
|
|
|
tag that identifies the object's type.
|
|
|
|
|
1994-04-24 21:47:17 +00:00
|
|
|
Because Lisp objects are represented as tagged pointers, it is always
|
|
|
|
possible to determine the Lisp data type of any object. The C data type
|
|
|
|
@code{Lisp_Object} can hold any Lisp object of any data type. Ordinary
|
|
|
|
variables have type @code{Lisp_Object}, which means they can hold any
|
|
|
|
type of Lisp value; you can determine the actual data type only at run
|
|
|
|
time. The same is true for function arguments; if you want a function
|
|
|
|
to accept only a certain type of argument, you must check the type
|
|
|
|
explicitly using a suitable predicate (@pxref{Type Predicates}).
|
1994-03-21 07:49:21 +00:00
|
|
|
@cindex type checking internals
|
|
|
|
|
|
|
|
@menu
|
|
|
|
* Buffer Internals:: Components of a buffer structure.
|
|
|
|
* Window Internals:: Components of a window structure.
|
|
|
|
* Process Internals:: Components of a process structure.
|
|
|
|
@end menu
|
|
|
|
|
|
|
|
@node Buffer Internals, Window Internals, Object Internals, Object Internals
|
|
|
|
@appendixsubsec Buffer Internals
|
|
|
|
@cindex internals, of buffer
|
|
|
|
@cindex buffer internals
|
|
|
|
|
|
|
|
Buffers contain fields not directly accessible by the Lisp programmer.
|
|
|
|
We describe them here, naming them by the names used in the C code.
|
|
|
|
Many are accessible indirectly in Lisp programs via Lisp primitives.
|
|
|
|
|
|
|
|
@table @code
|
|
|
|
@item name
|
1994-05-21 02:28:15 +00:00
|
|
|
The buffer name is a string that names the buffer. It is guaranteed to
|
1994-03-21 07:49:21 +00:00
|
|
|
be unique. @xref{Buffer Names}.
|
|
|
|
|
|
|
|
@item save_modified
|
|
|
|
This field contains the time when the buffer was last saved, as an integer.
|
|
|
|
@xref{Buffer Modification}.
|
|
|
|
|
|
|
|
@item modtime
|
|
|
|
This field contains the modification time of the visited file. It is
|
|
|
|
set when the file is written or read. Every time the buffer is written
|
|
|
|
to the file, this field is compared to the modification time of the
|
|
|
|
file. @xref{Buffer Modification}.
|
|
|
|
|
|
|
|
@item auto_save_modified
|
|
|
|
This field contains the time when the buffer was last auto-saved.
|
|
|
|
|
|
|
|
@item last_window_start
|
|
|
|
This field contains the @code{window-start} position in the buffer as of
|
|
|
|
the last time the buffer was displayed in a window.
|
|
|
|
|
1994-04-24 21:47:17 +00:00
|
|
|
@item undo_list
|
|
|
|
This field points to the buffer's undo list. @xref{Undo}.
|
1994-03-21 07:49:21 +00:00
|
|
|
|
|
|
|
@item syntax_table_v
|
|
|
|
This field contains the syntax table for the buffer. @xref{Syntax Tables}.
|
|
|
|
|
|
|
|
@item downcase_table
|
|
|
|
This field contains the conversion table for converting text to lower case.
|
|
|
|
@xref{Case Table}.
|
|
|
|
|
|
|
|
@item upcase_table
|
|
|
|
This field contains the conversion table for converting text to upper case.
|
|
|
|
@xref{Case Table}.
|
|
|
|
|
|
|
|
@item case_canon_table
|
|
|
|
This field contains the conversion table for canonicalizing text for
|
|
|
|
case-folding search. @xref{Case Table}.
|
|
|
|
|
|
|
|
@item case_eqv_table
|
|
|
|
This field contains the equivalence table for case-folding search.
|
|
|
|
@xref{Case Table}.
|
|
|
|
|
|
|
|
@item display_table
|
|
|
|
This field contains the buffer's display table, or @code{nil} if it doesn't
|
|
|
|
have one. @xref{Display Tables}.
|
|
|
|
|
|
|
|
@item markers
|
1994-04-24 21:47:17 +00:00
|
|
|
This field contains the chain of all markers that currently point into
|
|
|
|
the buffer. Deletion of text in the buffer, and motion of the buffer's
|
|
|
|
gap, must check each of these markers and perhaps update it.
|
|
|
|
@xref{Markers}.
|
1994-03-21 07:49:21 +00:00
|
|
|
|
|
|
|
@item backed_up
|
1994-05-21 02:28:15 +00:00
|
|
|
This field is a flag that tells whether a backup file has been made
|
1994-03-21 07:49:21 +00:00
|
|
|
for the visited file of this buffer.
|
|
|
|
|
|
|
|
@item mark
|
|
|
|
This field contains the mark for the buffer. The mark is a marker,
|
|
|
|
hence it is also included on the list @code{markers}. @xref{The Mark}.
|
|
|
|
|
1994-04-24 21:47:17 +00:00
|
|
|
@item mark_active
|
|
|
|
This field is non-@code{nil} if the buffer's mark is active.
|
|
|
|
|
1994-03-21 07:49:21 +00:00
|
|
|
@item local_var_alist
|
1994-04-24 21:47:17 +00:00
|
|
|
This field contains the association list describing the variables local
|
|
|
|
in this buffer, and their values, with the exception of local variables
|
|
|
|
that have special slots in the buffer object. (Those slots are omitted
|
|
|
|
from this table.) @xref{Buffer-Local Variables}.
|
|
|
|
|
1995-06-06 19:21:15 +00:00
|
|
|
@item base_buffer
|
|
|
|
This field holds the buffer's base buffer (if it is an indirect buffer),
|
|
|
|
or @code{nil}.
|
|
|
|
|
1994-04-24 21:47:17 +00:00
|
|
|
@item keymap
|
|
|
|
This field holds the buffer's local keymap. @xref{Keymaps}.
|
|
|
|
|
|
|
|
@item overlay_center
|
|
|
|
This field holds the current overlay center position. @xref{Overlays}.
|
|
|
|
|
|
|
|
@item overlays_before
|
|
|
|
This field holds a list of the overlays in this buffer that end at or
|
|
|
|
before the current overlay center position. They are sorted in order of
|
|
|
|
decreasing end position.
|
|
|
|
|
|
|
|
@item overlays_after
|
|
|
|
This field holds a list of the overlays in this buffer that end after
|
|
|
|
the current overlay center position. They are sorted in order of
|
|
|
|
increasing beginning position.
|
1994-03-21 07:49:21 +00:00
|
|
|
@end table
|
|
|
|
|
|
|
|
@node Window Internals, Process Internals, Buffer Internals, Object Internals
|
|
|
|
@appendixsubsec Window Internals
|
|
|
|
@cindex internals, of window
|
|
|
|
@cindex window internals
|
|
|
|
|
|
|
|
Windows have the following accessible fields:
|
|
|
|
|
|
|
|
@table @code
|
|
|
|
@item frame
|
1994-04-24 21:47:17 +00:00
|
|
|
The frame that this window is on.
|
1994-03-21 07:49:21 +00:00
|
|
|
|
|
|
|
@item mini_p
|
1994-04-24 21:47:17 +00:00
|
|
|
Non-@code{nil} if this window is a minibuffer window.
|
1994-03-21 07:49:21 +00:00
|
|
|
|
|
|
|
@item buffer
|
1994-05-21 02:28:15 +00:00
|
|
|
The buffer that the window is displaying. This may change often during
|
1994-03-21 07:49:21 +00:00
|
|
|
the life of the window.
|
|
|
|
|
|
|
|
@item dedicated
|
1994-04-24 21:47:17 +00:00
|
|
|
Non-@code{nil} if this window is dedicated to its buffer.
|
1994-03-21 07:49:21 +00:00
|
|
|
|
|
|
|
@item pointm
|
|
|
|
@cindex window point internals
|
1994-04-24 21:47:17 +00:00
|
|
|
This is the value of point in the current buffer when this window is
|
1994-03-21 07:49:21 +00:00
|
|
|
selected; when it is not selected, it retains its previous value.
|
|
|
|
|
1994-04-24 21:47:17 +00:00
|
|
|
@item start
|
1994-05-21 02:28:15 +00:00
|
|
|
The position in the buffer that is the first character to be displayed
|
1994-04-24 21:47:17 +00:00
|
|
|
in the window.
|
|
|
|
|
|
|
|
@item force_start
|
|
|
|
If this flag is non-@code{nil}, it says that the window has been
|
|
|
|
scrolled explicitly by the Lisp program. This affects what the next
|
|
|
|
redisplay does if point is off the screen: instead of scrolling the
|
|
|
|
window to show the text around point, it moves point to a location that
|
|
|
|
is on the screen.
|
|
|
|
|
|
|
|
@item last_modified
|
|
|
|
The @code{modified} field of the window's buffer, as of the last time
|
|
|
|
a redisplay completed in this window.
|
|
|
|
|
|
|
|
@item last_point
|
|
|
|
The buffer's value of point, as of the last time
|
|
|
|
a redisplay completed in this window.
|
|
|
|
|
1994-03-21 07:49:21 +00:00
|
|
|
@item left
|
1994-04-24 21:47:17 +00:00
|
|
|
This is the left-hand edge of the window, measured in columns. (The
|
1994-03-21 07:49:21 +00:00
|
|
|
leftmost column on the screen is @w{column 0}.)
|
|
|
|
|
|
|
|
@item top
|
1994-04-24 21:47:17 +00:00
|
|
|
This is the top edge of the window, measured in lines. (The top line on
|
1994-03-21 07:49:21 +00:00
|
|
|
the screen is @w{line 0}.)
|
|
|
|
|
1994-04-24 21:47:17 +00:00
|
|
|
@item height
|
|
|
|
The height of the window, measured in lines.
|
|
|
|
|
|
|
|
@item width
|
|
|
|
The width of the window, measured in columns.
|
|
|
|
|
1994-03-21 07:49:21 +00:00
|
|
|
@item next
|
1994-04-24 21:47:17 +00:00
|
|
|
This is the window that is the next in the chain of siblings. It is
|
|
|
|
@code{nil} in a window that is the rightmost or bottommost of a group of
|
|
|
|
siblings.
|
1994-03-21 07:49:21 +00:00
|
|
|
|
|
|
|
@item prev
|
1994-04-24 21:47:17 +00:00
|
|
|
This is the window that is the previous in the chain of siblings. It is
|
|
|
|
@code{nil} in a window that is the leftmost or topmost of a group of
|
|
|
|
siblings.
|
1994-03-21 07:49:21 +00:00
|
|
|
|
1994-04-24 21:47:17 +00:00
|
|
|
@item parent
|
|
|
|
Internally, Emacs arranges windows in a tree; each group of siblings has
|
|
|
|
a parent window whose area includes all the siblings. This field points
|
|
|
|
to a window's parent.
|
|
|
|
|
|
|
|
Parent windows do not display buffers, and play little role in display
|
|
|
|
except to shape their child windows. Emacs Lisp programs usually have
|
|
|
|
no access to the parent windows; they operate on the windows at the
|
1994-05-21 02:28:15 +00:00
|
|
|
leaves of the tree, which actually display buffers.
|
1994-03-21 07:49:21 +00:00
|
|
|
|
|
|
|
@item hscroll
|
1994-04-24 21:47:17 +00:00
|
|
|
This is the number of columns that the display in the window is scrolled
|
1994-03-21 07:49:21 +00:00
|
|
|
horizontally to the left. Normally, this is 0.
|
|
|
|
|
|
|
|
@item use_time
|
1994-04-24 21:47:17 +00:00
|
|
|
This is the last time that the window was selected. The function
|
1994-03-21 07:49:21 +00:00
|
|
|
@code{get-lru-window} uses this field.
|
|
|
|
|
|
|
|
@item display_table
|
1994-04-24 21:47:17 +00:00
|
|
|
The window's display table, or @code{nil} if none is specified for it.
|
|
|
|
|
|
|
|
@item update_mode_line
|
|
|
|
Non-@code{nil} means this window's mode line needs to be updated.
|
|
|
|
|
|
|
|
@item base_line_number
|
|
|
|
The line number of a certain position in the buffer, or @code{nil}.
|
|
|
|
This is used for displaying the line number of point in the mode line.
|
|
|
|
|
|
|
|
@item base_line_pos
|
|
|
|
The position in the buffer for which the line number is known, or
|
|
|
|
@code{nil} meaning none is known.
|
|
|
|
|
|
|
|
@item region_showing
|
|
|
|
If the region (or part of it) is highlighted in this window, this field
|
|
|
|
holds the mark position that made one end of that region. Otherwise,
|
|
|
|
this field is @code{nil}.
|
1994-03-21 07:49:21 +00:00
|
|
|
@end table
|
|
|
|
|
|
|
|
@node Process Internals, , Window Internals, Object Internals
|
|
|
|
@appendixsubsec Process Internals
|
|
|
|
@cindex internals, of process
|
|
|
|
@cindex process internals
|
|
|
|
|
|
|
|
The fields of a process are:
|
|
|
|
|
|
|
|
@table @code
|
|
|
|
@item name
|
|
|
|
A string, the name of the process.
|
|
|
|
|
|
|
|
@item command
|
|
|
|
A list containing the command arguments that were used to start this
|
|
|
|
process.
|
|
|
|
|
|
|
|
@item filter
|
|
|
|
A function used to accept output from the process instead of a buffer,
|
|
|
|
or @code{nil}.
|
|
|
|
|
|
|
|
@item sentinel
|
|
|
|
A function called whenever the process receives a signal, or @code{nil}.
|
|
|
|
|
|
|
|
@item buffer
|
|
|
|
The associated buffer of the process.
|
|
|
|
|
|
|
|
@item pid
|
|
|
|
An integer, the Unix process @sc{id}.
|
|
|
|
|
|
|
|
@item childp
|
|
|
|
A flag, non-@code{nil} if this is really a child process.
|
|
|
|
It is @code{nil} for a network connection.
|
|
|
|
|
|
|
|
@item mark
|
1994-05-21 02:28:15 +00:00
|
|
|
A marker indicating the position of the end of the last output from this
|
|
|
|
process inserted into the buffer. This is often but not always the end
|
|
|
|
of the buffer.
|
1994-03-21 07:49:21 +00:00
|
|
|
|
|
|
|
@item kill_without_query
|
1994-04-24 21:47:17 +00:00
|
|
|
If this is non-@code{nil}, killing Emacs while this process is still
|
|
|
|
running does not ask for confirmation about killing the process.
|
|
|
|
|
|
|
|
@item raw_status_low
|
|
|
|
@itemx raw_status_high
|
|
|
|
These two fields record 16 bits each of the process status returned by
|
|
|
|
the @code{wait} system call.
|
|
|
|
|
|
|
|
@item status
|
|
|
|
The process status, as @code{process-status} should return it.
|
|
|
|
|
|
|
|
@item tick
|
|
|
|
@itemx update_tick
|
|
|
|
If these two fields are not equal, a change in the status of the process
|
|
|
|
needs to be reported, either by running the sentinel or by inserting a
|
|
|
|
message in the process buffer.
|
|
|
|
|
|
|
|
@item pty_flag
|
|
|
|
Non-@code{nil} if communication with the subprocess uses a @sc{pty};
|
|
|
|
@code{nil} if it uses a pipe.
|
|
|
|
|
|
|
|
@item infd
|
|
|
|
The file descriptor for input from the process.
|
|
|
|
|
|
|
|
@item outfd
|
|
|
|
The file descriptor for output to the process.
|
|
|
|
|
|
|
|
@item subtty
|
|
|
|
The file descriptor for the terminal that the subprocess is using. (On
|
|
|
|
some systems, there is no need to record this, so the value is
|
|
|
|
@code{nil}.)
|
1995-06-06 19:21:15 +00:00
|
|
|
|
|
|
|
@item tty_name
|
|
|
|
The name of the terminal that the subprocess is using,
|
|
|
|
or @code{nil} if it is using pipes.
|
1994-03-21 07:49:21 +00:00
|
|
|
@end table
|