[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Emacs-diffs] Changes to internals.texi
|
From: |
Glenn Morris |
|
Subject: |
[Emacs-diffs] Changes to internals.texi |
|
Date: |
Thu, 06 Sep 2007 04:11:59 +0000 |
CVSROOT: /sources/emacs
Module name: emacs
Changes by: Glenn Morris <gm> 07/09/06 04:11:59
Index: internals.texi
===================================================================
RCS file: internals.texi
diff -N internals.texi
--- internals.texi 7 Apr 2007 01:50:56 -0000 1.57
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,1522 +0,0 @@
address@hidden -*-texinfo-*-
address@hidden This is part of the GNU Emacs Lisp Reference Manual.
address@hidden Copyright (C) 1990, 1991, 1992, 1993, 1998, 1999, 2001, 2002,
2003,
address@hidden 2004, 2005, 2006, 2007 Free Software Foundation, Inc.
address@hidden See the file elisp.texi for copying conditions.
address@hidden ../info/internals
address@hidden GNU Emacs Internals, Standard Errors, Tips, Top
address@hidden node-name, next, previous, up
address@hidden 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.
-
address@hidden
-* Building Emacs:: How the dumped Emacs is made.
-* Pure Storage:: A kludge to make preloaded Lisp functions sharable.
-* Garbage Collection:: Reclaiming space for Lisp objects no longer used.
-* Memory Usage:: Info about total size of Lisp objects made so far.
-* Writing Emacs Primitives:: Writing C code for Emacs.
-* Object Internals:: Data formats of buffers, windows, processes.
address@hidden menu
-
address@hidden Building Emacs
address@hidden Building Emacs
address@hidden building Emacs
address@hidden 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
address@hidden impure Emacs}. It contains the Emacs Lisp interpreter and I/O
-routines, but not the editing commands.
-
address@hidden @file{loadup.el}
- The command @address@hidden -l loadup}} uses @file{temacs} to create
-the real runnable Emacs executable. These arguments direct
address@hidden to evaluate the Lisp files specified in the file
address@hidden These files set up the normal Emacs editing
-environment, resulting in an Emacs that is still impure but no longer
-bare.
-
address@hidden dumping Emacs
- 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
-dump out an executable program called @file{emacs} that has these files
-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
-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.
-
address@hidden @file{site-load.el}
-
- You can specify additional files to preload by writing a library named
address@hidden that loads them. You may need to add a definition
-
address@hidden
-#define SITELOAD_PURESIZE_EXTRA @var{n}
address@hidden example
-
address@hidden
-to make @var{n} added bytes of pure space to hold 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.
-
- After @file{loadup.el} reads @file{site-load.el}, it finds the
-documentation strings for primitive and preloaded functions (and
-variables) in the file @file{etc/DOC} where they are stored, by
-calling @code{Snarf-documentation} (@pxref{Definition of
-Snarf-documentation,, Accessing Documentation}).
-
address@hidden @file{site-init.el}
address@hidden preloading additional functions and variables
- You can specify other Lisp expressions to execute just before dumping
-by putting them in a library named @file{site-init.el}. This file is
-executed after the documentation strings are found.
-
- If you want to preload function or variable definitions, there are
-three ways you can do this and make their documentation strings
-accessible when you subsequently run Emacs:
-
address@hidden @bullet
address@hidden
-Arrange to scan these files when producing the @file{etc/DOC} file,
-and load them with @file{site-load.el}.
-
address@hidden
-Load the files with @file{site-init.el}, then copy the files into the
-installation directory for Lisp files when you install Emacs.
-
address@hidden
-Specify a address@hidden value for
address@hidden as a local variable in each of these
-files, and load them with either @file{site-load.el} or
address@hidden (This method has the drawback that the
-documentation strings take up space in Emacs all the time.)
address@hidden itemize
-
- It is not advisable to put anything in @file{site-load.el} or
address@hidden that would alter any of the features that users
-expect in an ordinary unmodified Emacs. If you feel you must override
-normal features for your site, do it with @file{default.el}, so that
-users can override your changes if they wish. @xref{Startup Summary}.
-
- In a package that can be preloaded, it is sometimes useful to
-specify a computation to be done when Emacs subsequently starts up.
-For this, use @code{eval-at-startup}:
-
address@hidden eval-at-startup address@hidden
-This evaluates the @var{body} forms, either immediately if running in
-an Emacs that has already started up, or later when Emacs does start
-up. Since the value of the @var{body} forms is not necessarily
-available when the @code{eval-at-startup} form is run, that form
-always returns @code{nil}.
address@hidden defmac
-
address@hidden dump-emacs to-file from-file
address@hidden unexec
-This function dumps the current state of Emacs into an executable file
address@hidden It takes symbols from @var{from-file} (this is normally
-the executable file @file{temacs}).
-
-If you want to use this function in an Emacs that was already dumped,
-you must run Emacs with @samp{-batch}.
address@hidden defun
-
address@hidden Pure Storage
address@hidden Pure Storage
address@hidden pure storage
-
- Emacs Lisp uses two kinds of storage for user-created Lisp objects:
address@hidden storage} and @dfn{pure storage}. Normal storage is where
-all the new data created during an Emacs session are 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.
-
- Pure storage is allocated only while @file{temacs} is loading the
-standard preloaded Lisp libraries. In the file @file{emacs}, it is
-marked as read-only (on operating systems that permit this), so that
-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 preloaded libraries, @file{temacs} allocates dynamic memory for
-the part that didn't fit. If that happens, you should increase the
-compilation parameter @code{PURESIZE} in the file
address@hidden/puresize.h} and rebuild Emacs, even though the resulting
-image will work: garbage collection is disabled in this situation,
-causing a memory leak. Such an overflow normally won't happen unless you
-try to preload additional libraries or add features to the standard
-ones. Emacs will display a warning about the overflow when it
-starts.
-
address@hidden purecopy object
-This function makes a copy in pure storage of @var{object}, and returns
-it. It copies a string by simply making a new string with the same
-characters, but without text properties, in pure storage. It
-recursively copies the contents of 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 asked to copy markers.
-
-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.
address@hidden defun
-
address@hidden pure-bytes-used
-The value of this variable is the number of bytes of pure storage
-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.
address@hidden defvar
-
address@hidden purify-flag
-This variable determines whether @code{defun} should make a copy of the
-function definition in pure storage. If it is address@hidden, then the
-function definition is copied into pure storage.
-
-This flag is @code{t} while loading all of the basic functions for
-building Emacs initially (allowing those functions to be sharable and
-non-collectible). Dumping Emacs as an executable always writes
address@hidden in this variable, regardless of the value it actually has
-before and after dumping.
-
-You should not change this flag in a running Emacs.
address@hidden defvar
-
address@hidden Garbage Collection
address@hidden Garbage Collection
address@hidden garbage collection
-
address@hidden memory allocation
- When a program creates a list or the user defines a new function (such
-as by loading a library), that data is placed in normal storage. If
-normal storage runs low, then Emacs asks the operating system to
-allocate more memory in blocks of 1k bytes. Each block is used for one
-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
-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.)
-
- 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
-any data presently on the stack, are accessible. Any objects that can
-be reached indirectly through other accessible objects are also
-accessible.
-
- When marking is finished, all objects still unmarked are garbage. No
-matter what the Lisp program or the user does, it is impossible to refer
-to them, since there is no longer a way to reach them. Their space
-might as well be reused, since no one will miss them. The second
-(``sweep'') phase of the garbage collector arranges to reuse them.
-
address@hidden ??? Maybe add something describing weak hash tables here?
-
address@hidden free list
- 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
-other 8k blocks. Vectors, buffers, windows, and other large objects are
-individually allocated and freed using @code{malloc} and @code{free}.
-
address@hidden CL note---allocate more storage
address@hidden
address@hidden Lisp note:} Unlike other Lisps, GNU Emacs Lisp does not
-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).
address@hidden quotation
-
address@hidden Command garbage-collect
-This command runs a garbage collection, and returns information on
-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.)
-
address@hidden returns a list containing the following
-information:
-
address@hidden
address@hidden
-((@var{used-conses} . @var{free-conses})
- (@var{used-syms} . @var{free-syms})
address@hidden group
- (@var{used-miscs} . @var{free-miscs})
- @var{used-string-chars}
- @var{used-vector-slots}
- (@var{used-floats} . @var{free-floats})
- (@var{used-intervals} . @var{free-intervals})
- (@var{used-strings} . @var{free-strings}))
address@hidden example
-
-Here is an example:
-
address@hidden
address@hidden
-(garbage-collect)
- @result{} ((106886 . 13184) (9769 . 0)
- (7731 . 4651) 347543 121628
- (31 . 94) (1273 . 168)
- (25474 . 3569))
address@hidden group
address@hidden example
-
-Here is a table explaining each element:
-
address@hidden @var
address@hidden used-conses
-The number of cons cells in use.
-
address@hidden free-conses
-The number of cons cells for which space has been obtained from the
-operating system, but that are not currently being used.
-
address@hidden used-syms
-The number of symbols in use.
-
address@hidden free-syms
-The number of symbols for which space has been obtained from the
-operating system, but that are not currently being used.
-
address@hidden used-miscs
-The number of miscellaneous objects in use. These include markers and
-overlays, plus certain objects not visible to users.
-
address@hidden free-miscs
-The number of miscellaneous objects for which space has been obtained
-from the operating system, but that are not currently being used.
-
address@hidden used-string-chars
-The total size of all strings, in characters.
-
address@hidden used-vector-slots
-The total number of elements of existing vectors.
-
address@hidden used-floats
address@hidden Emacs 19 feature
-The number of floats in use.
-
address@hidden free-floats
address@hidden Emacs 19 feature
-The number of floats for which space has been obtained from the
-operating system, but that are not currently being used.
-
address@hidden used-intervals
-The number of intervals in use. Intervals are an internal
-data structure used for representing text properties.
-
address@hidden free-intervals
-The number of intervals for which space has been obtained
-from the operating system, but that are not currently being used.
-
address@hidden used-strings
-The number of strings in use.
-
address@hidden free-strings
-The number of string headers for which the space was obtained from the
-operating system, but which are currently not in use. (A string
-object consists of a header and the storage for the string text
-itself; the latter is only allocated when the string is created.)
address@hidden table
-
-If there was overflow in pure space (see the previous section),
address@hidden returns @code{nil}, because a real garbage
-collection can not be done in this situation.
address@hidden deffn
-
address@hidden garbage-collection-messages
-If this variable is address@hidden, Emacs displays a message at the
-beginning and end of garbage collection. The default value is
address@hidden, meaning there are no such messages.
address@hidden defopt
-
address@hidden post-gc-hook
-This is a normal hook that is run at the end of garbage collection.
-Garbage collection is inhibited while the hook functions run, so be
-careful writing them.
address@hidden defvar
-
address@hidden gc-cons-threshold
-The value of this variable is the number of bytes of storage that must
-be allocated for Lisp objects after one garbage collection in order to
-trigger another garbage collection. A cons cell counts as eight bytes,
-a string as one byte per character plus a few bytes of overhead, and so
-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
-called.
-
-The initial threshold value is 400,000. If you specify a larger
-value, garbage collection will happen less often. This reduces the
-amount of time spent garbage collecting, but increases total memory use.
-You may want to do this when running a program that creates lots of
-Lisp data.
-
-You can make collections more frequent by specifying a smaller value,
-down to 10,000. A value less than 10,000 will remain in effect only
-until the subsequent garbage collection, at which time
address@hidden will set the threshold back to 10,000.
address@hidden defopt
-
address@hidden gc-cons-percentage
-The value of this variable specifies the amount of consing before a
-garbage collection occurs, as a fraction of the current heap size.
-This criterion and @code{gc-cons-threshold} apply in parallel, and
-garbage collection occurs only when both criteria are satisfied.
-
-As the heap size increases, the time to perform a garbage collection
-increases. Thus, it can be desirable to do them less frequently in
-proportion.
address@hidden defopt
-
- The value returned by @code{garbage-collect} describes the amount of
-memory used by Lisp data, broken down by data type. By contrast, the
-function @code{memory-limit} provides information on the total amount of
-memory Emacs is currently using.
-
address@hidden Emacs 19 feature
address@hidden 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.
address@hidden defun
-
address@hidden memory-full
-This variable is @code{t} if Emacs is close to out of memory for Lisp
-objects, and @code{nil} otherwise.
address@hidden defvar
-
address@hidden memory-use-counts
-This returns a list of numbers that count the number of objects
-created in this Emacs session. Each of these counters increments for
-a certain kind of object. See the documentation string for details.
address@hidden defun
-
address@hidden gcs-done
-This variable contains the total number of garbage collections
-done so far in this Emacs session.
address@hidden defvar
-
address@hidden gc-elapsed
-This variable contains the total number of seconds of elapsed time
-during garbage collection so far in this Emacs session, as a floating
-point number.
address@hidden defvar
-
address@hidden Memory Usage
address@hidden Memory Usage
address@hidden memory usage
-
- These functions and variables give information about the total amount
-of memory allocation that Emacs has done, broken down by data type.
-Note the difference between these and the values returned by
address@hidden(garbage-collect)}; those count objects that currently exist, but
-these count the number or size of all allocations, including those for
-objects that have since been freed.
-
address@hidden cons-cells-consed
-The total number of cons cells that have been allocated so far
-in this Emacs session.
address@hidden defvar
-
address@hidden floats-consed
-The total number of floats that have been allocated so far
-in this Emacs session.
address@hidden defvar
-
address@hidden vector-cells-consed
-The total number of vector cells that have been allocated so far
-in this Emacs session.
address@hidden defvar
-
address@hidden symbols-consed
-The total number of symbols that have been allocated so far
-in this Emacs session.
address@hidden defvar
-
address@hidden string-chars-consed
-The total number of string characters that have been allocated so far
-in this Emacs session.
address@hidden defvar
-
address@hidden misc-objects-consed
-The total number of miscellaneous objects that have been allocated so
-far in this Emacs session. These include markers and overlays, plus
-certain objects not visible to users.
address@hidden defvar
-
address@hidden intervals-consed
-The total number of intervals that have been allocated so far
-in this Emacs session.
address@hidden defvar
-
address@hidden strings-consed
-The total number of strings that have been allocated so far in this
-Emacs session.
address@hidden defvar
-
address@hidden Writing Emacs Primitives
address@hidden Writing Emacs Primitives
address@hidden primitive function internals
address@hidden writing Emacs primitives
-
- 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
address@hidden (An ordinary function would have the same general
-appearance.)
-
address@hidden garbage collection protection
address@hidden
address@hidden
-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.
address@hidden group
address@hidden
-usage: (or CONDITIONS ...) */)
- (args)
- Lisp_Object args;
address@hidden
- register Lisp_Object val = Qnil;
- struct gcpro gcpro1;
address@hidden group
-
address@hidden
- GCPRO1 (args);
address@hidden group
-
address@hidden
- while (CONSP (args))
- @{
- val = Feval (XCAR (args));
- if (!NILP (val))
- break;
- args = XCDR (args);
- @}
address@hidden group
-
address@hidden
- UNGCPRO;
- return val;
address@hidden
address@hidden group
address@hidden smallexample
-
address@hidden @code{DEFUN}, C macro to define Lisp primitives
- Let's start with a precise explanation of the arguments to the
address@hidden macro. Here is a template for them:
-
address@hidden
-DEFUN (@var{lname}, @var{fname}, @var{sname}, @var{min}, @var{max},
@var{interactive}, @var{doc})
address@hidden example
-
address@hidden @var
address@hidden lname
-This is the name of the Lisp symbol to define as the function name; in
-the example above, it is @code{or}.
-
address@hidden 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
address@hidden
-
address@hidden 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
address@hidden
-
address@hidden min
-This is the minimum number of arguments that the function requires. The
-function @code{or} allows a minimum of zero arguments.
-
address@hidden max
-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
address@hidden, 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 eight.
-
address@hidden 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
address@hidden, it is 0 (a null pointer), indicating that @code{or} cannot be
-called interactively. A value of @code{""} indicates a function that
-should receive no arguments when called interactively.
-
address@hidden doc
-This is the documentation string. It uses C comment syntax rather
-than C string syntax because comment syntax requires nothing special
-to include multiple lines. The @samp{doc:} identifies the comment
-that follows as the documentation string. The @samp{/*} and @samp{*/}
-delimiters that begin and end the comment are not part of the
-documentation string.
-
-If the last line of the documentation string begins with the keyword
address@hidden:}, 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.
address@hidden:} is required if the function has an unlimited number of
-arguments.
-
-All the usual rules for documentation strings in Lisp code
-(@pxref{Documentation Tips}) apply to C code documentation strings
-too.
address@hidden table
-
- 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
-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 @address@hidden *}}.
-
address@hidden @code{GCPRO} and @code{UNGCPRO}
address@hidden protect C variables from garbage collection
- Within the function @code{For} itself, note the use of the macros
address@hidden 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. GC protection is necessary whenever you call
address@hidden or anything that can directly or indirectly call
address@hidden At such a time, any Lisp object that this function may
-refer to again must be protected somehow.
-
- It suffices to ensure that at least one pointer to each object is
-GC-protected; that way, the object cannot be recycled, so all pointers
-to it remain valid. Thus, a particular local variable can do without
-protection if it is certain that the object it points to will be
-preserved by some other pointer (such as another local variable which
-has a @code{GCPRO})@footnote{Formerly, strings were a special
-exception; in older Emacs versions, every local variable that might
-point to a string needed a @code{GCPRO}.}. Otherwise, the local
-variable needs a @code{GCPRO}.
-
- The macro @code{GCPRO1} protects just one local variable. If you
-want to protect two variables, use @code{GCPRO2} instead; repeating
address@hidden will not work. Macros @code{GCPRO3}, @code{GCPRO4},
address@hidden, and @code{GCPRO6} also exist. All these macros
-implicitly use local variables such as @code{gcpro1}; you must declare
-these explicitly, with type @code{struct gcpro}. Thus, if you use
address@hidden, you must declare @code{gcpro1} and @code{gcpro2}.
-Alas, we can't explain all the tricky details here.
-
- @code{UNGCPRO} cancels the protection of the variables that are
-protected in the current function. It is necessary to do this
-explicitly.
-
- Built-in functions that take a variable number of arguments actually
-accept two arguments at the C level: the number of Lisp arguments, and
-a @code{Lisp_Object *} pointer to a C vector containing those Lisp
-arguments. This C vector may be part of a Lisp vector, but it need
-not be. The responsibility for using @code{GCPRO} to protect the Lisp
-arguments from GC if necessary rests with the caller in this case,
-since the caller allocated or found the storage for them.
-
- 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.
address@hidden 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.)
-
address@hidden @code{defsubr}, Lisp symbol for a primitive
- 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:
-
address@hidden
-defsubr (&@var{subr-structure-name});
address@hidden example
-
address@hidden
-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
address@hidden@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 @address@hidden (e.g.,
address@hidden). Then find the spot in @file{emacs.c} where all
-of these functions are called, and add a call to
address@hidden@var{filename}} there.
-
address@hidden Lisp variables in C}
address@hidden byte-boolean-vars
address@hidden defining Lisp variables in C
address@hidden @code{DEFVAR_INT}, @code{DEFVAR_LISP}, @code{DEFVAR_BOOL}
- The function @address@hidden is also the place to define
-any C variables that are to be visible as Lisp variables.
address@hidden 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.
address@hidden makes a C variable of type @code{int} visible in Lisp
-with a value that is either @code{t} or @code{nil}. Note that variables
-defined with @code{DEFVAR_BOOL} are automatically added to the list
address@hidden used by the byte compiler.
-
address@hidden @code{staticpro}, protection from GC
- If you define a file-scope C variable of type @code{Lisp_Object},
-you must protect it from garbage-collection by calling @code{staticpro}
-in @address@hidden, like this:
-
address@hidden
-staticpro (&@var{variable});
address@hidden example
-
- Here is another example function, with more complicated arguments.
-This comes from the code in @file{window.c}, and it demonstrates the use
-of macros and functions to manipulate Lisp objects.
-
address@hidden
address@hidden
-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 COORDINATES is in WINDOW.\n\
-COORDINATES is a cons of the form (X . Y), X and Y being distances\n\
-...
address@hidden group
address@hidden
-If they are on the border between WINDOW and its right sibling,\n\
- `vertical-line' is returned.")
- (coordinates, window)
- register Lisp_Object coordinates, window;
address@hidden
- int x, y;
address@hidden group
-
address@hidden
- CHECK_LIVE_WINDOW (window, 0);
- CHECK_CONS (coordinates, 1);
- x = XINT (Fcar (coordinates));
- y = XINT (Fcdr (coordinates));
address@hidden group
-
address@hidden
- switch (coordinates_in_window (XWINDOW (window), &x, &y))
- @{
- case 0: /* NOT in window at all. */
- return Qnil;
address@hidden group
-
address@hidden
- case 1: /* In text part of window. */
- return Fcons (make_number (x), make_number (y));
address@hidden group
-
address@hidden
- case 2: /* In mode line of window. */
- return Qmode_line;
address@hidden group
-
address@hidden
- case 3: /* On right border of window. */
- return Qvertical_line;
address@hidden group
-
address@hidden
- default:
- abort ();
- @}
address@hidden
address@hidden group
address@hidden smallexample
-
- 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
address@hidden, 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
address@hidden
-
- 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}.
-
- @file{eval.c} is a very good file to look through for examples;
address@hidden contains the definitions for some important macros and
-functions.
-
- If you define a function which is side-effect free, update the code
-in @file{byte-opt.el} which binds @code{side-effect-free-fns} and
address@hidden so that the compiler optimizer
-knows about it.
-
address@hidden Object Internals
address@hidden Object Internals
address@hidden 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-nine bits are used to address the
-object, and the remaining three bits are used for the tag that
-identifies the object's type.
-
- 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
address@hidden 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}).
address@hidden type checking internals
-
address@hidden
-* Buffer Internals:: Components of a buffer structure.
-* Window Internals:: Components of a window structure.
-* Process Internals:: Components of a process structure.
address@hidden menu
-
address@hidden Buffer Internals
address@hidden Buffer Internals
address@hidden internals, of buffer
address@hidden 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.
-
-Two structures are used to represent buffers in C. The
address@hidden structure contains fields describing the text of a
-buffer; the @code{buffer} structure holds other fields. In the case
-of indirect buffers, two or more @code{buffer} structures reference
-the same @code{buffer_text} structure.
-
-Here is a list of the @code{struct buffer_text} fields:
-
address@hidden @code
address@hidden beg
-This field contains the actual address of the buffer contents.
-
address@hidden gpt
-This holds the character position of the gap in the buffer.
address@hidden Gap}.
-
address@hidden z
-This field contains the character position of the end of the buffer
-text.
-
address@hidden gpt_byte
-Contains the byte position of the gap.
-
address@hidden z_byte
-Holds the byte position of the end of the buffer text.
-
address@hidden gap_size
-Contains the size of buffer's gap. @xref{Buffer Gap}.
-
address@hidden modiff
-This field counts buffer-modification events for this buffer. It is
-incremented for each such event, and never otherwise changed.
-
address@hidden save_modiff
-Contains the previous value of @code{modiff}, as of the last time a
-buffer was visited or saved in a file.
-
address@hidden overlay_modiff
-Counts modifications to overlays analogous to @code{modiff}.
-
address@hidden beg_unchanged
-Holds the number of characters at the start of the text that are known
-to be unchanged since the last redisplay that finished.
-
address@hidden end_unchanged
-Holds the number of characters at the end of the text that are known to
-be unchanged since the last redisplay that finished.
-
address@hidden unchanged_modified
-Contains the value of @code{modiff} at the time of the last redisplay
-that finished. If this value matches @code{modiff},
address@hidden and @code{end_unchanged} contain no useful
-information.
-
address@hidden overlay_unchanged_modified
-Contains the value of @code{overlay_modiff} at the time of the last
-redisplay that finished. If this value matches @code{overlay_modiff},
address@hidden and @code{end_unchanged} contain no useful
-information.
-
address@hidden markers
-The markers that refer to this buffer. This is actually a single
-marker, and successive elements in its marker @code{chain} are the other
-markers referring to this buffer text.
-
address@hidden intervals
-Contains the interval tree which records the text properties of this
-buffer.
address@hidden table
-
-The fields of @code{struct buffer} are:
-
address@hidden @code
address@hidden next
-Points to the next buffer, in the chain of all buffers including killed
-buffers. This chain is used only for garbage collection, in order to
-collect killed buffers properly. Note that vectors, and most kinds of
-objects allocated as vectors, are all on one chain, but buffers are on a
-separate chain of their own.
-
address@hidden own_text
-This is a @code{struct buffer_text} structure. In an ordinary buffer,
-it holds the buffer contents. In indirect buffers, this field is not
-used.
-
address@hidden text
-This points to the @code{buffer_text} structure that is used for this
-buffer. In an ordinary buffer, this is the @code{own_text} field above.
-In an indirect buffer, this is the @code{own_text} field of the base
-buffer.
-
address@hidden pt
-Contains the character position of point in a buffer.
-
address@hidden pt_byte
-Contains the byte position of point in a buffer.
-
address@hidden begv
-This field contains the character position of the beginning of the
-accessible range of text in the buffer.
-
address@hidden begv_byte
-This field contains the byte position of the beginning of the
-accessible range of text in the buffer.
-
address@hidden zv
-This field contains the character position of the end of the
-accessible range of text in the buffer.
-
address@hidden zv_byte
-This field contains the byte position of the end of the
-accessible range of text in the buffer.
-
address@hidden base_buffer
-In an indirect buffer, this points to the base buffer. In an ordinary
-buffer, it is null.
-
address@hidden local_var_flags
-This field contains flags indicating that certain variables are local in
-this buffer. Such variables are declared in the C code using
address@hidden, and their buffer-local bindings are stored in
-fields in the buffer structure itself. (Some of these fields are
-described in this table.)
-
address@hidden modtime
-This field contains the modification time of the visited file. It is
-set when the file is written or read. Before writing the buffer into a
-file, this field is compared to the modification time of the file to see
-if the file has changed on disk. @xref{Buffer Modification}.
-
address@hidden auto_save_modified
-This field contains the time when the buffer was last auto-saved.
-
address@hidden auto_save_failure_time
-The time at which we detected a failure to auto-save, or -1 if we didn't
-have a failure.
-
address@hidden 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.
-
address@hidden clip_changed
-This flag is set when narrowing changes in a buffer.
-
address@hidden prevent_redisplay_optimizations_p
-this flag indicates that redisplay optimizations should not be used
-to display this buffer.
-
address@hidden undo_list
-This field points to the buffer's undo list. @xref{Undo}.
-
address@hidden name
-The buffer name is a string that names the buffer. It is guaranteed to
-be unique. @xref{Buffer Names}.
-
address@hidden filename
-The name of the file visited in this buffer, or @code{nil}.
-
address@hidden directory
-The directory for expanding relative file names.
-
address@hidden save_length
-Length of the file this buffer is visiting, when last read or saved.
-This and other fields concerned with saving are not kept in the
address@hidden structure because indirect buffers are never saved.
-
address@hidden auto_save_file_name
-File name used for auto-saving this buffer. This is not in the
address@hidden because it's not used in indirect buffers at all.
-
address@hidden read_only
address@hidden means this buffer is read-only.
-
address@hidden 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}.
-
address@hidden local_var_alist
-This field contains the association list describing the buffer-local
-variable bindings of this buffer, not including the built-in
-buffer-local bindings that have special slots in the buffer object.
-(Those slots are omitted from this table.) @xref{Buffer-Local
-Variables}.
-
address@hidden major_mode
-Symbol naming the major mode of this buffer, e.g., @code{lisp-mode}.
-
address@hidden mode_name
-Pretty name of major mode, e.g., @code{"Lisp"}.
-
address@hidden mode_line_format
-Mode line element that controls the format of the mode line. If this
-is @code{nil}, no mode line will be displayed.
-
address@hidden header_line_format
-This field is analogous to @code{mode_line_format} for the mode
-line displayed at the top of windows.
-
address@hidden keymap
-This field holds the buffer's local keymap. @xref{Keymaps}.
-
address@hidden abbrev_table
-This buffer's local abbrevs.
-
address@hidden syntax_table
-This field contains the syntax table for the buffer. @xref{Syntax Tables}.
-
address@hidden category_table
-This field contains the category table for the buffer.
-
address@hidden case_fold_search
-The value of @code{case-fold-search} in this buffer.
-
address@hidden tab_width
-The value of @code{tab-width} in this buffer.
-
address@hidden fill_column
-The value of @code{fill-column} in this buffer.
-
address@hidden left_margin
-The value of @code{left-margin} in this buffer.
-
address@hidden auto_fill_function
-The value of @code{auto-fill-function} in this buffer.
-
address@hidden downcase_table
-This field contains the conversion table for converting text to lower case.
address@hidden Tables}.
-
address@hidden upcase_table
-This field contains the conversion table for converting text to upper case.
address@hidden Tables}.
-
address@hidden case_canon_table
-This field contains the conversion table for canonicalizing text for
-case-folding search. @xref{Case Tables}.
-
address@hidden case_eqv_table
-This field contains the equivalence table for case-folding search.
address@hidden Tables}.
-
address@hidden truncate_lines
-The value of @code{truncate-lines} in this buffer.
-
address@hidden ctl_arrow
-The value of @code{ctl-arrow} in this buffer.
-
address@hidden selective_display
-The value of @code{selective-display} in this buffer.
-
address@hidden selective_display_ellipsis
-The value of @code{selective-display-ellipsis} in this buffer.
-
address@hidden minor_modes
-An alist of the minor modes of this buffer.
-
address@hidden overwrite_mode
-The value of @code{overwrite_mode} in this buffer.
-
address@hidden abbrev_mode
-The value of @code{abbrev-mode} in this buffer.
-
address@hidden display_table
-This field contains the buffer's display table, or @code{nil} if it doesn't
-have one. @xref{Display Tables}.
-
address@hidden save_modified
-This field contains the time when the buffer was last saved, as an integer.
address@hidden Modification}.
-
address@hidden mark_active
-This field is address@hidden if the buffer's mark is active.
-
address@hidden 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.
-
address@hidden 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.
-
address@hidden overlay_center
-This field holds the current overlay center position. @xref{Overlays}.
-
address@hidden enable_multibyte_characters
-This field holds the buffer's local value of
address@hidden @code{t} or @code{nil}.
-
address@hidden buffer_file_coding_system
-The value of @code{buffer-file-coding-system} in this buffer.
-
address@hidden file_format
-The value of @code{buffer-file-format} in this buffer.
-
address@hidden auto_save_file_format
-The value of @code{buffer-auto-save-file-format} in this buffer.
-
address@hidden pt_marker
-In an indirect buffer, or a buffer that is the base of an indirect
-buffer, this holds a marker that records point for this buffer when the
-buffer is not current.
-
address@hidden begv_marker
-In an indirect buffer, or a buffer that is the base of an indirect
-buffer, this holds a marker that records @code{begv} for this buffer
-when the buffer is not current.
-
address@hidden zv_marker
-In an indirect buffer, or a buffer that is the base of an indirect
-buffer, this holds a marker that records @code{zv} for this buffer when
-the buffer is not current.
-
address@hidden file_truename
-The truename of the visited file, or @code{nil}.
-
address@hidden invisibility_spec
-The value of @code{buffer-invisibility-spec} in this buffer.
-
address@hidden last_selected_window
-This is the last window that was selected with this buffer in it, or @code{nil}
-if that window no longer displays this buffer.
-
address@hidden display_count
-This field is incremented each time the buffer is displayed in a window.
-
address@hidden left_margin_width
-The value of @code{left-margin-width} in this buffer.
-
address@hidden right_margin_width
-The value of @code{right-margin-width} in this buffer.
-
address@hidden indicate_empty_lines
address@hidden means indicate empty lines (lines with no text) with a
-small bitmap in the fringe, when using a window system that can do it.
-
address@hidden display_time
-This holds a time stamp that is updated each time this buffer is
-displayed in a window.
-
address@hidden scroll_up_aggressively
-The value of @code{scroll-up-aggressively} in this buffer.
-
address@hidden scroll_down_aggressively
-The value of @code{scroll-down-aggressively} in this buffer.
address@hidden table
-
address@hidden Window Internals
address@hidden Window Internals
address@hidden internals, of window
address@hidden window internals
-
- Windows have the following accessible fields:
-
address@hidden @code
address@hidden frame
-The frame that this window is on.
-
address@hidden mini_p
address@hidden if this window is a minibuffer window.
-
address@hidden 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
-leaves of the tree, which actually display buffers.
-
-The following four fields also describe the window tree structure.
-
address@hidden hchild
-In a window subdivided horizontally by child windows, the leftmost child.
-Otherwise, @code{nil}.
-
address@hidden vchild
-In a window subdivided vertically by child windows, the topmost child.
-Otherwise, @code{nil}.
-
address@hidden next
-The next sibling of this window. It is @code{nil} in a window that is
-the rightmost or bottommost of a group of siblings.
-
address@hidden prev
-The previous sibling of this window. It is @code{nil} in a window that
-is the leftmost or topmost of a group of siblings.
-
address@hidden left
-This is the left-hand edge of the window, measured in columns. (The
-leftmost column on the screen is @w{column 0}.)
-
address@hidden top
-This is the top edge of the window, measured in lines. (The top line on
-the screen is @w{line 0}.)
-
address@hidden height
-The height of the window, measured in lines.
-
address@hidden width
-The width of the window, measured in columns. This width includes the
-scroll bar and fringes, and/or the separator line on the right of the
-window (if any).
-
address@hidden buffer
-The buffer that the window is displaying. This may change often during
-the life of the window.
-
address@hidden start
-The position in the buffer that is the first character to be displayed
-in the window.
-
address@hidden pointm
address@hidden window point internals
-This is the value of point in the current buffer when this window is
-selected; when it is not selected, it retains its previous value.
-
address@hidden force_start
-If this flag is address@hidden, 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.
-
address@hidden frozen_window_start_p
-This field is set temporarily to 1 to indicate to redisplay that
address@hidden of this window should not be changed, even if point
-gets invisible.
-
address@hidden start_at_line_beg
address@hidden means current value of @code{start} was the beginning of a line
-when it was chosen.
-
address@hidden too_small_ok
address@hidden means don't delete this window for becoming ``too small.''
-
address@hidden height_fixed_p
-This field is temporarily set to 1 to fix the height of the selected
-window when the echo area is resized.
-
address@hidden use_time
-This is the last time that the window was selected. The function
address@hidden uses this field.
-
address@hidden sequence_number
-A unique number assigned to this window when it was created.
-
address@hidden last_modified
-The @code{modiff} field of the window's buffer, as of the last time
-a redisplay completed in this window.
-
address@hidden last_overlay_modified
-The @code{overlay_modiff} field of the window's buffer, as of the last
-time a redisplay completed in this window.
-
address@hidden last_point
-The buffer's value of point, as of the last time a redisplay completed
-in this window.
-
address@hidden last_had_star
-A address@hidden value means the window's buffer was ``modified'' when the
-window was last updated.
-
address@hidden vertical_scroll_bar
-This window's vertical scroll bar.
-
address@hidden left_margin_width
-The width of the left margin in this window, or @code{nil} not to
-specify it (in which case the buffer's value of @code{left-margin-width}
-is used.
-
address@hidden right_margin_width
-Likewise for the right margin.
-
address@hidden
address@hidden last_mark_x
address@hidden last_mark_y
-???Not used.
address@hidden ignore
-
address@hidden window_end_pos
-This is computed as @code{z} minus the buffer position of the last glyph
-in the current matrix of the window. The value is only valid if
address@hidden is not @code{nil}.
-
address@hidden window_end_bytepos
-The byte position corresponding to @code{window_end_pos}.
-
address@hidden window_end_vpos
-The window-relative vertical position of the line containing
address@hidden
-
address@hidden window_end_valid
-This field is set to a address@hidden value if @code{window_end_pos} is truly
-valid. This is @code{nil} if nontrivial redisplay is preempted since in that
-case the display that @code{window_end_pos} was computed for did not get
-onto the screen.
-
address@hidden redisplay_end_trigger
-If redisplay in this window goes beyond this buffer position, it runs
-the @code{redisplay-end-trigger-hook}.
-
address@hidden
address@hidden orig_height
address@hidden orig_top
-??? Are temporary storage areas.
address@hidden ignore
-
address@hidden cursor
-A structure describing where the cursor is in this window.
-
address@hidden last_cursor
-The value of @code{cursor} as of the last redisplay that finished.
-
address@hidden phys_cursor
-A structure describing where the cursor of this window physically is.
-
address@hidden phys_cursor_type
-The type of cursor that was last displayed on this window.
-
address@hidden phys_cursor_on_p
-This field is non-zero if the cursor is physically on.
-
address@hidden cursor_off_p
-Non-zero means the cursor in this window is logically on.
-
address@hidden last_cursor_off_p
-This field contains the value of @code{cursor_off_p} as of the time of
-the last redisplay.
-
address@hidden must_be_updated_p
-This is set to 1 during redisplay when this window must be updated.
-
address@hidden hscroll
-This is the number of columns that the display in the window is scrolled
-horizontally to the left. Normally, this is 0.
-
address@hidden vscroll
-Vertical scroll amount, in pixels. Normally, this is 0.
-
address@hidden dedicated
address@hidden if this window is dedicated to its buffer.
-
address@hidden display_table
-The window's display table, or @code{nil} if none is specified for it.
-
address@hidden update_mode_line
address@hidden means this window's mode line needs to be updated.
-
address@hidden 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.
-
address@hidden base_line_pos
-The position in the buffer for which the line number is known, or
address@hidden meaning none is known.
-
address@hidden 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}.
-
address@hidden column_number_displayed
-The column number currently displayed in this window's mode line, or @code{nil}
-if column numbers are not being displayed.
-
address@hidden current_matrix
-A glyph matrix describing the current display of this window.
-
address@hidden desired_matrix
-A glyph matrix describing the desired display of this window.
address@hidden table
-
address@hidden Process Internals
address@hidden Process Internals
address@hidden internals, of process
address@hidden process internals
-
- The fields of a process are:
-
address@hidden @code
address@hidden name
-A string, the name of the process.
-
address@hidden command
-A list containing the command arguments that were used to start this
-process.
-
address@hidden filter
-A function used to accept output from the process instead of a buffer,
-or @code{nil}.
-
address@hidden sentinel
-A function called whenever the process receives a signal, or @code{nil}.
-
address@hidden buffer
-The associated buffer of the process.
-
address@hidden pid
-An integer, the operating system's process @acronym{ID}.
-
address@hidden childp
-A flag, address@hidden if this is really a child process.
-It is @code{nil} for a network connection.
-
address@hidden mark
-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.
-
address@hidden kill_without_query
-If this is address@hidden, killing Emacs while this process is still
-running does not ask for confirmation about killing the process.
-
address@hidden raw_status_low
address@hidden raw_status_high
-These two fields record 16 bits each of the process status returned by
-the @code{wait} system call.
-
address@hidden status
-The process status, as @code{process-status} should return it.
-
address@hidden tick
address@hidden 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.
-
address@hidden pty_flag
address@hidden if communication with the subprocess uses a @acronym{PTY};
address@hidden if it uses a pipe.
-
address@hidden infd
-The file descriptor for input from the process.
-
address@hidden outfd
-The file descriptor for output to the process.
-
address@hidden 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
address@hidden)
-
address@hidden tty_name
-The name of the terminal that the subprocess is using,
-or @code{nil} if it is using pipes.
-
address@hidden decode_coding_system
-Coding-system for decoding the input from this process.
-
address@hidden decoding_buf
-A working buffer for decoding.
-
address@hidden decoding_carryover
-Size of carryover in decoding.
-
address@hidden encode_coding_system
-Coding-system for encoding the output to this process.
-
address@hidden encoding_buf
-A working buffer for encoding.
-
address@hidden encoding_carryover
-Size of carryover in encoding.
-
address@hidden inherit_coding_system_flag
-Flag to set @code{coding-system} of the process buffer from the
-coding system used to decode process output.
address@hidden table
-
address@hidden
- arch-tag: 4b2c33bc-d7e4-43f5-bc20-27c0db52a53e
address@hidden ignore