Commit | Line | Data |
---|---|---|
b8d4c8d0 GM |
1 | @c -*-texinfo-*- |
2 | @c This is part of the GNU Emacs Lisp Reference Manual. | |
73b0cd50 | 3 | @c Copyright (C) 1990-1993, 1998-1999, 2001-2011 Free Software Foundation, Inc. |
b8d4c8d0 | 4 | @c See the file elisp.texi for copying conditions. |
6336d8c3 | 5 | @setfilename ../../info/internals |
b8d4c8d0 GM |
6 | @node GNU Emacs Internals, Standard Errors, Tips, Top |
7 | @comment node-name, next, previous, up | |
8 | @appendix GNU Emacs Internals | |
9 | ||
10 | This chapter describes how the runnable Emacs executable is dumped with | |
11 | the preloaded Lisp libraries in it, how storage is allocated, and some | |
12 | internal aspects of GNU Emacs that may be of interest to C programmers. | |
13 | ||
14 | @menu | |
15 | * Building Emacs:: How the dumped Emacs is made. | |
333f9019 | 16 | * Pure Storage:: Kludge to make preloaded Lisp functions shareable. |
b8d4c8d0 GM |
17 | * Garbage Collection:: Reclaiming space for Lisp objects no longer used. |
18 | * Memory Usage:: Info about total size of Lisp objects made so far. | |
19 | * Writing Emacs Primitives:: Writing C code for Emacs. | |
20 | * Object Internals:: Data formats of buffers, windows, processes. | |
21 | @end menu | |
22 | ||
23 | @node Building Emacs | |
24 | @appendixsec Building Emacs | |
25 | @cindex building Emacs | |
26 | @pindex temacs | |
27 | ||
28 | This section explains the steps involved in building the Emacs | |
29 | executable. You don't have to know this material to build and install | |
30 | Emacs, since the makefiles do all these things automatically. This | |
31 | information is pertinent to Emacs maintenance. | |
32 | ||
33 | Compilation of the C source files in the @file{src} directory | |
34 | produces an executable file called @file{temacs}, also called a | |
35 | @dfn{bare impure Emacs}. It contains the Emacs Lisp interpreter and I/O | |
36 | routines, but not the editing commands. | |
37 | ||
38 | @cindex @file{loadup.el} | |
39 | The command @w{@samp{temacs -l loadup}} uses @file{temacs} to create | |
40 | the real runnable Emacs executable. These arguments direct | |
41 | @file{temacs} to evaluate the Lisp files specified in the file | |
42 | @file{loadup.el}. These files set up the normal Emacs editing | |
43 | environment, resulting in an Emacs that is still impure but no longer | |
44 | bare. | |
45 | ||
46 | @cindex dumping Emacs | |
47 | It takes a substantial time to load the standard Lisp files. Luckily, | |
48 | you don't have to do this each time you run Emacs; @file{temacs} can | |
49 | dump out an executable program called @file{emacs} that has these files | |
50 | preloaded. @file{emacs} starts more quickly because it does not need to | |
51 | load the files. This is the Emacs executable that is normally | |
52 | installed. | |
53 | ||
b578c9cc GM |
54 | @vindex preloaded-file-list |
55 | @cindex dumped Lisp files | |
b8d4c8d0 GM |
56 | To create @file{emacs}, use the command @samp{temacs -batch -l loadup |
57 | dump}. The purpose of @samp{-batch} here is to prevent @file{temacs} | |
58 | from trying to initialize any of its data on the terminal; this ensures | |
59 | that the tables of terminal information are empty in the dumped Emacs. | |
60 | The argument @samp{dump} tells @file{loadup.el} to dump a new executable | |
b578c9cc GM |
61 | named @file{emacs}. The variable @code{preloaded-file-list} stores a |
62 | list of the Lisp files that were dumped with the @file{emacs} executable. | |
b8d4c8d0 GM |
63 | |
64 | Some operating systems don't support dumping. On those systems, you | |
65 | must start Emacs with the @samp{temacs -l loadup} command each time you | |
66 | use it. This takes a substantial time, but since you need to start | |
67 | Emacs once a day at most---or once a week if you never log out---the | |
68 | extra time is not too severe a problem. | |
69 | ||
70 | @cindex @file{site-load.el} | |
71 | ||
72 | You can specify additional files to preload by writing a library named | |
73 | @file{site-load.el} that loads them. You may need to add a definition | |
74 | ||
75 | @example | |
76 | #define SITELOAD_PURESIZE_EXTRA @var{n} | |
77 | @end example | |
78 | ||
79 | @noindent | |
80 | to make @var{n} added bytes of pure space to hold the additional files. | |
81 | (Try adding increments of 20000 until it is big enough.) However, the | |
82 | advantage of preloading additional files decreases as machines get | |
83 | faster. On modern machines, it is usually not advisable. | |
84 | ||
85 | After @file{loadup.el} reads @file{site-load.el}, it finds the | |
86 | documentation strings for primitive and preloaded functions (and | |
87 | variables) in the file @file{etc/DOC} where they are stored, by | |
88 | calling @code{Snarf-documentation} (@pxref{Definition of | |
89 | Snarf-documentation,, Accessing Documentation}). | |
90 | ||
91 | @cindex @file{site-init.el} | |
92 | @cindex preloading additional functions and variables | |
93 | You can specify other Lisp expressions to execute just before dumping | |
94 | by putting them in a library named @file{site-init.el}. This file is | |
95 | executed after the documentation strings are found. | |
96 | ||
97 | If you want to preload function or variable definitions, there are | |
98 | three ways you can do this and make their documentation strings | |
99 | accessible when you subsequently run Emacs: | |
100 | ||
101 | @itemize @bullet | |
102 | @item | |
103 | Arrange to scan these files when producing the @file{etc/DOC} file, | |
104 | and load them with @file{site-load.el}. | |
105 | ||
106 | @item | |
107 | Load the files with @file{site-init.el}, then copy the files into the | |
108 | installation directory for Lisp files when you install Emacs. | |
109 | ||
110 | @item | |
111 | Specify a non-@code{nil} value for | |
112 | @code{byte-compile-dynamic-docstrings} as a local variable in each of these | |
113 | files, and load them with either @file{site-load.el} or | |
114 | @file{site-init.el}. (This method has the drawback that the | |
115 | documentation strings take up space in Emacs all the time.) | |
116 | @end itemize | |
117 | ||
118 | It is not advisable to put anything in @file{site-load.el} or | |
119 | @file{site-init.el} that would alter any of the features that users | |
120 | expect in an ordinary unmodified Emacs. If you feel you must override | |
121 | normal features for your site, do it with @file{default.el}, so that | |
122 | users can override your changes if they wish. @xref{Startup Summary}. | |
123 | ||
124 | In a package that can be preloaded, it is sometimes useful to | |
125 | specify a computation to be done when Emacs subsequently starts up. | |
126 | For this, use @code{eval-at-startup}: | |
127 | ||
128 | @defmac eval-at-startup body@dots{} | |
129 | This evaluates the @var{body} forms, either immediately if running in | |
130 | an Emacs that has already started up, or later when Emacs does start | |
131 | up. Since the value of the @var{body} forms is not necessarily | |
132 | available when the @code{eval-at-startup} form is run, that form | |
133 | always returns @code{nil}. | |
134 | @end defmac | |
135 | ||
136 | @defun dump-emacs to-file from-file | |
137 | @cindex unexec | |
138 | This function dumps the current state of Emacs into an executable file | |
139 | @var{to-file}. It takes symbols from @var{from-file} (this is normally | |
140 | the executable file @file{temacs}). | |
141 | ||
142 | If you want to use this function in an Emacs that was already dumped, | |
143 | you must run Emacs with @samp{-batch}. | |
144 | @end defun | |
145 | ||
146 | @node Pure Storage | |
147 | @appendixsec Pure Storage | |
148 | @cindex pure storage | |
149 | ||
150 | Emacs Lisp uses two kinds of storage for user-created Lisp objects: | |
151 | @dfn{normal storage} and @dfn{pure storage}. Normal storage is where | |
152 | all the new data created during an Emacs session are kept; see the | |
153 | following section for information on normal storage. Pure storage is | |
154 | used for certain data in the preloaded standard Lisp files---data that | |
155 | should never change during actual use of Emacs. | |
156 | ||
157 | Pure storage is allocated only while @file{temacs} is loading the | |
158 | standard preloaded Lisp libraries. In the file @file{emacs}, it is | |
159 | marked as read-only (on operating systems that permit this), so that | |
160 | the memory space can be shared by all the Emacs jobs running on the | |
161 | machine at once. Pure storage is not expandable; a fixed amount is | |
162 | allocated when Emacs is compiled, and if that is not sufficient for | |
163 | the preloaded libraries, @file{temacs} allocates dynamic memory for | |
164 | the part that didn't fit. If that happens, you should increase the | |
165 | compilation parameter @code{PURESIZE} in the file | |
166 | @file{src/puresize.h} and rebuild Emacs, even though the resulting | |
167 | image will work: garbage collection is disabled in this situation, | |
168 | causing a memory leak. Such an overflow normally won't happen unless you | |
169 | try to preload additional libraries or add features to the standard | |
170 | ones. Emacs will display a warning about the overflow when it | |
171 | starts. | |
172 | ||
173 | @defun purecopy object | |
174 | This function makes a copy in pure storage of @var{object}, and returns | |
175 | it. It copies a string by simply making a new string with the same | |
176 | characters, but without text properties, in pure storage. It | |
177 | recursively copies the contents of vectors and cons cells. It does | |
178 | not make copies of other objects such as symbols, but just returns | |
179 | them unchanged. It signals an error if asked to copy markers. | |
180 | ||
181 | This function is a no-op except while Emacs is being built and dumped; | |
182 | it is usually called only in the file @file{emacs/lisp/loaddefs.el}, but | |
183 | a few packages call it just in case you decide to preload them. | |
184 | @end defun | |
185 | ||
186 | @defvar pure-bytes-used | |
187 | The value of this variable is the number of bytes of pure storage | |
188 | allocated so far. Typically, in a dumped Emacs, this number is very | |
189 | close to the total amount of pure storage available---if it were not, | |
190 | we would preallocate less. | |
191 | @end defvar | |
192 | ||
193 | @defvar purify-flag | |
194 | This variable determines whether @code{defun} should make a copy of the | |
195 | function definition in pure storage. If it is non-@code{nil}, then the | |
196 | function definition is copied into pure storage. | |
197 | ||
198 | This flag is @code{t} while loading all of the basic functions for | |
333f9019 | 199 | building Emacs initially (allowing those functions to be shareable and |
b8d4c8d0 GM |
200 | non-collectible). Dumping Emacs as an executable always writes |
201 | @code{nil} in this variable, regardless of the value it actually has | |
202 | before and after dumping. | |
203 | ||
204 | You should not change this flag in a running Emacs. | |
205 | @end defvar | |
206 | ||
207 | @node Garbage Collection | |
208 | @appendixsec Garbage Collection | |
209 | @cindex garbage collection | |
210 | ||
211 | @cindex memory allocation | |
212 | When a program creates a list or the user defines a new function (such | |
213 | as by loading a library), that data is placed in normal storage. If | |
214 | normal storage runs low, then Emacs asks the operating system to | |
215 | allocate more memory in blocks of 1k bytes. Each block is used for one | |
216 | type of Lisp object, so symbols, cons cells, markers, etc., are | |
217 | segregated in distinct blocks in memory. (Vectors, long strings, | |
218 | buffers and certain other editing types, which are fairly large, are | |
219 | allocated in individual blocks, one per object, while small strings are | |
220 | packed into blocks of 8k bytes.) | |
221 | ||
222 | It is quite common to use some storage for a while, then release it by | |
223 | (for example) killing a buffer or deleting the last pointer to an | |
224 | object. Emacs provides a @dfn{garbage collector} to reclaim this | |
225 | abandoned storage. (This name is traditional, but ``garbage recycler'' | |
226 | might be a more intuitive metaphor for this facility.) | |
227 | ||
228 | The garbage collector operates by finding and marking all Lisp objects | |
229 | that are still accessible to Lisp programs. To begin with, it assumes | |
230 | all the symbols, their values and associated function definitions, and | |
231 | any data presently on the stack, are accessible. Any objects that can | |
232 | be reached indirectly through other accessible objects are also | |
233 | accessible. | |
234 | ||
235 | When marking is finished, all objects still unmarked are garbage. No | |
236 | matter what the Lisp program or the user does, it is impossible to refer | |
237 | to them, since there is no longer a way to reach them. Their space | |
238 | might as well be reused, since no one will miss them. The second | |
239 | (``sweep'') phase of the garbage collector arranges to reuse them. | |
240 | ||
241 | @c ??? Maybe add something describing weak hash tables here? | |
242 | ||
243 | @cindex free list | |
244 | The sweep phase puts unused cons cells onto a @dfn{free list} | |
245 | for future allocation; likewise for symbols and markers. It compacts | |
246 | the accessible strings so they occupy fewer 8k blocks; then it frees the | |
247 | other 8k blocks. Vectors, buffers, windows, and other large objects are | |
248 | individually allocated and freed using @code{malloc} and @code{free}. | |
249 | ||
250 | @cindex CL note---allocate more storage | |
251 | @quotation | |
252 | @b{Common Lisp note:} Unlike other Lisps, GNU Emacs Lisp does not | |
253 | call the garbage collector when the free list is empty. Instead, it | |
254 | simply requests the operating system to allocate more storage, and | |
255 | processing continues until @code{gc-cons-threshold} bytes have been | |
256 | used. | |
257 | ||
258 | This means that you can make sure that the garbage collector will not | |
259 | run during a certain portion of a Lisp program by calling the garbage | |
260 | collector explicitly just before it (provided that portion of the | |
261 | program does not use so much space as to force a second garbage | |
262 | collection). | |
263 | @end quotation | |
264 | ||
265 | @deffn Command garbage-collect | |
266 | This command runs a garbage collection, and returns information on | |
267 | the amount of space in use. (Garbage collection can also occur | |
268 | spontaneously if you use more than @code{gc-cons-threshold} bytes of | |
269 | Lisp data since the previous garbage collection.) | |
270 | ||
271 | @code{garbage-collect} returns a list containing the following | |
272 | information: | |
273 | ||
274 | @example | |
275 | @group | |
276 | ((@var{used-conses} . @var{free-conses}) | |
277 | (@var{used-syms} . @var{free-syms}) | |
278 | @end group | |
279 | (@var{used-miscs} . @var{free-miscs}) | |
280 | @var{used-string-chars} | |
281 | @var{used-vector-slots} | |
282 | (@var{used-floats} . @var{free-floats}) | |
283 | (@var{used-intervals} . @var{free-intervals}) | |
284 | (@var{used-strings} . @var{free-strings})) | |
285 | @end example | |
286 | ||
287 | Here is an example: | |
288 | ||
289 | @example | |
290 | @group | |
291 | (garbage-collect) | |
292 | @result{} ((106886 . 13184) (9769 . 0) | |
293 | (7731 . 4651) 347543 121628 | |
294 | (31 . 94) (1273 . 168) | |
295 | (25474 . 3569)) | |
296 | @end group | |
297 | @end example | |
298 | ||
299 | Here is a table explaining each element: | |
300 | ||
301 | @table @var | |
302 | @item used-conses | |
303 | The number of cons cells in use. | |
304 | ||
305 | @item free-conses | |
306 | The number of cons cells for which space has been obtained from the | |
307 | operating system, but that are not currently being used. | |
308 | ||
309 | @item used-syms | |
310 | The number of symbols in use. | |
311 | ||
312 | @item free-syms | |
313 | The number of symbols for which space has been obtained from the | |
314 | operating system, but that are not currently being used. | |
315 | ||
316 | @item used-miscs | |
317 | The number of miscellaneous objects in use. These include markers and | |
318 | overlays, plus certain objects not visible to users. | |
319 | ||
320 | @item free-miscs | |
321 | The number of miscellaneous objects for which space has been obtained | |
322 | from the operating system, but that are not currently being used. | |
323 | ||
324 | @item used-string-chars | |
325 | The total size of all strings, in characters. | |
326 | ||
327 | @item used-vector-slots | |
328 | The total number of elements of existing vectors. | |
329 | ||
330 | @item used-floats | |
331 | @c Emacs 19 feature | |
332 | The number of floats in use. | |
333 | ||
334 | @item free-floats | |
335 | @c Emacs 19 feature | |
336 | The number of floats for which space has been obtained from the | |
337 | operating system, but that are not currently being used. | |
338 | ||
339 | @item used-intervals | |
340 | The number of intervals in use. Intervals are an internal | |
341 | data structure used for representing text properties. | |
342 | ||
343 | @item free-intervals | |
344 | The number of intervals for which space has been obtained | |
345 | from the operating system, but that are not currently being used. | |
346 | ||
347 | @item used-strings | |
348 | The number of strings in use. | |
349 | ||
350 | @item free-strings | |
351 | The number of string headers for which the space was obtained from the | |
352 | operating system, but which are currently not in use. (A string | |
353 | object consists of a header and the storage for the string text | |
354 | itself; the latter is only allocated when the string is created.) | |
355 | @end table | |
356 | ||
357 | If there was overflow in pure space (see the previous section), | |
358 | @code{garbage-collect} returns @code{nil}, because a real garbage | |
359 | collection can not be done in this situation. | |
360 | @end deffn | |
361 | ||
362 | @defopt garbage-collection-messages | |
363 | If this variable is non-@code{nil}, Emacs displays a message at the | |
364 | beginning and end of garbage collection. The default value is | |
365 | @code{nil}, meaning there are no such messages. | |
366 | @end defopt | |
367 | ||
368 | @defvar post-gc-hook | |
369 | This is a normal hook that is run at the end of garbage collection. | |
370 | Garbage collection is inhibited while the hook functions run, so be | |
371 | careful writing them. | |
372 | @end defvar | |
373 | ||
374 | @defopt gc-cons-threshold | |
375 | The value of this variable is the number of bytes of storage that must | |
376 | be allocated for Lisp objects after one garbage collection in order to | |
377 | trigger another garbage collection. A cons cell counts as eight bytes, | |
378 | a string as one byte per character plus a few bytes of overhead, and so | |
379 | on; space allocated to the contents of buffers does not count. Note | |
380 | that the subsequent garbage collection does not happen immediately when | |
381 | the threshold is exhausted, but only the next time the Lisp evaluator is | |
382 | called. | |
383 | ||
384 | The initial threshold value is 400,000. If you specify a larger | |
385 | value, garbage collection will happen less often. This reduces the | |
386 | amount of time spent garbage collecting, but increases total memory use. | |
387 | You may want to do this when running a program that creates lots of | |
388 | Lisp data. | |
389 | ||
390 | You can make collections more frequent by specifying a smaller value, | |
391 | down to 10,000. A value less than 10,000 will remain in effect only | |
392 | until the subsequent garbage collection, at which time | |
393 | @code{garbage-collect} will set the threshold back to 10,000. | |
394 | @end defopt | |
395 | ||
396 | @defopt gc-cons-percentage | |
397 | The value of this variable specifies the amount of consing before a | |
398 | garbage collection occurs, as a fraction of the current heap size. | |
399 | This criterion and @code{gc-cons-threshold} apply in parallel, and | |
400 | garbage collection occurs only when both criteria are satisfied. | |
401 | ||
402 | As the heap size increases, the time to perform a garbage collection | |
403 | increases. Thus, it can be desirable to do them less frequently in | |
404 | proportion. | |
405 | @end defopt | |
406 | ||
407 | The value returned by @code{garbage-collect} describes the amount of | |
408 | memory used by Lisp data, broken down by data type. By contrast, the | |
409 | function @code{memory-limit} provides information on the total amount of | |
410 | memory Emacs is currently using. | |
411 | ||
412 | @c Emacs 19 feature | |
413 | @defun memory-limit | |
414 | This function returns the address of the last byte Emacs has allocated, | |
415 | divided by 1024. We divide the value by 1024 to make sure it fits in a | |
416 | Lisp integer. | |
417 | ||
418 | You can use this to get a general idea of how your actions affect the | |
419 | memory usage. | |
420 | @end defun | |
421 | ||
422 | @defvar memory-full | |
423 | This variable is @code{t} if Emacs is close to out of memory for Lisp | |
424 | objects, and @code{nil} otherwise. | |
425 | @end defvar | |
426 | ||
427 | @defun memory-use-counts | |
428 | This returns a list of numbers that count the number of objects | |
429 | created in this Emacs session. Each of these counters increments for | |
430 | a certain kind of object. See the documentation string for details. | |
431 | @end defun | |
432 | ||
433 | @defvar gcs-done | |
434 | This variable contains the total number of garbage collections | |
435 | done so far in this Emacs session. | |
436 | @end defvar | |
437 | ||
438 | @defvar gc-elapsed | |
439 | This variable contains the total number of seconds of elapsed time | |
440 | during garbage collection so far in this Emacs session, as a floating | |
441 | point number. | |
442 | @end defvar | |
443 | ||
444 | @node Memory Usage | |
445 | @section Memory Usage | |
446 | @cindex memory usage | |
447 | ||
448 | These functions and variables give information about the total amount | |
449 | of memory allocation that Emacs has done, broken down by data type. | |
450 | Note the difference between these and the values returned by | |
451 | @code{(garbage-collect)}; those count objects that currently exist, but | |
452 | these count the number or size of all allocations, including those for | |
453 | objects that have since been freed. | |
454 | ||
455 | @defvar cons-cells-consed | |
456 | The total number of cons cells that have been allocated so far | |
457 | in this Emacs session. | |
458 | @end defvar | |
459 | ||
460 | @defvar floats-consed | |
461 | The total number of floats that have been allocated so far | |
462 | in this Emacs session. | |
463 | @end defvar | |
464 | ||
465 | @defvar vector-cells-consed | |
466 | The total number of vector cells that have been allocated so far | |
467 | in this Emacs session. | |
468 | @end defvar | |
469 | ||
470 | @defvar symbols-consed | |
471 | The total number of symbols that have been allocated so far | |
472 | in this Emacs session. | |
473 | @end defvar | |
474 | ||
475 | @defvar string-chars-consed | |
476 | The total number of string characters that have been allocated so far | |
477 | in this Emacs session. | |
478 | @end defvar | |
479 | ||
480 | @defvar misc-objects-consed | |
481 | The total number of miscellaneous objects that have been allocated so | |
482 | far in this Emacs session. These include markers and overlays, plus | |
483 | certain objects not visible to users. | |
484 | @end defvar | |
485 | ||
486 | @defvar intervals-consed | |
487 | The total number of intervals that have been allocated so far | |
488 | in this Emacs session. | |
489 | @end defvar | |
490 | ||
491 | @defvar strings-consed | |
492 | The total number of strings that have been allocated so far in this | |
493 | Emacs session. | |
494 | @end defvar | |
495 | ||
496 | @node Writing Emacs Primitives | |
497 | @appendixsec Writing Emacs Primitives | |
498 | @cindex primitive function internals | |
499 | @cindex writing Emacs primitives | |
500 | ||
501 | Lisp primitives are Lisp functions implemented in C. The details of | |
502 | interfacing the C function so that Lisp can call it are handled by a few | |
503 | C macros. The only way to really understand how to write new C code is | |
504 | to read the source, but we can explain some things here. | |
505 | ||
506 | An example of a special form is the definition of @code{or}, from | |
507 | @file{eval.c}. (An ordinary function would have the same general | |
508 | appearance.) | |
509 | ||
510 | @cindex garbage collection protection | |
511 | @smallexample | |
512 | @group | |
513 | DEFUN ("or", For, Sor, 0, UNEVALLED, 0, | |
514 | doc: /* Eval args until one of them yields non-nil, then return that | |
515 | value. The remaining args are not evalled at all. | |
516 | If all args return nil, return nil. | |
517 | @end group | |
518 | @group | |
519 | usage: (or CONDITIONS ...) */) | |
b88746ba | 520 | (Lisp_Object args) |
b8d4c8d0 GM |
521 | @{ |
522 | register Lisp_Object val = Qnil; | |
523 | struct gcpro gcpro1; | |
524 | @end group | |
525 | ||
526 | @group | |
527 | GCPRO1 (args); | |
528 | @end group | |
529 | ||
530 | @group | |
531 | while (CONSP (args)) | |
532 | @{ | |
533 | val = Feval (XCAR (args)); | |
534 | if (!NILP (val)) | |
535 | break; | |
536 | args = XCDR (args); | |
537 | @} | |
538 | @end group | |
539 | ||
540 | @group | |
541 | UNGCPRO; | |
542 | return val; | |
543 | @} | |
544 | @end group | |
545 | @end smallexample | |
546 | ||
547 | @cindex @code{DEFUN}, C macro to define Lisp primitives | |
548 | Let's start with a precise explanation of the arguments to the | |
549 | @code{DEFUN} macro. Here is a template for them: | |
550 | ||
551 | @example | |
552 | DEFUN (@var{lname}, @var{fname}, @var{sname}, @var{min}, @var{max}, @var{interactive}, @var{doc}) | |
553 | @end example | |
554 | ||
555 | @table @var | |
556 | @item lname | |
557 | This is the name of the Lisp symbol to define as the function name; in | |
558 | the example above, it is @code{or}. | |
559 | ||
560 | @item fname | |
561 | This is the C function name for this function. This is | |
562 | the name that is used in C code for calling the function. The name is, | |
563 | by convention, @samp{F} prepended to the Lisp name, with all dashes | |
564 | (@samp{-}) in the Lisp name changed to underscores. Thus, to call this | |
565 | function from C code, call @code{For}. Remember that the arguments must | |
566 | be of type @code{Lisp_Object}; various macros and functions for creating | |
567 | values of type @code{Lisp_Object} are declared in the file | |
568 | @file{lisp.h}. | |
569 | ||
570 | @item sname | |
571 | This is a C variable name to use for a structure that holds the data for | |
572 | the subr object that represents the function in Lisp. This structure | |
573 | conveys the Lisp symbol name to the initialization routine that will | |
574 | create the symbol and store the subr object as its definition. By | |
575 | convention, this name is always @var{fname} with @samp{F} replaced with | |
576 | @samp{S}. | |
577 | ||
578 | @item min | |
579 | This is the minimum number of arguments that the function requires. The | |
580 | function @code{or} allows a minimum of zero arguments. | |
581 | ||
582 | @item max | |
583 | This is the maximum number of arguments that the function accepts, if | |
584 | there is a fixed maximum. Alternatively, it can be @code{UNEVALLED}, | |
585 | indicating a special form that receives unevaluated arguments, or | |
586 | @code{MANY}, indicating an unlimited number of evaluated arguments (the | |
587 | equivalent of @code{&rest}). Both @code{UNEVALLED} and @code{MANY} are | |
588 | macros. If @var{max} is a number, it may not be less than @var{min} and | |
589 | it may not be greater than eight. | |
590 | ||
591 | @item interactive | |
592 | This is an interactive specification, a string such as might be used as | |
593 | the argument of @code{interactive} in a Lisp function. In the case of | |
594 | @code{or}, it is 0 (a null pointer), indicating that @code{or} cannot be | |
595 | called interactively. A value of @code{""} indicates a function that | |
2c30e468 EZ |
596 | should receive no arguments when called interactively. If the value |
597 | begins with a @samp{(}, the string is evaluated as a Lisp form. | |
b8d4c8d0 GM |
598 | |
599 | @item doc | |
600 | This is the documentation string. It uses C comment syntax rather | |
601 | than C string syntax because comment syntax requires nothing special | |
602 | to include multiple lines. The @samp{doc:} identifies the comment | |
603 | that follows as the documentation string. The @samp{/*} and @samp{*/} | |
604 | delimiters that begin and end the comment are not part of the | |
605 | documentation string. | |
606 | ||
607 | If the last line of the documentation string begins with the keyword | |
608 | @samp{usage:}, the rest of the line is treated as the argument list | |
609 | for documentation purposes. This way, you can use different argument | |
610 | names in the documentation string from the ones used in the C code. | |
611 | @samp{usage:} is required if the function has an unlimited number of | |
612 | arguments. | |
613 | ||
614 | All the usual rules for documentation strings in Lisp code | |
615 | (@pxref{Documentation Tips}) apply to C code documentation strings | |
616 | too. | |
617 | @end table | |
618 | ||
b88746ba EZ |
619 | After the call to the @code{DEFUN} macro, you must write the |
620 | argument list that every C function must have, including the types for | |
621 | the arguments. For a function with a fixed maximum number of | |
622 | arguments, declare a C argument for each Lisp argument, and give them | |
623 | all type @code{Lisp_Object}. When a Lisp function has no upper limit | |
624 | on the number of arguments, its implementation in C actually receives | |
625 | exactly two arguments: the first is the number of Lisp arguments, and | |
626 | the second is the address of a block containing their values. They | |
627 | have types @code{int} and @w{@code{Lisp_Object *}}. | |
b8d4c8d0 GM |
628 | |
629 | @cindex @code{GCPRO} and @code{UNGCPRO} | |
630 | @cindex protect C variables from garbage collection | |
631 | Within the function @code{For} itself, note the use of the macros | |
632 | @code{GCPRO1} and @code{UNGCPRO}. @code{GCPRO1} is used to | |
633 | ``protect'' a variable from garbage collection---to inform the garbage | |
634 | collector that it must look in that variable and regard its contents | |
635 | as an accessible object. GC protection is necessary whenever you call | |
636 | @code{Feval} or anything that can directly or indirectly call | |
637 | @code{Feval}. At such a time, any Lisp object that this function may | |
638 | refer to again must be protected somehow. | |
639 | ||
640 | It suffices to ensure that at least one pointer to each object is | |
641 | GC-protected; that way, the object cannot be recycled, so all pointers | |
642 | to it remain valid. Thus, a particular local variable can do without | |
643 | protection if it is certain that the object it points to will be | |
644 | preserved by some other pointer (such as another local variable which | |
645 | has a @code{GCPRO})@footnote{Formerly, strings were a special | |
646 | exception; in older Emacs versions, every local variable that might | |
647 | point to a string needed a @code{GCPRO}.}. Otherwise, the local | |
648 | variable needs a @code{GCPRO}. | |
649 | ||
650 | The macro @code{GCPRO1} protects just one local variable. If you | |
651 | want to protect two variables, use @code{GCPRO2} instead; repeating | |
652 | @code{GCPRO1} will not work. Macros @code{GCPRO3}, @code{GCPRO4}, | |
653 | @code{GCPRO5}, and @code{GCPRO6} also exist. All these macros | |
654 | implicitly use local variables such as @code{gcpro1}; you must declare | |
655 | these explicitly, with type @code{struct gcpro}. Thus, if you use | |
656 | @code{GCPRO2}, you must declare @code{gcpro1} and @code{gcpro2}. | |
657 | Alas, we can't explain all the tricky details here. | |
658 | ||
659 | @code{UNGCPRO} cancels the protection of the variables that are | |
660 | protected in the current function. It is necessary to do this | |
661 | explicitly. | |
662 | ||
663 | Built-in functions that take a variable number of arguments actually | |
664 | accept two arguments at the C level: the number of Lisp arguments, and | |
665 | a @code{Lisp_Object *} pointer to a C vector containing those Lisp | |
666 | arguments. This C vector may be part of a Lisp vector, but it need | |
667 | not be. The responsibility for using @code{GCPRO} to protect the Lisp | |
668 | arguments from GC if necessary rests with the caller in this case, | |
669 | since the caller allocated or found the storage for them. | |
670 | ||
671 | You must not use C initializers for static or global variables unless | |
672 | the variables are never written once Emacs is dumped. These variables | |
673 | with initializers are allocated in an area of memory that becomes | |
674 | read-only (on certain operating systems) as a result of dumping Emacs. | |
675 | @xref{Pure Storage}. | |
676 | ||
677 | Do not use static variables within functions---place all static | |
678 | variables at top level in the file. This is necessary because Emacs on | |
679 | some operating systems defines the keyword @code{static} as a null | |
680 | macro. (This definition is used because those systems put all variables | |
681 | declared static in a place that becomes read-only after dumping, whether | |
682 | they have initializers or not.) | |
683 | ||
684 | @cindex @code{defsubr}, Lisp symbol for a primitive | |
685 | Defining the C function is not enough to make a Lisp primitive | |
686 | available; you must also create the Lisp symbol for the primitive and | |
687 | store a suitable subr object in its function cell. The code looks like | |
688 | this: | |
689 | ||
690 | @example | |
691 | defsubr (&@var{subr-structure-name}); | |
692 | @end example | |
693 | ||
694 | @noindent | |
695 | Here @var{subr-structure-name} is the name you used as the third | |
696 | argument to @code{DEFUN}. | |
697 | ||
698 | If you add a new primitive to a file that already has Lisp primitives | |
699 | defined in it, find the function (near the end of the file) named | |
700 | @code{syms_of_@var{something}}, and add the call to @code{defsubr} | |
701 | there. If the file doesn't have this function, or if you create a new | |
702 | file, add to it a @code{syms_of_@var{filename}} (e.g., | |
703 | @code{syms_of_myfile}). Then find the spot in @file{emacs.c} where all | |
704 | of these functions are called, and add a call to | |
705 | @code{syms_of_@var{filename}} there. | |
706 | ||
707 | @anchor{Defining Lisp variables in C} | |
708 | @vindex byte-boolean-vars | |
709 | @cindex defining Lisp variables in C | |
710 | @cindex @code{DEFVAR_INT}, @code{DEFVAR_LISP}, @code{DEFVAR_BOOL} | |
711 | The function @code{syms_of_@var{filename}} is also the place to define | |
712 | any C variables that are to be visible as Lisp variables. | |
713 | @code{DEFVAR_LISP} makes a C variable of type @code{Lisp_Object} visible | |
714 | in Lisp. @code{DEFVAR_INT} makes a C variable of type @code{int} | |
715 | visible in Lisp with a value that is always an integer. | |
716 | @code{DEFVAR_BOOL} makes a C variable of type @code{int} visible in Lisp | |
717 | with a value that is either @code{t} or @code{nil}. Note that variables | |
718 | defined with @code{DEFVAR_BOOL} are automatically added to the list | |
719 | @code{byte-boolean-vars} used by the byte compiler. | |
720 | ||
721 | @cindex @code{staticpro}, protection from GC | |
722 | If you define a file-scope C variable of type @code{Lisp_Object}, | |
723 | you must protect it from garbage-collection by calling @code{staticpro} | |
724 | in @code{syms_of_@var{filename}}, like this: | |
725 | ||
726 | @example | |
727 | staticpro (&@var{variable}); | |
728 | @end example | |
729 | ||
730 | Here is another example function, with more complicated arguments. | |
731 | This comes from the code in @file{window.c}, and it demonstrates the use | |
732 | of macros and functions to manipulate Lisp objects. | |
733 | ||
734 | @smallexample | |
735 | @group | |
736 | DEFUN ("coordinates-in-window-p", Fcoordinates_in_window_p, | |
737 | Scoordinates_in_window_p, 2, 2, | |
738 | "xSpecify coordinate pair: \nXExpression which evals to window: ", | |
739 | "Return non-nil if COORDINATES is in WINDOW.\n\ | |
740 | COORDINATES is a cons of the form (X . Y), X and Y being distances\n\ | |
741 | ... | |
742 | @end group | |
743 | @group | |
744 | If they are on the border between WINDOW and its right sibling,\n\ | |
745 | `vertical-line' is returned.") | |
746 | (coordinates, window) | |
747 | register Lisp_Object coordinates, window; | |
748 | @{ | |
749 | int x, y; | |
750 | @end group | |
751 | ||
752 | @group | |
753 | CHECK_LIVE_WINDOW (window, 0); | |
754 | CHECK_CONS (coordinates, 1); | |
755 | x = XINT (Fcar (coordinates)); | |
756 | y = XINT (Fcdr (coordinates)); | |
757 | @end group | |
758 | ||
759 | @group | |
760 | switch (coordinates_in_window (XWINDOW (window), &x, &y)) | |
761 | @{ | |
d24880de | 762 | case 0: /* NOT in window at all. */ |
b8d4c8d0 GM |
763 | return Qnil; |
764 | @end group | |
765 | ||
766 | @group | |
d24880de | 767 | case 1: /* In text part of window. */ |
b8d4c8d0 GM |
768 | return Fcons (make_number (x), make_number (y)); |
769 | @end group | |
770 | ||
771 | @group | |
d24880de | 772 | case 2: /* In mode line of window. */ |
b8d4c8d0 GM |
773 | return Qmode_line; |
774 | @end group | |
775 | ||
776 | @group | |
d24880de | 777 | case 3: /* On right border of window. */ |
b8d4c8d0 GM |
778 | return Qvertical_line; |
779 | @end group | |
780 | ||
781 | @group | |
782 | default: | |
783 | abort (); | |
784 | @} | |
785 | @} | |
786 | @end group | |
787 | @end smallexample | |
788 | ||
789 | Note that C code cannot call functions by name unless they are defined | |
790 | in C. The way to call a function written in Lisp is to use | |
791 | @code{Ffuncall}, which embodies the Lisp function @code{funcall}. Since | |
792 | the Lisp function @code{funcall} accepts an unlimited number of | |
793 | arguments, in C it takes two: the number of Lisp-level arguments, and a | |
794 | one-dimensional array containing their values. The first Lisp-level | |
795 | argument is the Lisp function to call, and the rest are the arguments to | |
796 | pass to it. Since @code{Ffuncall} can call the evaluator, you must | |
797 | protect pointers from garbage collection around the call to | |
798 | @code{Ffuncall}. | |
799 | ||
800 | The C functions @code{call0}, @code{call1}, @code{call2}, and so on, | |
801 | provide handy ways to call a Lisp function conveniently with a fixed | |
802 | number of arguments. They work by calling @code{Ffuncall}. | |
803 | ||
804 | @file{eval.c} is a very good file to look through for examples; | |
805 | @file{lisp.h} contains the definitions for some important macros and | |
806 | functions. | |
807 | ||
808 | If you define a function which is side-effect free, update the code | |
809 | in @file{byte-opt.el} which binds @code{side-effect-free-fns} and | |
810 | @code{side-effect-and-error-free-fns} so that the compiler optimizer | |
811 | knows about it. | |
812 | ||
813 | @node Object Internals | |
814 | @appendixsec Object Internals | |
815 | @cindex object internals | |
816 | ||
817 | GNU Emacs Lisp manipulates many different types of data. The actual | |
818 | data are stored in a heap and the only access that programs have to it | |
c773345a CY |
819 | is through pointers. Each pointer is 32 bits wide on 32-bit machines, |
820 | and 64 bits wide on 64-bit machines; three of these bits are used for | |
821 | the tag that identifies the object's type, and the remainder are used | |
822 | to address the object. | |
b8d4c8d0 GM |
823 | |
824 | Because Lisp objects are represented as tagged pointers, it is always | |
825 | possible to determine the Lisp data type of any object. The C data type | |
826 | @code{Lisp_Object} can hold any Lisp object of any data type. Ordinary | |
827 | variables have type @code{Lisp_Object}, which means they can hold any | |
828 | type of Lisp value; you can determine the actual data type only at run | |
829 | time. The same is true for function arguments; if you want a function | |
830 | to accept only a certain type of argument, you must check the type | |
831 | explicitly using a suitable predicate (@pxref{Type Predicates}). | |
832 | @cindex type checking internals | |
833 | ||
834 | @menu | |
835 | * Buffer Internals:: Components of a buffer structure. | |
836 | * Window Internals:: Components of a window structure. | |
837 | * Process Internals:: Components of a process structure. | |
838 | @end menu | |
839 | ||
840 | @node Buffer Internals | |
841 | @appendixsubsec Buffer Internals | |
842 | @cindex internals, of buffer | |
843 | @cindex buffer internals | |
844 | ||
c773345a | 845 | Two structures are used to represent buffers in C. The |
b8d4c8d0 GM |
846 | @code{buffer_text} structure contains fields describing the text of a |
847 | buffer; the @code{buffer} structure holds other fields. In the case | |
848 | of indirect buffers, two or more @code{buffer} structures reference | |
849 | the same @code{buffer_text} structure. | |
850 | ||
c773345a | 851 | Here are some of the fields in @code{struct buffer_text}: |
b8d4c8d0 GM |
852 | |
853 | @table @code | |
854 | @item beg | |
c773345a | 855 | The address of the buffer contents. |
b8d4c8d0 GM |
856 | |
857 | @item gpt | |
c773345a CY |
858 | @itemx gpt_byte |
859 | The character and byte positions of the buffer gap. @xref{Buffer | |
860 | Gap}. | |
b8d4c8d0 GM |
861 | |
862 | @item z | |
c773345a CY |
863 | @itemx z_byte |
864 | The character and byte positions of the end of the buffer text. | |
b8d4c8d0 GM |
865 | |
866 | @item gap_size | |
c773345a | 867 | The size of buffer's gap. @xref{Buffer Gap}. |
b8d4c8d0 GM |
868 | |
869 | @item modiff | |
c773345a CY |
870 | @itemx save_modiff |
871 | @itemx chars_modiff | |
872 | @itemx overlay_modiff | |
873 | These fields count the number of buffer-modification events performed | |
874 | in this buffer. @code{modiff} is incremented after each | |
875 | buffer-modification event, and is never otherwise changed; | |
876 | @code{save_modiff} contains the value of @code{modiff} the last time | |
877 | the buffer was visited or saved; @code{chars_modiff} counts only | |
878 | modifications to the characters in the buffer, ignoring all other | |
879 | kinds of changes; and @code{overlay_modiff} counts only modifications | |
880 | to the overlays. | |
b8d4c8d0 GM |
881 | |
882 | @item beg_unchanged | |
c773345a CY |
883 | @itemx end_unchanged |
884 | The number of characters at the start and end of the text that are | |
885 | known to be unchanged since the last complete redisplay. | |
b8d4c8d0 GM |
886 | |
887 | @item unchanged_modified | |
c773345a CY |
888 | @itemx overlay_unchanged_modified |
889 | The values of @code{modiff} and @code{overlay_modiff}, respectively, | |
da6062e6 | 890 | after the last complete redisplay. If their current values match |
c773345a | 891 | @code{modiff} or @code{overlay_modiff}, that means |
b8d4c8d0 GM |
892 | @code{beg_unchanged} and @code{end_unchanged} contain no useful |
893 | information. | |
894 | ||
895 | @item markers | |
896 | The markers that refer to this buffer. This is actually a single | |
897 | marker, and successive elements in its marker @code{chain} are the other | |
898 | markers referring to this buffer text. | |
899 | ||
900 | @item intervals | |
c773345a | 901 | The interval tree which records the text properties of this buffer. |
b8d4c8d0 GM |
902 | @end table |
903 | ||
c773345a | 904 | Some of the fields of @code{struct buffer} are: |
b8d4c8d0 GM |
905 | |
906 | @table @code | |
907 | @item next | |
c773345a CY |
908 | Points to the next buffer, in the chain of all buffers (including |
909 | killed buffers). This chain is used only for garbage collection, in | |
910 | order to collect killed buffers properly. Note that vectors, and most | |
911 | kinds of objects allocated as vectors, are all on one chain, but | |
912 | buffers are on a separate chain of their own. | |
b8d4c8d0 GM |
913 | |
914 | @item own_text | |
c773345a CY |
915 | A @code{struct buffer_text} structure that ordinarily holds the buffer |
916 | contents. In indirect buffers, this field is not used. | |
b8d4c8d0 GM |
917 | |
918 | @item text | |
c773345a CY |
919 | A pointer to the @code{buffer_text} structure for this buffer. In an |
920 | ordinary buffer, this is the @code{own_text} field above. In an | |
921 | indirect buffer, this is the @code{own_text} field of the base buffer. | |
b8d4c8d0 GM |
922 | |
923 | @item pt | |
c773345a CY |
924 | @itemx pt_byte |
925 | The character and byte positions of point in a buffer. | |
b8d4c8d0 GM |
926 | |
927 | @item begv | |
c773345a CY |
928 | @itemx begv_byte |
929 | The character and byte positions of the beginning of the accessible | |
930 | range of text in the buffer. | |
b8d4c8d0 GM |
931 | |
932 | @item zv | |
c773345a CY |
933 | @itemx zv_byte |
934 | The character and byte positions of the end of the accessible range of | |
935 | text in the buffer. | |
b8d4c8d0 GM |
936 | |
937 | @item base_buffer | |
938 | In an indirect buffer, this points to the base buffer. In an ordinary | |
939 | buffer, it is null. | |
940 | ||
c773345a CY |
941 | @item local_flags |
942 | This field contains flags indicating that certain variables are local | |
943 | in this buffer. Such variables are declared in the C code using | |
944 | @code{DEFVAR_PER_BUFFER}, and their buffer-local bindings are stored | |
945 | in fields in the buffer structure itself. (Some of these fields are | |
b8d4c8d0 GM |
946 | described in this table.) |
947 | ||
948 | @item modtime | |
c773345a CY |
949 | The modification time of the visited file. It is set when the file is |
950 | written or read. Before writing the buffer into a file, this field is | |
951 | compared to the modification time of the file to see if the file has | |
952 | changed on disk. @xref{Buffer Modification}. | |
b8d4c8d0 GM |
953 | |
954 | @item auto_save_modified | |
c773345a | 955 | The time when the buffer was last auto-saved. |
b8d4c8d0 GM |
956 | |
957 | @item last_window_start | |
c773345a CY |
958 | The @code{window-start} position in the buffer as of the last time the |
959 | buffer was displayed in a window. | |
b8d4c8d0 GM |
960 | |
961 | @item clip_changed | |
c773345a CY |
962 | This flag indicates that narrowing has changed in the buffer. |
963 | @xref{Narrowing}. | |
b8d4c8d0 GM |
964 | |
965 | @item prevent_redisplay_optimizations_p | |
c773345a CY |
966 | This flag indicates that redisplay optimizations should not be used to |
967 | display this buffer. | |
b8d4c8d0 | 968 | |
c773345a CY |
969 | @item overlay_center |
970 | This field holds the current overlay center position. @xref{Managing | |
971 | Overlays}. | |
972 | ||
973 | @item overlays_before | |
974 | @itemx overlays_after | |
975 | These fields hold, respectively, a list of overlays that end at or | |
976 | before the current overlay center, and a list of overlays that end | |
977 | after the current overlay center. @xref{Managing Overlays}. | |
978 | @code{overlays_before} is sorted in order of decreasing end position, | |
979 | and @code{overlays_after} is sorted in order of increasing beginning | |
980 | position. | |
b8d4c8d0 GM |
981 | |
982 | @item name | |
c773345a CY |
983 | A Lisp string that names the buffer. It is guaranteed to be unique. |
984 | @xref{Buffer Names}. | |
b8d4c8d0 | 985 | |
c773345a CY |
986 | @item save_length |
987 | The length of the file this buffer is visiting, when last read or | |
988 | saved. This and other fields concerned with saving are not kept in | |
989 | the @code{buffer_text} structure because indirect buffers are never | |
990 | saved. | |
b8d4c8d0 GM |
991 | |
992 | @item directory | |
c773345a CY |
993 | The directory for expanding relative file names. This is the value of |
994 | the buffer-local variable @code{default-directory} (@pxref{File Name Expansion}). | |
b8d4c8d0 | 995 | |
c773345a CY |
996 | @item filename |
997 | The name of the file visited in this buffer, or @code{nil}. This is | |
998 | the value of the buffer-local variable @code{buffer-file-name} | |
999 | (@pxref{Buffer File Name}). | |
b8d4c8d0 | 1000 | |
c773345a CY |
1001 | @item undo_list |
1002 | @itemx backed_up | |
1003 | @itemx auto_save_file_name | |
1004 | @itemx read_only | |
1005 | @itemx file_format | |
1006 | @itemx file_truename | |
1007 | @itemx invisibility_spec | |
1008 | @itemx display_count | |
1009 | @itemx display_time | |
1010 | These fields store the values of Lisp variables that are automatically | |
1011 | buffer-local (@pxref{Buffer-Local Variables}), whose corresponding | |
1012 | variable names have the additional prefix @code{buffer-} and have | |
1013 | underscores replaced with dashes. For instance, @code{undo_list} | |
1014 | stores the value of @code{buffer-undo-list}. @xref{Standard | |
1015 | Buffer-Local Variables}. | |
b8d4c8d0 GM |
1016 | |
1017 | @item mark | |
c773345a CY |
1018 | The mark for the buffer. The mark is a marker, hence it is also |
1019 | included on the list @code{markers}. @xref{The Mark}. | |
b8d4c8d0 GM |
1020 | |
1021 | @item local_var_alist | |
c773345a CY |
1022 | The association list describing the buffer-local variable bindings of |
1023 | this buffer, not including the built-in buffer-local bindings that | |
1024 | have special slots in the buffer object. (Those slots are omitted | |
1025 | from this table.) @xref{Buffer-Local Variables}. | |
b8d4c8d0 GM |
1026 | |
1027 | @item major_mode | |
1028 | Symbol naming the major mode of this buffer, e.g., @code{lisp-mode}. | |
1029 | ||
1030 | @item mode_name | |
c773345a | 1031 | Pretty name of the major mode, e.g., @code{"Lisp"}. |
b8d4c8d0 GM |
1032 | |
1033 | @item keymap | |
c773345a CY |
1034 | @itemx abbrev_table |
1035 | @itemx syntax_table | |
1036 | @itemx category_table | |
1037 | @itemx display_table | |
1038 | These fields store the buffer's local keymap (@pxref{Keymaps}), abbrev | |
1039 | table (@pxref{Abbrev Tables}), syntax table (@pxref{Syntax Tables}), | |
1040 | category table (@pxref{Categories}), and display table (@pxref{Display | |
1041 | Tables}). | |
b8d4c8d0 GM |
1042 | |
1043 | @item downcase_table | |
c773345a CY |
1044 | @itemx upcase_table |
1045 | @itemx case_canon_table | |
1046 | These fields store the conversion tables for converting text to lower | |
1047 | case, upper case, and for canonicalizing text for case-fold search. | |
b8d4c8d0 GM |
1048 | @xref{Case Tables}. |
1049 | ||
b8d4c8d0 GM |
1050 | @item minor_modes |
1051 | An alist of the minor modes of this buffer. | |
1052 | ||
b8d4c8d0 | 1053 | @item pt_marker |
c773345a CY |
1054 | @itemx begv_marker |
1055 | @itemx zv_marker | |
1056 | These fields are only used in an indirect buffer, or in a buffer that | |
1057 | is the base of an indirect buffer. Each holds a marker that records | |
1058 | @code{pt}, @code{begv}, and @code{zv} respectively, for this buffer | |
b8d4c8d0 GM |
1059 | when the buffer is not current. |
1060 | ||
c773345a CY |
1061 | @item mode_line_format |
1062 | @itemx header_line_format | |
1063 | @itemx case_fold_search | |
1064 | @itemx tab_width | |
1065 | @itemx fill_column | |
1066 | @itemx left_margin | |
1067 | @itemx auto_fill_function | |
c773345a CY |
1068 | @itemx truncate_lines |
1069 | @itemx word_wrap | |
1070 | @itemx ctl_arrow | |
1071 | @itemx selective_display | |
1072 | @itemx selective_display_ellipses | |
1073 | @itemx overwrite_mode | |
1074 | @itemx abbrev_mode | |
1075 | @itemx display_table | |
1076 | @itemx mark_active | |
1077 | @itemx enable_multibyte_characters | |
1078 | @itemx buffer_file_coding_system | |
1079 | @itemx auto_save_file_format | |
1080 | @itemx cache_long_line_scans | |
1081 | @itemx point_before_scroll | |
1082 | @itemx left_fringe_width | |
1083 | @itemx right_fringe_width | |
1084 | @itemx fringes_outside_margins | |
1085 | @itemx scroll_bar_width | |
1086 | @itemx indicate_empty_lines | |
1087 | @itemx indicate_buffer_boundaries | |
1088 | @itemx fringe_indicator_alist | |
1089 | @itemx fringe_cursor_alist | |
1090 | @itemx scroll_up_aggressively | |
1091 | @itemx scroll_down_aggressively | |
1092 | @itemx cursor_type | |
1093 | @itemx cursor_in_non_selected_windows | |
1094 | These fields store the values of Lisp variables that are automatically | |
1095 | buffer-local (@pxref{Buffer-Local Variables}), whose corresponding | |
1096 | variable names have underscores replaced with dashes. For instance, | |
1097 | @code{mode_line_format} stores the value of @code{mode-line-format}. | |
1098 | @xref{Standard Buffer-Local Variables}. | |
b8d4c8d0 GM |
1099 | |
1100 | @item last_selected_window | |
1101 | This is the last window that was selected with this buffer in it, or @code{nil} | |
1102 | if that window no longer displays this buffer. | |
b8d4c8d0 GM |
1103 | @end table |
1104 | ||
1105 | @node Window Internals | |
1106 | @appendixsubsec Window Internals | |
1107 | @cindex internals, of window | |
1108 | @cindex window internals | |
1109 | ||
1110 | Windows have the following accessible fields: | |
1111 | ||
1112 | @table @code | |
1113 | @item frame | |
1114 | The frame that this window is on. | |
1115 | ||
1116 | @item mini_p | |
1117 | Non-@code{nil} if this window is a minibuffer window. | |
1118 | ||
1119 | @item parent | |
1120 | Internally, Emacs arranges windows in a tree; each group of siblings has | |
1121 | a parent window whose area includes all the siblings. This field points | |
1122 | to a window's parent. | |
1123 | ||
1124 | Parent windows do not display buffers, and play little role in display | |
1125 | except to shape their child windows. Emacs Lisp programs usually have | |
1126 | no access to the parent windows; they operate on the windows at the | |
1127 | leaves of the tree, which actually display buffers. | |
1128 | ||
b8d4c8d0 | 1129 | @item hchild |
ee2d5b5e CY |
1130 | @itemx vchild |
1131 | These fields contain the window's leftmost child and its topmost child | |
1132 | respectively. @code{hchild} is used if the window is subdivided | |
1133 | horizontally by child windows, and @code{vchild} if it is subdivided | |
1134 | vertically. | |
b8d4c8d0 GM |
1135 | |
1136 | @item next | |
ee2d5b5e CY |
1137 | @itemx prev |
1138 | The next sibling and previous sibling of this window. @code{next} is | |
1139 | @code{nil} if the window is the rightmost or bottommost in its group; | |
1140 | @code{prev} is @code{nil} if it is the leftmost or topmost in its | |
1141 | group. | |
1142 | ||
1143 | @item left_col | |
1144 | The left-hand edge of the window, measured in columns, relative to the | |
1145 | leftmost column in the frame (column 0). | |
1146 | ||
1147 | @item top_line | |
1148 | The top edge of the window, measured in lines, relative to the topmost | |
1149 | line in the frame (line 0). | |
1150 | ||
1151 | @item total_cols | |
1152 | @itemx total_lines | |
1153 | The width and height of the window, measured in columns and lines | |
1154 | respectively. The width includes the scroll bar and fringes, and/or | |
1155 | the separator line on the right of the window (if any). | |
b8d4c8d0 GM |
1156 | |
1157 | @item buffer | |
ee2d5b5e | 1158 | The buffer that the window is displaying. |
b8d4c8d0 GM |
1159 | |
1160 | @item start | |
ee2d5b5e CY |
1161 | A marker pointing to the position in the buffer that is the first |
1162 | character displayed in the window. | |
b8d4c8d0 GM |
1163 | |
1164 | @item pointm | |
1165 | @cindex window point internals | |
1166 | This is the value of point in the current buffer when this window is | |
1167 | selected; when it is not selected, it retains its previous value. | |
1168 | ||
1169 | @item force_start | |
1170 | If this flag is non-@code{nil}, it says that the window has been | |
1171 | scrolled explicitly by the Lisp program. This affects what the next | |
1172 | redisplay does if point is off the screen: instead of scrolling the | |
1173 | window to show the text around point, it moves point to a location that | |
1174 | is on the screen. | |
1175 | ||
1176 | @item frozen_window_start_p | |
1177 | This field is set temporarily to 1 to indicate to redisplay that | |
1178 | @code{start} of this window should not be changed, even if point | |
1179 | gets invisible. | |
1180 | ||
1181 | @item start_at_line_beg | |
1182 | Non-@code{nil} means current value of @code{start} was the beginning of a line | |
1183 | when it was chosen. | |
1184 | ||
b8d4c8d0 GM |
1185 | @item use_time |
1186 | This is the last time that the window was selected. The function | |
1187 | @code{get-lru-window} uses this field. | |
1188 | ||
1189 | @item sequence_number | |
1190 | A unique number assigned to this window when it was created. | |
1191 | ||
1192 | @item last_modified | |
1193 | The @code{modiff} field of the window's buffer, as of the last time | |
1194 | a redisplay completed in this window. | |
1195 | ||
1196 | @item last_overlay_modified | |
1197 | The @code{overlay_modiff} field of the window's buffer, as of the last | |
1198 | time a redisplay completed in this window. | |
1199 | ||
1200 | @item last_point | |
1201 | The buffer's value of point, as of the last time a redisplay completed | |
1202 | in this window. | |
1203 | ||
1204 | @item last_had_star | |
1205 | A non-@code{nil} value means the window's buffer was ``modified'' when the | |
1206 | window was last updated. | |
1207 | ||
1208 | @item vertical_scroll_bar | |
1209 | This window's vertical scroll bar. | |
1210 | ||
1211 | @item left_margin_width | |
ee2d5b5e CY |
1212 | @itemx right_margin_width |
1213 | The widths of the left and right margins in this window. A value of | |
1214 | @code{nil} means to use the buffer's value of @code{left-margin-width} | |
1215 | or @code{right-margin-width}. | |
b8d4c8d0 GM |
1216 | |
1217 | @item window_end_pos | |
1218 | This is computed as @code{z} minus the buffer position of the last glyph | |
1219 | in the current matrix of the window. The value is only valid if | |
1220 | @code{window_end_valid} is not @code{nil}. | |
1221 | ||
1222 | @item window_end_bytepos | |
1223 | The byte position corresponding to @code{window_end_pos}. | |
1224 | ||
1225 | @item window_end_vpos | |
1226 | The window-relative vertical position of the line containing | |
1227 | @code{window_end_pos}. | |
1228 | ||
1229 | @item window_end_valid | |
1230 | This field is set to a non-@code{nil} value if @code{window_end_pos} is truly | |
1231 | valid. This is @code{nil} if nontrivial redisplay is preempted since in that | |
1232 | case the display that @code{window_end_pos} was computed for did not get | |
1233 | onto the screen. | |
1234 | ||
b8d4c8d0 GM |
1235 | @item cursor |
1236 | A structure describing where the cursor is in this window. | |
1237 | ||
1238 | @item last_cursor | |
1239 | The value of @code{cursor} as of the last redisplay that finished. | |
1240 | ||
1241 | @item phys_cursor | |
1242 | A structure describing where the cursor of this window physically is. | |
1243 | ||
1244 | @item phys_cursor_type | |
1245 | The type of cursor that was last displayed on this window. | |
1246 | ||
1247 | @item phys_cursor_on_p | |
1248 | This field is non-zero if the cursor is physically on. | |
1249 | ||
1250 | @item cursor_off_p | |
1251 | Non-zero means the cursor in this window is logically on. | |
1252 | ||
1253 | @item last_cursor_off_p | |
1254 | This field contains the value of @code{cursor_off_p} as of the time of | |
1255 | the last redisplay. | |
1256 | ||
1257 | @item must_be_updated_p | |
1258 | This is set to 1 during redisplay when this window must be updated. | |
1259 | ||
1260 | @item hscroll | |
1261 | This is the number of columns that the display in the window is scrolled | |
1262 | horizontally to the left. Normally, this is 0. | |
1263 | ||
1264 | @item vscroll | |
1265 | Vertical scroll amount, in pixels. Normally, this is 0. | |
1266 | ||
1267 | @item dedicated | |
1268 | Non-@code{nil} if this window is dedicated to its buffer. | |
1269 | ||
1270 | @item display_table | |
1271 | The window's display table, or @code{nil} if none is specified for it. | |
1272 | ||
1273 | @item update_mode_line | |
1274 | Non-@code{nil} means this window's mode line needs to be updated. | |
1275 | ||
1276 | @item base_line_number | |
1277 | The line number of a certain position in the buffer, or @code{nil}. | |
1278 | This is used for displaying the line number of point in the mode line. | |
1279 | ||
1280 | @item base_line_pos | |
1281 | The position in the buffer for which the line number is known, or | |
1282 | @code{nil} meaning none is known. | |
1283 | ||
1284 | @item region_showing | |
1285 | If the region (or part of it) is highlighted in this window, this field | |
1286 | holds the mark position that made one end of that region. Otherwise, | |
1287 | this field is @code{nil}. | |
1288 | ||
1289 | @item column_number_displayed | |
1290 | The column number currently displayed in this window's mode line, or @code{nil} | |
1291 | if column numbers are not being displayed. | |
1292 | ||
1293 | @item current_matrix | |
1294 | A glyph matrix describing the current display of this window. | |
1295 | ||
1296 | @item desired_matrix | |
1297 | A glyph matrix describing the desired display of this window. | |
1298 | @end table | |
1299 | ||
1300 | @node Process Internals | |
1301 | @appendixsubsec Process Internals | |
1302 | @cindex internals, of process | |
1303 | @cindex process internals | |
1304 | ||
1305 | The fields of a process are: | |
1306 | ||
1307 | @table @code | |
1308 | @item name | |
1309 | A string, the name of the process. | |
1310 | ||
1311 | @item command | |
1312 | A list containing the command arguments that were used to start this | |
c73e02fa GM |
1313 | process. For a network or serial process, it is @code{nil} if the |
1314 | process is running or @code{t} if the process is stopped. | |
b8d4c8d0 GM |
1315 | |
1316 | @item filter | |
1317 | A function used to accept output from the process instead of a buffer, | |
1318 | or @code{nil}. | |
1319 | ||
1320 | @item sentinel | |
1321 | A function called whenever the process receives a signal, or @code{nil}. | |
1322 | ||
1323 | @item buffer | |
1324 | The associated buffer of the process. | |
1325 | ||
1326 | @item pid | |
1327 | An integer, the operating system's process @acronym{ID}. | |
1328 | ||
1329 | @item childp | |
1330 | A flag, non-@code{nil} if this is really a child process. | |
c73e02fa | 1331 | It is @code{nil} for a network or serial connection. |
b8d4c8d0 GM |
1332 | |
1333 | @item mark | |
1334 | A marker indicating the position of the end of the last output from this | |
1335 | process inserted into the buffer. This is often but not always the end | |
1336 | of the buffer. | |
1337 | ||
1338 | @item kill_without_query | |
ee2d5b5e CY |
1339 | If this is non-zero, killing Emacs while this process is still running |
1340 | does not ask for confirmation about killing the process. | |
b8d4c8d0 GM |
1341 | |
1342 | @item raw_status_low | |
1343 | @itemx raw_status_high | |
1344 | These two fields record 16 bits each of the process status returned by | |
1345 | the @code{wait} system call. | |
1346 | ||
1347 | @item status | |
1348 | The process status, as @code{process-status} should return it. | |
1349 | ||
1350 | @item tick | |
1351 | @itemx update_tick | |
1352 | If these two fields are not equal, a change in the status of the process | |
1353 | needs to be reported, either by running the sentinel or by inserting a | |
1354 | message in the process buffer. | |
1355 | ||
1356 | @item pty_flag | |
1357 | Non-@code{nil} if communication with the subprocess uses a @acronym{PTY}; | |
1358 | @code{nil} if it uses a pipe. | |
1359 | ||
1360 | @item infd | |
1361 | The file descriptor for input from the process. | |
1362 | ||
1363 | @item outfd | |
1364 | The file descriptor for output to the process. | |
1365 | ||
1366 | @item subtty | |
1367 | The file descriptor for the terminal that the subprocess is using. (On | |
1368 | some systems, there is no need to record this, so the value is | |
1369 | @code{nil}.) | |
1370 | ||
1371 | @item tty_name | |
1372 | The name of the terminal that the subprocess is using, | |
1373 | or @code{nil} if it is using pipes. | |
1374 | ||
1375 | @item decode_coding_system | |
1376 | Coding-system for decoding the input from this process. | |
1377 | ||
1378 | @item decoding_buf | |
1379 | A working buffer for decoding. | |
1380 | ||
1381 | @item decoding_carryover | |
1382 | Size of carryover in decoding. | |
1383 | ||
1384 | @item encode_coding_system | |
1385 | Coding-system for encoding the output to this process. | |
1386 | ||
1387 | @item encoding_buf | |
1388 | A working buffer for encoding. | |
1389 | ||
1390 | @item encoding_carryover | |
1391 | Size of carryover in encoding. | |
1392 | ||
1393 | @item inherit_coding_system_flag | |
1394 | Flag to set @code{coding-system} of the process buffer from the | |
1395 | coding system used to decode process output. | |
c73e02fa GM |
1396 | |
1397 | @item type | |
1398 | Symbol indicating the type of process: @code{real}, @code{network}, | |
1399 | @code{serial} | |
1400 | ||
b8d4c8d0 | 1401 | @end table |