Commit | Line | Data |
---|---|---|
b8d4c8d0 GM |
1 | @c -*-texinfo-*- |
2 | @c This is part of the GNU Emacs Lisp Reference Manual. | |
ba318903 | 3 | @c Copyright (C) 1990-1993, 1998-1999, 2001-2014 Free Software |
ab422c4d | 4 | @c Foundation, Inc. |
b8d4c8d0 | 5 | @c See the file elisp.texi for copying conditions. |
ecc6530d | 6 | @node GNU Emacs Internals |
b8d4c8d0 GM |
7 | @appendix GNU Emacs Internals |
8 | ||
9 | This chapter describes how the runnable Emacs executable is dumped with | |
10 | the preloaded Lisp libraries in it, how storage is allocated, and some | |
11 | internal aspects of GNU Emacs that may be of interest to C programmers. | |
12 | ||
13 | @menu | |
14 | * Building Emacs:: How the dumped Emacs is made. | |
333f9019 | 15 | * Pure Storage:: Kludge to make preloaded Lisp functions shareable. |
b8d4c8d0 GM |
16 | * Garbage Collection:: Reclaiming space for Lisp objects no longer used. |
17 | * Memory Usage:: Info about total size of Lisp objects made so far. | |
76377e46 | 18 | * C Dialect:: What C variant Emacs is written in. |
b8d4c8d0 GM |
19 | * Writing Emacs Primitives:: Writing C code for Emacs. |
20 | * Object Internals:: Data formats of buffers, windows, processes. | |
d92d9c95 | 21 | * C Integer Types:: How C integer types are used inside Emacs. |
b8d4c8d0 GM |
22 | @end menu |
23 | ||
24 | @node Building Emacs | |
520f2425 | 25 | @section Building Emacs |
b8d4c8d0 GM |
26 | @cindex building Emacs |
27 | @pindex temacs | |
28 | ||
29 | This section explains the steps involved in building the Emacs | |
30 | executable. You don't have to know this material to build and install | |
31 | Emacs, since the makefiles do all these things automatically. This | |
d15aac68 | 32 | information is pertinent to Emacs developers. |
b8d4c8d0 GM |
33 | |
34 | Compilation of the C source files in the @file{src} directory | |
35 | produces an executable file called @file{temacs}, also called a | |
d15aac68 CY |
36 | @dfn{bare impure Emacs}. It contains the Emacs Lisp interpreter and |
37 | I/O routines, but not the editing commands. | |
b8d4c8d0 GM |
38 | |
39 | @cindex @file{loadup.el} | |
d15aac68 CY |
40 | The command @w{@command{temacs -l loadup}} would run @file{temacs} |
41 | and direct it to load @file{loadup.el}. The @code{loadup} library | |
42 | loads additional Lisp libraries, which set up the normal Emacs editing | |
43 | environment. After this step, the Emacs executable is no longer | |
44 | @dfn{bare}. | |
b8d4c8d0 GM |
45 | |
46 | @cindex dumping Emacs | |
d15aac68 CY |
47 | Because it takes some time to load the standard Lisp files, the |
48 | @file{temacs} executable usually isn't run directly by users. | |
49 | Instead, as one of the last steps of building Emacs, the command | |
50 | @samp{temacs -batch -l loadup dump} is run. The special @samp{dump} | |
51 | argument causes @command{temacs} to dump out an executable program, | |
52 | called @file{emacs}, which has all the standard Lisp files preloaded. | |
53 | (The @samp{-batch} argument prevents @file{temacs} from trying to | |
54 | initialize any of its data on the terminal, so that the tables of | |
55 | terminal information are empty in the dumped Emacs.) | |
56 | ||
57 | @cindex preloaded Lisp files | |
b578c9cc | 58 | @vindex preloaded-file-list |
d15aac68 CY |
59 | The dumped @file{emacs} executable (also called a @dfn{pure} Emacs) |
60 | is the one which is installed. The variable | |
61 | @code{preloaded-file-list} stores a list of the Lisp files preloaded | |
62 | into the dumped Emacs. If you port Emacs to a new operating system, | |
63 | and are not able to implement dumping, then Emacs must load | |
64 | @file{loadup.el} each time it starts. | |
b8d4c8d0 GM |
65 | |
66 | @cindex @file{site-load.el} | |
b8d4c8d0 | 67 | You can specify additional files to preload by writing a library named |
520f2425 GM |
68 | @file{site-load.el} that loads them. You may need to rebuild Emacs |
69 | with an added definition | |
b8d4c8d0 GM |
70 | |
71 | @example | |
72 | #define SITELOAD_PURESIZE_EXTRA @var{n} | |
73 | @end example | |
74 | ||
75 | @noindent | |
520f2425 GM |
76 | to make @var{n} added bytes of pure space to hold the additional files; |
77 | see @file{src/puresize.h}. | |
b8d4c8d0 GM |
78 | (Try adding increments of 20000 until it is big enough.) However, the |
79 | advantage of preloading additional files decreases as machines get | |
80 | faster. On modern machines, it is usually not advisable. | |
81 | ||
82 | After @file{loadup.el} reads @file{site-load.el}, it finds the | |
83 | documentation strings for primitive and preloaded functions (and | |
84 | variables) in the file @file{etc/DOC} where they are stored, by | |
85 | calling @code{Snarf-documentation} (@pxref{Definition of | |
86 | Snarf-documentation,, Accessing Documentation}). | |
87 | ||
88 | @cindex @file{site-init.el} | |
89 | @cindex preloading additional functions and variables | |
90 | You can specify other Lisp expressions to execute just before dumping | |
91 | by putting them in a library named @file{site-init.el}. This file is | |
92 | executed after the documentation strings are found. | |
93 | ||
94 | If you want to preload function or variable definitions, there are | |
95 | three ways you can do this and make their documentation strings | |
96 | accessible when you subsequently run Emacs: | |
97 | ||
98 | @itemize @bullet | |
99 | @item | |
100 | Arrange to scan these files when producing the @file{etc/DOC} file, | |
101 | and load them with @file{site-load.el}. | |
102 | ||
103 | @item | |
104 | Load the files with @file{site-init.el}, then copy the files into the | |
105 | installation directory for Lisp files when you install Emacs. | |
106 | ||
107 | @item | |
5906db45 GM |
108 | Specify a @code{nil} value for @code{byte-compile-dynamic-docstrings} |
109 | as a local variable in each of these files, and load them with either | |
110 | @file{site-load.el} or @file{site-init.el}. (This method has the | |
111 | drawback that the documentation strings take up space in Emacs all the | |
112 | time.) | |
b8d4c8d0 GM |
113 | @end itemize |
114 | ||
f982b371 EZ |
115 | @cindex change @code{load-path} at configure time |
116 | @cindex @option{--enable-locallisppath} option to @command{configure} | |
b8d4c8d0 GM |
117 | It is not advisable to put anything in @file{site-load.el} or |
118 | @file{site-init.el} that would alter any of the features that users | |
119 | expect in an ordinary unmodified Emacs. If you feel you must override | |
120 | normal features for your site, do it with @file{default.el}, so that | |
121 | users can override your changes if they wish. @xref{Startup Summary}. | |
06a4f110 GM |
122 | Note that if either @file{site-load.el} or @file{site-init.el} changes |
123 | @code{load-path}, the changes will be lost after dumping. | |
124 | @xref{Library Search}. To make a permanent change to | |
125 | @code{load-path}, use the @option{--enable-locallisppath} option | |
126 | of @command{configure}. | |
b8d4c8d0 | 127 | |
520f2425 GM |
128 | In a package that can be preloaded, it is sometimes necessary (or |
129 | useful) to delay certain evaluations until Emacs subsequently starts | |
130 | up. The vast majority of such cases relate to the values of | |
131 | customizable variables. For example, @code{tutorial-directory} is a | |
132 | variable defined in @file{startup.el}, which is preloaded. The default | |
133 | value is set based on @code{data-directory}. The variable needs to | |
134 | access the value of @code{data-directory} when Emacs starts, not when | |
135 | it is dumped, because the Emacs executable has probably been installed | |
136 | in a different location since it was dumped. | |
137 | ||
138 | @defun custom-initialize-delay symbol value | |
139 | This function delays the initialization of @var{symbol} to the next | |
140 | Emacs start. You normally use this function by specifying it as the | |
141 | @code{:initialize} property of a customizable variable. (The argument | |
f003f294 | 142 | @var{value} is unused, and is provided only for compatibility with the |
520f2425 GM |
143 | form Custom expects.) |
144 | @end defun | |
b8d4c8d0 | 145 | |
520f2425 GM |
146 | In the unlikely event that you need a more general functionality than |
147 | @code{custom-initialize-delay} provides, you can use | |
148 | @code{before-init-hook} (@pxref{Startup Summary}). | |
b8d4c8d0 GM |
149 | |
150 | @defun dump-emacs to-file from-file | |
151 | @cindex unexec | |
152 | This function dumps the current state of Emacs into an executable file | |
153 | @var{to-file}. It takes symbols from @var{from-file} (this is normally | |
154 | the executable file @file{temacs}). | |
155 | ||
156 | If you want to use this function in an Emacs that was already dumped, | |
157 | you must run Emacs with @samp{-batch}. | |
158 | @end defun | |
159 | ||
160 | @node Pure Storage | |
520f2425 | 161 | @section Pure Storage |
b8d4c8d0 GM |
162 | @cindex pure storage |
163 | ||
164 | Emacs Lisp uses two kinds of storage for user-created Lisp objects: | |
165 | @dfn{normal storage} and @dfn{pure storage}. Normal storage is where | |
999dd333 GM |
166 | all the new data created during an Emacs session are kept |
167 | (@pxref{Garbage Collection}). Pure storage is used for certain data | |
168 | in the preloaded standard Lisp files---data that should never change | |
169 | during actual use of Emacs. | |
b8d4c8d0 | 170 | |
d15aac68 | 171 | Pure storage is allocated only while @command{temacs} is loading the |
b8d4c8d0 GM |
172 | standard preloaded Lisp libraries. In the file @file{emacs}, it is |
173 | marked as read-only (on operating systems that permit this), so that | |
174 | the memory space can be shared by all the Emacs jobs running on the | |
175 | machine at once. Pure storage is not expandable; a fixed amount is | |
176 | allocated when Emacs is compiled, and if that is not sufficient for | |
177 | the preloaded libraries, @file{temacs} allocates dynamic memory for | |
999dd333 GM |
178 | the part that didn't fit. The resulting image will work, but garbage |
179 | collection (@pxref{Garbage Collection}) is disabled in this situation, | |
180 | causing a memory leak. Such an overflow normally won't happen unless | |
181 | you try to preload additional libraries or add features to the | |
182 | standard ones. Emacs will display a warning about the overflow when | |
183 | it starts. If this happens, you should increase the compilation | |
184 | parameter @code{SYSTEM_PURESIZE_EXTRA} in the file | |
185 | @file{src/puresize.h} and rebuild Emacs. | |
b8d4c8d0 GM |
186 | |
187 | @defun purecopy object | |
188 | This function makes a copy in pure storage of @var{object}, and returns | |
189 | it. It copies a string by simply making a new string with the same | |
190 | characters, but without text properties, in pure storage. It | |
191 | recursively copies the contents of vectors and cons cells. It does | |
192 | not make copies of other objects such as symbols, but just returns | |
193 | them unchanged. It signals an error if asked to copy markers. | |
194 | ||
195 | This function is a no-op except while Emacs is being built and dumped; | |
999dd333 | 196 | it is usually called only in preloaded Lisp files. |
b8d4c8d0 GM |
197 | @end defun |
198 | ||
199 | @defvar pure-bytes-used | |
200 | The value of this variable is the number of bytes of pure storage | |
201 | allocated so far. Typically, in a dumped Emacs, this number is very | |
202 | close to the total amount of pure storage available---if it were not, | |
203 | we would preallocate less. | |
204 | @end defvar | |
205 | ||
206 | @defvar purify-flag | |
207 | This variable determines whether @code{defun} should make a copy of the | |
208 | function definition in pure storage. If it is non-@code{nil}, then the | |
209 | function definition is copied into pure storage. | |
210 | ||
211 | This flag is @code{t} while loading all of the basic functions for | |
333f9019 | 212 | building Emacs initially (allowing those functions to be shareable and |
b8d4c8d0 GM |
213 | non-collectible). Dumping Emacs as an executable always writes |
214 | @code{nil} in this variable, regardless of the value it actually has | |
215 | before and after dumping. | |
216 | ||
217 | You should not change this flag in a running Emacs. | |
218 | @end defvar | |
219 | ||
220 | @node Garbage Collection | |
520f2425 | 221 | @section Garbage Collection |
b8d4c8d0 GM |
222 | |
223 | @cindex memory allocation | |
d15aac68 CY |
224 | When a program creates a list or the user defines a new function |
225 | (such as by loading a library), that data is placed in normal storage. | |
226 | If normal storage runs low, then Emacs asks the operating system to | |
227 | allocate more memory. Different types of Lisp objects, such as | |
f3372c87 DA |
228 | symbols, cons cells, small vectors, markers, etc., are segregated in |
229 | distinct blocks in memory. (Large vectors, long strings, buffers and | |
230 | certain other editing types, which are fairly large, are allocated in | |
231 | individual blocks, one per object; small strings are packed into blocks | |
232 | of 8k bytes, and small vectors are packed into blocks of 4k bytes). | |
233 | ||
234 | @cindex vector-like objects, storage | |
235 | @cindex storage of vector-like Lisp objects | |
236 | Beyond the basic vector, a lot of objects like window, buffer, and | |
237 | frame are managed as if they were vectors. The corresponding C data | |
238 | structures include the @code{struct vectorlike_header} field whose | |
74934dcc DA |
239 | @code{size} member contains the subtype enumerated by @code{enum pvec_type} |
240 | and an information about how many @code{Lisp_Object} fields this structure | |
241 | contains and what the size of the rest data is. This information is | |
242 | needed to calculate the memory footprint of an object, and used | |
243 | by the vector allocation code while iterating over the vector blocks. | |
b8d4c8d0 | 244 | |
d15aac68 CY |
245 | @cindex garbage collection |
246 | It is quite common to use some storage for a while, then release it | |
247 | by (for example) killing a buffer or deleting the last pointer to an | |
248 | object. Emacs provides a @dfn{garbage collector} to reclaim this | |
249 | abandoned storage. The garbage collector operates by finding and | |
250 | marking all Lisp objects that are still accessible to Lisp programs. | |
251 | To begin with, it assumes all the symbols, their values and associated | |
252 | function definitions, and any data presently on the stack, are | |
253 | accessible. Any objects that can be reached indirectly through other | |
254 | accessible objects are also accessible. | |
b8d4c8d0 GM |
255 | |
256 | When marking is finished, all objects still unmarked are garbage. No | |
257 | matter what the Lisp program or the user does, it is impossible to refer | |
258 | to them, since there is no longer a way to reach them. Their space | |
259 | might as well be reused, since no one will miss them. The second | |
260 | (``sweep'') phase of the garbage collector arranges to reuse them. | |
261 | ||
262 | @c ??? Maybe add something describing weak hash tables here? | |
263 | ||
264 | @cindex free list | |
265 | The sweep phase puts unused cons cells onto a @dfn{free list} | |
266 | for future allocation; likewise for symbols and markers. It compacts | |
267 | the accessible strings so they occupy fewer 8k blocks; then it frees the | |
f3372c87 DA |
268 | other 8k blocks. Unreachable vectors from vector blocks are coalesced |
269 | to create largest possible free areas; if a free area spans a complete | |
270 | 4k block, that block is freed. Otherwise, the free area is recorded | |
271 | in a free list array, where each entry corresponds to a free list | |
272 | of areas of the same size. Large vectors, buffers, and other large | |
273 | objects are allocated and freed individually. | |
b8d4c8d0 GM |
274 | |
275 | @cindex CL note---allocate more storage | |
276 | @quotation | |
277 | @b{Common Lisp note:} Unlike other Lisps, GNU Emacs Lisp does not | |
278 | call the garbage collector when the free list is empty. Instead, it | |
279 | simply requests the operating system to allocate more storage, and | |
280 | processing continues until @code{gc-cons-threshold} bytes have been | |
281 | used. | |
282 | ||
283 | This means that you can make sure that the garbage collector will not | |
284 | run during a certain portion of a Lisp program by calling the garbage | |
285 | collector explicitly just before it (provided that portion of the | |
286 | program does not use so much space as to force a second garbage | |
287 | collection). | |
288 | @end quotation | |
289 | ||
290 | @deffn Command garbage-collect | |
291 | This command runs a garbage collection, and returns information on | |
292 | the amount of space in use. (Garbage collection can also occur | |
293 | spontaneously if you use more than @code{gc-cons-threshold} bytes of | |
294 | Lisp data since the previous garbage collection.) | |
295 | ||
74934dcc DA |
296 | @code{garbage-collect} returns a list with information on amount of space in |
297 | use, where each entry has the form @samp{(@var{name} @var{size} @var{used})} | |
298 | or @samp{(@var{name} @var{size} @var{used} @var{free})}. In the entry, | |
299 | @var{name} is a symbol describing the kind of objects this entry represents, | |
300 | @var{size} is the number of bytes used by each one, @var{used} is the number | |
301 | of those objects that were found live in the heap, and optional @var{free} is | |
302 | the number of those objects that are not live but that Emacs keeps around for | |
303 | future allocations. So an overall result is: | |
b8d4c8d0 GM |
304 | |
305 | @example | |
f24f2e22 | 306 | ((@code{conses} @var{cons-size} @var{used-conses} @var{free-conses}) |
74934dcc DA |
307 | (@code{symbols} @var{symbol-size} @var{used-symbols} @var{free-symbols}) |
308 | (@code{miscs} @var{misc-size} @var{used-miscs} @var{free-miscs}) | |
309 | (@code{strings} @var{string-size} @var{used-strings} @var{free-strings}) | |
310 | (@code{string-bytes} @var{byte-size} @var{used-bytes}) | |
311 | (@code{vectors} @var{vector-size} @var{used-vectors}) | |
312 | (@code{vector-slots} @var{slot-size} @var{used-slots} @var{free-slots}) | |
313 | (@code{floats} @var{float-size} @var{used-floats} @var{free-floats}) | |
314 | (@code{intervals} @var{interval-size} @var{used-intervals} @var{free-intervals}) | |
315 | (@code{buffers} @var{buffer-size} @var{used-buffers}) | |
316 | (@code{heap} @var{unit-size} @var{total-size} @var{free-size})) | |
b8d4c8d0 GM |
317 | @end example |
318 | ||
319 | Here is an example: | |
320 | ||
321 | @example | |
b8d4c8d0 | 322 | (garbage-collect) |
74934dcc DA |
323 | @result{} ((conses 16 49126 8058) (symbols 48 14607 0) |
324 | (miscs 40 34 56) (strings 32 2942 2607) | |
325 | (string-bytes 1 78607) (vectors 16 7247) | |
326 | (vector-slots 8 341609 29474) (floats 8 71 102) | |
327 | (intervals 56 27 26) (buffers 944 8) | |
328 | (heap 1024 11715 2678)) | |
b8d4c8d0 GM |
329 | @end example |
330 | ||
74934dcc DA |
331 | Below is a table explaining each element. Note that last @code{heap} entry |
332 | is optional and present only if an underlying @code{malloc} implementation | |
333 | provides @code{mallinfo} function. | |
b8d4c8d0 GM |
334 | |
335 | @table @var | |
74934dcc | 336 | @item cons-size |
39670ef4 | 337 | Internal size of a cons cell, i.e., @code{sizeof (struct Lisp_Cons)}. |
74934dcc | 338 | |
b8d4c8d0 GM |
339 | @item used-conses |
340 | The number of cons cells in use. | |
341 | ||
342 | @item free-conses | |
74934dcc DA |
343 | The number of cons cells for which space has been obtained from |
344 | the operating system, but that are not currently being used. | |
b8d4c8d0 | 345 | |
74934dcc | 346 | @item symbol-size |
39670ef4 | 347 | Internal size of a symbol, i.e., @code{sizeof (struct Lisp_Symbol)}. |
74934dcc DA |
348 | |
349 | @item used-symbols | |
b8d4c8d0 GM |
350 | The number of symbols in use. |
351 | ||
74934dcc DA |
352 | @item free-symbols |
353 | The number of symbols for which space has been obtained from | |
354 | the operating system, but that are not currently being used. | |
355 | ||
356 | @item misc-size | |
39670ef4 | 357 | Internal size of a miscellaneous entity, i.e., |
74934dcc DA |
358 | @code{sizeof (union Lisp_Misc)}, which is a size of the |
359 | largest type enumerated in @code{enum Lisp_Misc_Type}. | |
b8d4c8d0 GM |
360 | |
361 | @item used-miscs | |
74934dcc DA |
362 | The number of miscellaneous objects in use. These include markers |
363 | and overlays, plus certain objects not visible to users. | |
b8d4c8d0 GM |
364 | |
365 | @item free-miscs | |
366 | The number of miscellaneous objects for which space has been obtained | |
367 | from the operating system, but that are not currently being used. | |
368 | ||
74934dcc | 369 | @item string-size |
39670ef4 | 370 | Internal size of a string header, i.e., @code{sizeof (struct Lisp_String)}. |
74934dcc DA |
371 | |
372 | @item used-strings | |
373 | The number of string headers in use. | |
374 | ||
375 | @item free-strings | |
376 | The number of string headers for which space has been obtained | |
377 | from the operating system, but that are not currently being used. | |
378 | ||
379 | @item byte-size | |
380 | This is used for convenience and equals to @code{sizeof (char)}. | |
381 | ||
382 | @item used-bytes | |
383 | The total size of all string data in bytes. | |
384 | ||
385 | @item vector-size | |
39670ef4 | 386 | Internal size of a vector header, i.e., @code{sizeof (struct Lisp_Vector)}. |
74934dcc DA |
387 | |
388 | @item used-vectors | |
389 | The number of vector headers allocated from the vector blocks. | |
390 | ||
391 | @item slot-size | |
392 | Internal size of a vector slot, always equal to @code{sizeof (Lisp_Object)}. | |
393 | ||
394 | @item used-slots | |
395 | The number of slots in all used vectors. | |
396 | ||
397 | @item free-slots | |
398 | The number of free slots in all vector blocks. | |
b8d4c8d0 | 399 | |
74934dcc | 400 | @item float-size |
39670ef4 | 401 | Internal size of a float object, i.e., @code{sizeof (struct Lisp_Float)}. |
74934dcc | 402 | (Do not confuse it with the native platform @code{float} or @code{double}.) |
b8d4c8d0 GM |
403 | |
404 | @item used-floats | |
b8d4c8d0 GM |
405 | The number of floats in use. |
406 | ||
407 | @item free-floats | |
74934dcc DA |
408 | The number of floats for which space has been obtained from |
409 | the operating system, but that are not currently being used. | |
410 | ||
411 | @item interval-size | |
39670ef4 | 412 | Internal size of an interval object, i.e., @code{sizeof (struct interval)}. |
b8d4c8d0 GM |
413 | |
414 | @item used-intervals | |
74934dcc | 415 | The number of intervals in use. |
b8d4c8d0 GM |
416 | |
417 | @item free-intervals | |
74934dcc DA |
418 | The number of intervals for which space has been obtained from |
419 | the operating system, but that are not currently being used. | |
b8d4c8d0 | 420 | |
74934dcc | 421 | @item buffer-size |
39670ef4 | 422 | Internal size of a buffer, i.e., @code{sizeof (struct buffer)}. |
74934dcc | 423 | (Do not confuse with the value returned by @code{buffer-size} function.) |
b8d4c8d0 | 424 | |
74934dcc DA |
425 | @item used-buffers |
426 | The number of buffer objects in use. This includes killed buffers | |
39670ef4 | 427 | invisible to users, i.e., all buffers in @code{all_buffers} list. |
74934dcc DA |
428 | |
429 | @item unit-size | |
430 | The unit of heap space measurement, always equal to 1024 bytes. | |
431 | ||
432 | @item total-size | |
433 | Total heap size, in @var{unit-size} units. | |
434 | ||
435 | @item free-size | |
436 | Heap space which is not currently used, in @var{unit-size} units. | |
b8d4c8d0 GM |
437 | @end table |
438 | ||
999dd333 | 439 | If there was overflow in pure space (@pxref{Pure Storage}), |
b8d4c8d0 | 440 | @code{garbage-collect} returns @code{nil}, because a real garbage |
9658dc2a | 441 | collection cannot be done. |
b8d4c8d0 GM |
442 | @end deffn |
443 | ||
444 | @defopt garbage-collection-messages | |
445 | If this variable is non-@code{nil}, Emacs displays a message at the | |
446 | beginning and end of garbage collection. The default value is | |
999dd333 | 447 | @code{nil}. |
b8d4c8d0 GM |
448 | @end defopt |
449 | ||
450 | @defvar post-gc-hook | |
451 | This is a normal hook that is run at the end of garbage collection. | |
452 | Garbage collection is inhibited while the hook functions run, so be | |
453 | careful writing them. | |
454 | @end defvar | |
455 | ||
456 | @defopt gc-cons-threshold | |
457 | The value of this variable is the number of bytes of storage that must | |
458 | be allocated for Lisp objects after one garbage collection in order to | |
74934dcc DA |
459 | trigger another garbage collection. You can use the result returned by |
460 | @code{garbage-collect} to get an information about size of the particular | |
461 | object type; space allocated to the contents of buffers does not count. | |
462 | Note that the subsequent garbage collection does not happen immediately | |
463 | when the threshold is exhausted, but only the next time the Lisp interpreter | |
464 | is called. | |
465 | ||
466 | The initial threshold value is @code{GC_DEFAULT_THRESHOLD}, defined in | |
467 | @file{alloc.c}. Since it's defined in @code{word_size} units, the value | |
468 | is 400,000 for the default 32-bit configuration and 800,000 for the 64-bit | |
469 | one. If you specify a larger value, garbage collection will happen less | |
470 | often. This reduces the amount of time spent garbage collecting, but | |
471 | increases total memory use. You may want to do this when running a program | |
472 | that creates lots of Lisp data. | |
473 | ||
474 | You can make collections more frequent by specifying a smaller value, down | |
475 | to 1/10th of @code{GC_DEFAULT_THRESHOLD}. A value less than this minimum | |
476 | will remain in effect only until the subsequent garbage collection, at which | |
477 | time @code{garbage-collect} will set the threshold back to the minimum. | |
b8d4c8d0 GM |
478 | @end defopt |
479 | ||
480 | @defopt gc-cons-percentage | |
481 | The value of this variable specifies the amount of consing before a | |
482 | garbage collection occurs, as a fraction of the current heap size. | |
483 | This criterion and @code{gc-cons-threshold} apply in parallel, and | |
484 | garbage collection occurs only when both criteria are satisfied. | |
485 | ||
486 | As the heap size increases, the time to perform a garbage collection | |
487 | increases. Thus, it can be desirable to do them less frequently in | |
488 | proportion. | |
489 | @end defopt | |
490 | ||
491 | The value returned by @code{garbage-collect} describes the amount of | |
492 | memory used by Lisp data, broken down by data type. By contrast, the | |
493 | function @code{memory-limit} provides information on the total amount of | |
494 | memory Emacs is currently using. | |
495 | ||
b8d4c8d0 GM |
496 | @defun memory-limit |
497 | This function returns the address of the last byte Emacs has allocated, | |
498 | divided by 1024. We divide the value by 1024 to make sure it fits in a | |
499 | Lisp integer. | |
500 | ||
501 | You can use this to get a general idea of how your actions affect the | |
502 | memory usage. | |
503 | @end defun | |
504 | ||
505 | @defvar memory-full | |
d15aac68 | 506 | This variable is @code{t} if Emacs is nearly out of memory for Lisp |
b8d4c8d0 GM |
507 | objects, and @code{nil} otherwise. |
508 | @end defvar | |
509 | ||
510 | @defun memory-use-counts | |
511 | This returns a list of numbers that count the number of objects | |
512 | created in this Emacs session. Each of these counters increments for | |
513 | a certain kind of object. See the documentation string for details. | |
514 | @end defun | |
515 | ||
516 | @defvar gcs-done | |
517 | This variable contains the total number of garbage collections | |
518 | done so far in this Emacs session. | |
519 | @end defvar | |
520 | ||
521 | @defvar gc-elapsed | |
522 | This variable contains the total number of seconds of elapsed time | |
09b73f08 PE |
523 | during garbage collection so far in this Emacs session, as a |
524 | floating-point number. | |
b8d4c8d0 GM |
525 | @end defvar |
526 | ||
527 | @node Memory Usage | |
528 | @section Memory Usage | |
529 | @cindex memory usage | |
530 | ||
531 | These functions and variables give information about the total amount | |
532 | of memory allocation that Emacs has done, broken down by data type. | |
533 | Note the difference between these and the values returned by | |
01a6dcc8 | 534 | @code{garbage-collect}; those count objects that currently exist, but |
b8d4c8d0 GM |
535 | these count the number or size of all allocations, including those for |
536 | objects that have since been freed. | |
537 | ||
538 | @defvar cons-cells-consed | |
539 | The total number of cons cells that have been allocated so far | |
540 | in this Emacs session. | |
541 | @end defvar | |
542 | ||
543 | @defvar floats-consed | |
544 | The total number of floats that have been allocated so far | |
545 | in this Emacs session. | |
546 | @end defvar | |
547 | ||
548 | @defvar vector-cells-consed | |
549 | The total number of vector cells that have been allocated so far | |
550 | in this Emacs session. | |
551 | @end defvar | |
552 | ||
553 | @defvar symbols-consed | |
554 | The total number of symbols that have been allocated so far | |
555 | in this Emacs session. | |
556 | @end defvar | |
557 | ||
558 | @defvar string-chars-consed | |
559 | The total number of string characters that have been allocated so far | |
9658dc2a | 560 | in this session. |
b8d4c8d0 GM |
561 | @end defvar |
562 | ||
563 | @defvar misc-objects-consed | |
564 | The total number of miscellaneous objects that have been allocated so | |
9658dc2a | 565 | far in this session. These include markers and overlays, plus |
b8d4c8d0 GM |
566 | certain objects not visible to users. |
567 | @end defvar | |
568 | ||
569 | @defvar intervals-consed | |
570 | The total number of intervals that have been allocated so far | |
571 | in this Emacs session. | |
572 | @end defvar | |
573 | ||
574 | @defvar strings-consed | |
575 | The total number of strings that have been allocated so far in this | |
576 | Emacs session. | |
577 | @end defvar | |
578 | ||
76377e46 PE |
579 | @node C Dialect |
580 | @section C Dialect | |
581 | @cindex C programming language | |
582 | ||
8208d2bf PE |
583 | The C part of Emacs is portable to C99 or later: C11-specific features such |
584 | as @samp{<stdalign.h>} and @samp{_Noreturn} are not used without a check, | |
76377e46 | 585 | typically at configuration time, and the Emacs build procedure |
8208d2bf PE |
586 | provides a substitute implementation if necessary. Some C11 features, |
587 | such as anonymous structures and unions, are too difficult to emulate, | |
588 | so they are avoided entirely. | |
76377e46 | 589 | |
8208d2bf | 590 | At some point in the future the base C dialect will no doubt change to C11. |
76377e46 | 591 | |
b8d4c8d0 | 592 | @node Writing Emacs Primitives |
520f2425 | 593 | @section Writing Emacs Primitives |
b8d4c8d0 GM |
594 | @cindex primitive function internals |
595 | @cindex writing Emacs primitives | |
596 | ||
1df7defd | 597 | Lisp primitives are Lisp functions implemented in C@. The details of |
b8d4c8d0 GM |
598 | interfacing the C function so that Lisp can call it are handled by a few |
599 | C macros. The only way to really understand how to write new C code is | |
600 | to read the source, but we can explain some things here. | |
601 | ||
602 | An example of a special form is the definition of @code{or}, from | |
603 | @file{eval.c}. (An ordinary function would have the same general | |
604 | appearance.) | |
605 | ||
606 | @cindex garbage collection protection | |
607 | @smallexample | |
608 | @group | |
609 | DEFUN ("or", For, Sor, 0, UNEVALLED, 0, | |
d15aac68 CY |
610 | doc: /* Eval args until one of them yields non-nil, then return |
611 | that value. | |
612 | The remaining args are not evalled at all. | |
b8d4c8d0 GM |
613 | If all args return nil, return nil. |
614 | @end group | |
615 | @group | |
616 | usage: (or CONDITIONS ...) */) | |
b88746ba | 617 | (Lisp_Object args) |
b8d4c8d0 GM |
618 | @{ |
619 | register Lisp_Object val = Qnil; | |
620 | struct gcpro gcpro1; | |
621 | @end group | |
622 | ||
623 | @group | |
624 | GCPRO1 (args); | |
625 | @end group | |
626 | ||
627 | @group | |
628 | while (CONSP (args)) | |
629 | @{ | |
7d2d7cc0 | 630 | val = eval_sub (XCAR (args)); |
b8d4c8d0 GM |
631 | if (!NILP (val)) |
632 | break; | |
633 | args = XCDR (args); | |
634 | @} | |
635 | @end group | |
636 | ||
637 | @group | |
638 | UNGCPRO; | |
639 | return val; | |
640 | @} | |
641 | @end group | |
642 | @end smallexample | |
643 | ||
644 | @cindex @code{DEFUN}, C macro to define Lisp primitives | |
645 | Let's start with a precise explanation of the arguments to the | |
646 | @code{DEFUN} macro. Here is a template for them: | |
647 | ||
648 | @example | |
649 | DEFUN (@var{lname}, @var{fname}, @var{sname}, @var{min}, @var{max}, @var{interactive}, @var{doc}) | |
650 | @end example | |
651 | ||
652 | @table @var | |
653 | @item lname | |
654 | This is the name of the Lisp symbol to define as the function name; in | |
655 | the example above, it is @code{or}. | |
656 | ||
657 | @item fname | |
d15aac68 CY |
658 | This is the C function name for this function. This is the name that |
659 | is used in C code for calling the function. The name is, by | |
660 | convention, @samp{F} prepended to the Lisp name, with all dashes | |
661 | (@samp{-}) in the Lisp name changed to underscores. Thus, to call | |
662 | this function from C code, call @code{For}. | |
b8d4c8d0 GM |
663 | |
664 | @item sname | |
665 | This is a C variable name to use for a structure that holds the data for | |
666 | the subr object that represents the function in Lisp. This structure | |
667 | conveys the Lisp symbol name to the initialization routine that will | |
668 | create the symbol and store the subr object as its definition. By | |
669 | convention, this name is always @var{fname} with @samp{F} replaced with | |
670 | @samp{S}. | |
671 | ||
672 | @item min | |
673 | This is the minimum number of arguments that the function requires. The | |
674 | function @code{or} allows a minimum of zero arguments. | |
675 | ||
676 | @item max | |
677 | This is the maximum number of arguments that the function accepts, if | |
678 | there is a fixed maximum. Alternatively, it can be @code{UNEVALLED}, | |
679 | indicating a special form that receives unevaluated arguments, or | |
680 | @code{MANY}, indicating an unlimited number of evaluated arguments (the | |
681 | equivalent of @code{&rest}). Both @code{UNEVALLED} and @code{MANY} are | |
9658dc2a GM |
682 | macros. If @var{max} is a number, it must be more than @var{min} but |
683 | less than 8. | |
b8d4c8d0 | 684 | |
84ebefe9 | 685 | @cindex interactive specification in primitives |
b8d4c8d0 | 686 | @item interactive |
84ebefe9 XF |
687 | This is an interactive specification, a string such as might be used |
688 | as the argument of @code{interactive} in a Lisp function. In the case | |
689 | of @code{or}, it is 0 (a null pointer), indicating that @code{or} | |
b02b5481 GM |
690 | cannot be called interactively. A value of @code{""} indicates a |
691 | function that should receive no arguments when called interactively. | |
84ebefe9 XF |
692 | If the value begins with a @samp{"(}, the string is evaluated as a |
693 | Lisp form. For example: | |
694 | ||
b02b5481 | 695 | @example |
84ebefe9 | 696 | @group |
b02b5481 GM |
697 | DEFUN ("foo", Ffoo, Sfoo, 0, UNEVALLED, |
698 | "(list (read-char-by-name \"Insert character: \")\ | |
84ebefe9 XF |
699 | (prefix-numeric-value current-prefix-arg)\ |
700 | t))", | |
701 | doc: /* @dots{} /*) | |
702 | @end group | |
b02b5481 | 703 | @end example |
b8d4c8d0 GM |
704 | |
705 | @item doc | |
706 | This is the documentation string. It uses C comment syntax rather | |
707 | than C string syntax because comment syntax requires nothing special | |
708 | to include multiple lines. The @samp{doc:} identifies the comment | |
709 | that follows as the documentation string. The @samp{/*} and @samp{*/} | |
710 | delimiters that begin and end the comment are not part of the | |
711 | documentation string. | |
712 | ||
713 | If the last line of the documentation string begins with the keyword | |
714 | @samp{usage:}, the rest of the line is treated as the argument list | |
715 | for documentation purposes. This way, you can use different argument | |
716 | names in the documentation string from the ones used in the C code. | |
717 | @samp{usage:} is required if the function has an unlimited number of | |
718 | arguments. | |
719 | ||
720 | All the usual rules for documentation strings in Lisp code | |
721 | (@pxref{Documentation Tips}) apply to C code documentation strings | |
722 | too. | |
723 | @end table | |
724 | ||
b88746ba | 725 | After the call to the @code{DEFUN} macro, you must write the |
d15aac68 CY |
726 | argument list for the C function, including the types for the |
727 | arguments. If the primitive accepts a fixed maximum number of Lisp | |
728 | arguments, there must be one C argument for each Lisp argument, and | |
729 | each argument must be of type @code{Lisp_Object}. (Various macros and | |
730 | functions for creating values of type @code{Lisp_Object} are declared | |
731 | in the file @file{lisp.h}.) If the primitive has no upper limit on | |
732 | the number of Lisp arguments, it must have exactly two C arguments: | |
733 | the first is the number of Lisp arguments, and the second is the | |
734 | address of a block containing their values. These have types | |
39670ef4 | 735 | @code{int} and @w{@code{Lisp_Object *}} respectively. Since |
74934dcc DA |
736 | @code{Lisp_Object} can hold any Lisp object of any data type, you |
737 | can determine the actual data type only at run time; so if you want | |
738 | a primitive to accept only a certain type of argument, you must check | |
739 | the type explicitly using a suitable predicate (@pxref{Type Predicates}). | |
740 | @cindex type checking internals | |
b8d4c8d0 GM |
741 | |
742 | @cindex @code{GCPRO} and @code{UNGCPRO} | |
743 | @cindex protect C variables from garbage collection | |
744 | Within the function @code{For} itself, note the use of the macros | |
d15aac68 CY |
745 | @code{GCPRO1} and @code{UNGCPRO}. These macros are defined for the |
746 | sake of the few platforms which do not use Emacs' default | |
747 | stack-marking garbage collector. The @code{GCPRO1} macro ``protects'' | |
748 | a variable from garbage collection, explicitly informing the garbage | |
749 | collector that that variable and all its contents must be as | |
750 | accessible. GC protection is necessary in any function which can | |
751 | perform Lisp evaluation by calling @code{eval_sub} or @code{Feval} as | |
752 | a subroutine, either directly or indirectly. | |
b8d4c8d0 GM |
753 | |
754 | It suffices to ensure that at least one pointer to each object is | |
d15aac68 | 755 | GC-protected. Thus, a particular local variable can do without |
b8d4c8d0 | 756 | protection if it is certain that the object it points to will be |
7d2d7cc0 | 757 | preserved by some other pointer (such as another local variable that |
d15aac68 CY |
758 | has a @code{GCPRO}). Otherwise, the local variable needs a |
759 | @code{GCPRO}. | |
b8d4c8d0 GM |
760 | |
761 | The macro @code{GCPRO1} protects just one local variable. If you | |
762 | want to protect two variables, use @code{GCPRO2} instead; repeating | |
763 | @code{GCPRO1} will not work. Macros @code{GCPRO3}, @code{GCPRO4}, | |
764 | @code{GCPRO5}, and @code{GCPRO6} also exist. All these macros | |
765 | implicitly use local variables such as @code{gcpro1}; you must declare | |
766 | these explicitly, with type @code{struct gcpro}. Thus, if you use | |
767 | @code{GCPRO2}, you must declare @code{gcpro1} and @code{gcpro2}. | |
b8d4c8d0 GM |
768 | |
769 | @code{UNGCPRO} cancels the protection of the variables that are | |
770 | protected in the current function. It is necessary to do this | |
771 | explicitly. | |
772 | ||
b8d4c8d0 GM |
773 | You must not use C initializers for static or global variables unless |
774 | the variables are never written once Emacs is dumped. These variables | |
775 | with initializers are allocated in an area of memory that becomes | |
776 | read-only (on certain operating systems) as a result of dumping Emacs. | |
777 | @xref{Pure Storage}. | |
778 | ||
b8d4c8d0 GM |
779 | @cindex @code{defsubr}, Lisp symbol for a primitive |
780 | Defining the C function is not enough to make a Lisp primitive | |
781 | available; you must also create the Lisp symbol for the primitive and | |
782 | store a suitable subr object in its function cell. The code looks like | |
783 | this: | |
784 | ||
785 | @example | |
7d2d7cc0 | 786 | defsubr (&@var{sname}); |
b8d4c8d0 GM |
787 | @end example |
788 | ||
789 | @noindent | |
7d2d7cc0 | 790 | Here @var{sname} is the name you used as the third argument to @code{DEFUN}. |
b8d4c8d0 GM |
791 | |
792 | If you add a new primitive to a file that already has Lisp primitives | |
793 | defined in it, find the function (near the end of the file) named | |
794 | @code{syms_of_@var{something}}, and add the call to @code{defsubr} | |
795 | there. If the file doesn't have this function, or if you create a new | |
796 | file, add to it a @code{syms_of_@var{filename}} (e.g., | |
797 | @code{syms_of_myfile}). Then find the spot in @file{emacs.c} where all | |
798 | of these functions are called, and add a call to | |
799 | @code{syms_of_@var{filename}} there. | |
800 | ||
801 | @anchor{Defining Lisp variables in C} | |
802 | @vindex byte-boolean-vars | |
803 | @cindex defining Lisp variables in C | |
804 | @cindex @code{DEFVAR_INT}, @code{DEFVAR_LISP}, @code{DEFVAR_BOOL} | |
805 | The function @code{syms_of_@var{filename}} is also the place to define | |
806 | any C variables that are to be visible as Lisp variables. | |
807 | @code{DEFVAR_LISP} makes a C variable of type @code{Lisp_Object} visible | |
808 | in Lisp. @code{DEFVAR_INT} makes a C variable of type @code{int} | |
809 | visible in Lisp with a value that is always an integer. | |
810 | @code{DEFVAR_BOOL} makes a C variable of type @code{int} visible in Lisp | |
811 | with a value that is either @code{t} or @code{nil}. Note that variables | |
812 | defined with @code{DEFVAR_BOOL} are automatically added to the list | |
813 | @code{byte-boolean-vars} used by the byte compiler. | |
814 | ||
7d2d7cc0 GM |
815 | @cindex defining customization variables in C |
816 | If you want to make a Lisp variables that is defined in C behave | |
817 | like one declared with @code{defcustom}, add an appropriate entry to | |
818 | @file{cus-start.el}. | |
819 | ||
b8d4c8d0 GM |
820 | @cindex @code{staticpro}, protection from GC |
821 | If you define a file-scope C variable of type @code{Lisp_Object}, | |
822 | you must protect it from garbage-collection by calling @code{staticpro} | |
823 | in @code{syms_of_@var{filename}}, like this: | |
824 | ||
825 | @example | |
826 | staticpro (&@var{variable}); | |
827 | @end example | |
828 | ||
829 | Here is another example function, with more complicated arguments. | |
830 | This comes from the code in @file{window.c}, and it demonstrates the use | |
831 | of macros and functions to manipulate Lisp objects. | |
832 | ||
833 | @smallexample | |
834 | @group | |
835 | DEFUN ("coordinates-in-window-p", Fcoordinates_in_window_p, | |
7d2d7cc0 GM |
836 | Scoordinates_in_window_p, 2, 2, 0, |
837 | doc: /* Return non-nil if COORDINATES are in WINDOW. | |
838 | ... | |
b8d4c8d0 GM |
839 | @end group |
840 | @group | |
7d2d7cc0 GM |
841 | or `right-margin' is returned. */) |
842 | (register Lisp_Object coordinates, Lisp_Object window) | |
b8d4c8d0 | 843 | @{ |
7d2d7cc0 GM |
844 | struct window *w; |
845 | struct frame *f; | |
b8d4c8d0 | 846 | int x, y; |
7d2d7cc0 | 847 | Lisp_Object lx, ly; |
b8d4c8d0 GM |
848 | @end group |
849 | ||
850 | @group | |
7d2d7cc0 GM |
851 | CHECK_LIVE_WINDOW (window); |
852 | w = XWINDOW (window); | |
853 | f = XFRAME (w->frame); | |
854 | CHECK_CONS (coordinates); | |
855 | lx = Fcar (coordinates); | |
856 | ly = Fcdr (coordinates); | |
857 | CHECK_NUMBER_OR_FLOAT (lx); | |
858 | CHECK_NUMBER_OR_FLOAT (ly); | |
859 | x = FRAME_PIXEL_X_FROM_CANON_X (f, lx) + FRAME_INTERNAL_BORDER_WIDTH(f); | |
860 | y = FRAME_PIXEL_Y_FROM_CANON_Y (f, ly) + FRAME_INTERNAL_BORDER_WIDTH(f); | |
b8d4c8d0 GM |
861 | @end group |
862 | ||
863 | @group | |
7d2d7cc0 | 864 | switch (coordinates_in_window (w, x, y)) |
b8d4c8d0 | 865 | @{ |
7d2d7cc0 | 866 | case ON_NOTHING: /* NOT in window at all. */ |
b8d4c8d0 GM |
867 | return Qnil; |
868 | @end group | |
869 | ||
7d2d7cc0 | 870 | ... |
b8d4c8d0 GM |
871 | |
872 | @group | |
7d2d7cc0 | 873 | case ON_MODE_LINE: /* In mode line of window. */ |
b8d4c8d0 GM |
874 | return Qmode_line; |
875 | @end group | |
876 | ||
7d2d7cc0 GM |
877 | ... |
878 | ||
b8d4c8d0 | 879 | @group |
7d2d7cc0 GM |
880 | case ON_SCROLL_BAR: /* On scroll-bar of window. */ |
881 | /* Historically we are supposed to return nil in this case. */ | |
882 | return Qnil; | |
b8d4c8d0 GM |
883 | @end group |
884 | ||
885 | @group | |
886 | default: | |
887 | abort (); | |
888 | @} | |
889 | @} | |
890 | @end group | |
891 | @end smallexample | |
892 | ||
893 | Note that C code cannot call functions by name unless they are defined | |
1df7defd | 894 | in C@. The way to call a function written in Lisp is to use |
b8d4c8d0 GM |
895 | @code{Ffuncall}, which embodies the Lisp function @code{funcall}. Since |
896 | the Lisp function @code{funcall} accepts an unlimited number of | |
897 | arguments, in C it takes two: the number of Lisp-level arguments, and a | |
898 | one-dimensional array containing their values. The first Lisp-level | |
899 | argument is the Lisp function to call, and the rest are the arguments to | |
900 | pass to it. Since @code{Ffuncall} can call the evaluator, you must | |
901 | protect pointers from garbage collection around the call to | |
902 | @code{Ffuncall}. | |
903 | ||
904 | The C functions @code{call0}, @code{call1}, @code{call2}, and so on, | |
905 | provide handy ways to call a Lisp function conveniently with a fixed | |
906 | number of arguments. They work by calling @code{Ffuncall}. | |
907 | ||
908 | @file{eval.c} is a very good file to look through for examples; | |
909 | @file{lisp.h} contains the definitions for some important macros and | |
910 | functions. | |
911 | ||
912 | If you define a function which is side-effect free, update the code | |
7d2d7cc0 | 913 | in @file{byte-opt.el} that binds @code{side-effect-free-fns} and |
b8d4c8d0 GM |
914 | @code{side-effect-and-error-free-fns} so that the compiler optimizer |
915 | knows about it. | |
916 | ||
917 | @node Object Internals | |
520f2425 | 918 | @section Object Internals |
b8d4c8d0 GM |
919 | @cindex object internals |
920 | ||
74934dcc | 921 | Emacs Lisp provides a rich set of the data types. Some of them, like cons |
f24f2e22 | 922 | cells, integers and strings, are common to nearly all Lisp dialects. Some |
74934dcc DA |
923 | others, like markers and buffers, are quite special and needed to provide |
924 | the basic support to write editor commands in Lisp. To implement such | |
925 | a variety of object types and provide an efficient way to pass objects between | |
926 | the subsystems of an interpreter, there is a set of C data structures and | |
927 | a special type to represent the pointers to all of them, which is known as | |
928 | @dfn{tagged pointer}. | |
929 | ||
930 | In C, the tagged pointer is an object of type @code{Lisp_Object}. Any | |
931 | initialized variable of such a type always holds the value of one of the | |
932 | following basic data types: integer, symbol, string, cons cell, float, | |
933 | vectorlike or miscellaneous object. Each of these data types has the | |
934 | corresponding tag value. All tags are enumerated by @code{enum Lisp_Type} | |
935 | and placed into a 3-bit bitfield of the @code{Lisp_Object}. The rest of the | |
09b73f08 | 936 | bits is the value itself. Integers are immediate, i.e., directly |
74934dcc DA |
937 | represented by those @dfn{value bits}, and all other objects are represented |
938 | by the C pointers to a corresponding object allocated from the heap. Width | |
939 | of the @code{Lisp_Object} is platform- and configuration-dependent: usually | |
39670ef4 | 940 | it's equal to the width of an underlying platform pointer (i.e., 32-bit on |
74934dcc DA |
941 | a 32-bit machine and 64-bit on a 64-bit one), but also there is a special |
942 | configuration where @code{Lisp_Object} is 64-bit but all pointers are 32-bit. | |
943 | The latter trick was designed to overcome the limited range of values for | |
944 | Lisp integers on a 32-bit system by using 64-bit @code{long long} type for | |
945 | @code{Lisp_Object}. | |
946 | ||
947 | The following C data structures are defined in @file{lisp.h} to represent | |
948 | the basic data types beyond integers: | |
949 | ||
950 | @table @code | |
951 | @item struct Lisp_Cons | |
952 | Cons cell, an object used to construct lists. | |
953 | ||
954 | @item struct Lisp_String | |
955 | String, the basic object to represent a sequence of characters. | |
956 | ||
957 | @item struct Lisp_Vector | |
958 | Array, a fixed-size set of Lisp objects which may be accessed by an index. | |
959 | ||
960 | @item struct Lisp_Symbol | |
961 | Symbol, the unique-named entity commonly used as an identifier. | |
962 | ||
963 | @item struct Lisp_Float | |
09b73f08 | 964 | Floating-point value. |
74934dcc DA |
965 | |
966 | @item union Lisp_Misc | |
967 | Miscellaneous kinds of objects which don't fit into any of the above. | |
968 | @end table | |
969 | ||
970 | These types are the first-class citizens of an internal type system. | |
971 | Since the tag space is limited, all other types are the subtypes of either | |
972 | @code{Lisp_Vectorlike} or @code{Lisp_Misc}. Vector subtypes are enumerated | |
973 | by @code{enum pvec_type}, and nearly all complex objects like windows, buffers, | |
974 | frames, and processes fall into this category. The rest of special types, | |
975 | including markers and overlays, are enumerated by @code{enum Lisp_Misc_Type} | |
976 | and form the set of subtypes of @code{Lisp_Misc}. | |
977 | ||
978 | Below there is a description of a few subtypes of @code{Lisp_Vectorlike}. | |
979 | Buffer object represents the text to display and edit. Window is the part | |
980 | of display structure which shows the buffer or used as a container to | |
981 | recursively place other windows on the same frame. (Do not confuse Emacs Lisp | |
982 | window object with the window as an entity managed by the user interface | |
983 | system like X; in Emacs terminology, the latter is called frame.) Finally, | |
984 | process object is used to manage the subprocesses. | |
b8d4c8d0 GM |
985 | |
986 | @menu | |
987 | * Buffer Internals:: Components of a buffer structure. | |
988 | * Window Internals:: Components of a window structure. | |
989 | * Process Internals:: Components of a process structure. | |
990 | @end menu | |
991 | ||
992 | @node Buffer Internals | |
520f2425 | 993 | @subsection Buffer Internals |
b8d4c8d0 GM |
994 | @cindex internals, of buffer |
995 | @cindex buffer internals | |
996 | ||
7d2d7cc0 | 997 | Two structures (see @file{buffer.h}) are used to represent buffers |
1df7defd | 998 | in C@. The @code{buffer_text} structure contains fields describing the |
7d2d7cc0 GM |
999 | text of a buffer; the @code{buffer} structure holds other fields. In |
1000 | the case of indirect buffers, two or more @code{buffer} structures | |
1001 | reference the same @code{buffer_text} structure. | |
b8d4c8d0 | 1002 | |
c773345a | 1003 | Here are some of the fields in @code{struct buffer_text}: |
b8d4c8d0 GM |
1004 | |
1005 | @table @code | |
1006 | @item beg | |
c773345a | 1007 | The address of the buffer contents. |
b8d4c8d0 GM |
1008 | |
1009 | @item gpt | |
c773345a CY |
1010 | @itemx gpt_byte |
1011 | The character and byte positions of the buffer gap. @xref{Buffer | |
1012 | Gap}. | |
b8d4c8d0 GM |
1013 | |
1014 | @item z | |
c773345a CY |
1015 | @itemx z_byte |
1016 | The character and byte positions of the end of the buffer text. | |
b8d4c8d0 GM |
1017 | |
1018 | @item gap_size | |
c773345a | 1019 | The size of buffer's gap. @xref{Buffer Gap}. |
b8d4c8d0 GM |
1020 | |
1021 | @item modiff | |
c773345a CY |
1022 | @itemx save_modiff |
1023 | @itemx chars_modiff | |
1024 | @itemx overlay_modiff | |
1025 | These fields count the number of buffer-modification events performed | |
1026 | in this buffer. @code{modiff} is incremented after each | |
1027 | buffer-modification event, and is never otherwise changed; | |
1028 | @code{save_modiff} contains the value of @code{modiff} the last time | |
1029 | the buffer was visited or saved; @code{chars_modiff} counts only | |
1030 | modifications to the characters in the buffer, ignoring all other | |
1031 | kinds of changes; and @code{overlay_modiff} counts only modifications | |
1032 | to the overlays. | |
b8d4c8d0 GM |
1033 | |
1034 | @item beg_unchanged | |
c773345a CY |
1035 | @itemx end_unchanged |
1036 | The number of characters at the start and end of the text that are | |
1037 | known to be unchanged since the last complete redisplay. | |
b8d4c8d0 GM |
1038 | |
1039 | @item unchanged_modified | |
c773345a CY |
1040 | @itemx overlay_unchanged_modified |
1041 | The values of @code{modiff} and @code{overlay_modiff}, respectively, | |
da6062e6 | 1042 | after the last complete redisplay. If their current values match |
c773345a | 1043 | @code{modiff} or @code{overlay_modiff}, that means |
b8d4c8d0 GM |
1044 | @code{beg_unchanged} and @code{end_unchanged} contain no useful |
1045 | information. | |
1046 | ||
1047 | @item markers | |
1048 | The markers that refer to this buffer. This is actually a single | |
1049 | marker, and successive elements in its marker @code{chain} are the other | |
1050 | markers referring to this buffer text. | |
1051 | ||
1052 | @item intervals | |
c773345a | 1053 | The interval tree which records the text properties of this buffer. |
b8d4c8d0 GM |
1054 | @end table |
1055 | ||
c773345a | 1056 | Some of the fields of @code{struct buffer} are: |
b8d4c8d0 GM |
1057 | |
1058 | @table @code | |
7d2d7cc0 | 1059 | @item header |
74934dcc DA |
1060 | A header of type @code{struct vectorlike_header} is common to all |
1061 | vectorlike objects. | |
b8d4c8d0 GM |
1062 | |
1063 | @item own_text | |
c773345a CY |
1064 | A @code{struct buffer_text} structure that ordinarily holds the buffer |
1065 | contents. In indirect buffers, this field is not used. | |
b8d4c8d0 GM |
1066 | |
1067 | @item text | |
c773345a CY |
1068 | A pointer to the @code{buffer_text} structure for this buffer. In an |
1069 | ordinary buffer, this is the @code{own_text} field above. In an | |
1070 | indirect buffer, this is the @code{own_text} field of the base buffer. | |
b8d4c8d0 | 1071 | |
74934dcc DA |
1072 | @item next |
1073 | A pointer to the next buffer, in the chain of all buffers, including | |
1074 | killed buffers. This chain is used only for allocation and garbage | |
1075 | collection, in order to collect killed buffers properly. | |
1076 | ||
b8d4c8d0 | 1077 | @item pt |
c773345a CY |
1078 | @itemx pt_byte |
1079 | The character and byte positions of point in a buffer. | |
b8d4c8d0 GM |
1080 | |
1081 | @item begv | |
c773345a CY |
1082 | @itemx begv_byte |
1083 | The character and byte positions of the beginning of the accessible | |
1084 | range of text in the buffer. | |
b8d4c8d0 GM |
1085 | |
1086 | @item zv | |
c773345a CY |
1087 | @itemx zv_byte |
1088 | The character and byte positions of the end of the accessible range of | |
1089 | text in the buffer. | |
b8d4c8d0 GM |
1090 | |
1091 | @item base_buffer | |
1092 | In an indirect buffer, this points to the base buffer. In an ordinary | |
1093 | buffer, it is null. | |
1094 | ||
c773345a CY |
1095 | @item local_flags |
1096 | This field contains flags indicating that certain variables are local | |
1097 | in this buffer. Such variables are declared in the C code using | |
1098 | @code{DEFVAR_PER_BUFFER}, and their buffer-local bindings are stored | |
1099 | in fields in the buffer structure itself. (Some of these fields are | |
b8d4c8d0 GM |
1100 | described in this table.) |
1101 | ||
1102 | @item modtime | |
c773345a CY |
1103 | The modification time of the visited file. It is set when the file is |
1104 | written or read. Before writing the buffer into a file, this field is | |
1105 | compared to the modification time of the file to see if the file has | |
1106 | changed on disk. @xref{Buffer Modification}. | |
b8d4c8d0 GM |
1107 | |
1108 | @item auto_save_modified | |
c773345a | 1109 | The time when the buffer was last auto-saved. |
b8d4c8d0 GM |
1110 | |
1111 | @item last_window_start | |
c773345a CY |
1112 | The @code{window-start} position in the buffer as of the last time the |
1113 | buffer was displayed in a window. | |
b8d4c8d0 GM |
1114 | |
1115 | @item clip_changed | |
c773345a CY |
1116 | This flag indicates that narrowing has changed in the buffer. |
1117 | @xref{Narrowing}. | |
b8d4c8d0 GM |
1118 | |
1119 | @item prevent_redisplay_optimizations_p | |
c773345a CY |
1120 | This flag indicates that redisplay optimizations should not be used to |
1121 | display this buffer. | |
b8d4c8d0 | 1122 | |
c773345a CY |
1123 | @item overlay_center |
1124 | This field holds the current overlay center position. @xref{Managing | |
1125 | Overlays}. | |
1126 | ||
1127 | @item overlays_before | |
1128 | @itemx overlays_after | |
1129 | These fields hold, respectively, a list of overlays that end at or | |
1130 | before the current overlay center, and a list of overlays that end | |
1131 | after the current overlay center. @xref{Managing Overlays}. | |
1132 | @code{overlays_before} is sorted in order of decreasing end position, | |
1133 | and @code{overlays_after} is sorted in order of increasing beginning | |
1134 | position. | |
b8d4c8d0 | 1135 | |
7d2d7cc0 GM |
1136 | @c FIXME? the following are now all Lisp_Object BUFFER_INTERNAL_FIELD (foo). |
1137 | ||
b8d4c8d0 | 1138 | @item name |
c773345a CY |
1139 | A Lisp string that names the buffer. It is guaranteed to be unique. |
1140 | @xref{Buffer Names}. | |
b8d4c8d0 | 1141 | |
c773345a CY |
1142 | @item save_length |
1143 | The length of the file this buffer is visiting, when last read or | |
1144 | saved. This and other fields concerned with saving are not kept in | |
1145 | the @code{buffer_text} structure because indirect buffers are never | |
1146 | saved. | |
b8d4c8d0 GM |
1147 | |
1148 | @item directory | |
c773345a CY |
1149 | The directory for expanding relative file names. This is the value of |
1150 | the buffer-local variable @code{default-directory} (@pxref{File Name Expansion}). | |
b8d4c8d0 | 1151 | |
c773345a CY |
1152 | @item filename |
1153 | The name of the file visited in this buffer, or @code{nil}. This is | |
1154 | the value of the buffer-local variable @code{buffer-file-name} | |
1155 | (@pxref{Buffer File Name}). | |
b8d4c8d0 | 1156 | |
c773345a CY |
1157 | @item undo_list |
1158 | @itemx backed_up | |
1159 | @itemx auto_save_file_name | |
7d2d7cc0 | 1160 | @itemx auto_save_file_format |
c773345a CY |
1161 | @itemx read_only |
1162 | @itemx file_format | |
1163 | @itemx file_truename | |
1164 | @itemx invisibility_spec | |
1165 | @itemx display_count | |
1166 | @itemx display_time | |
1167 | These fields store the values of Lisp variables that are automatically | |
1168 | buffer-local (@pxref{Buffer-Local Variables}), whose corresponding | |
1169 | variable names have the additional prefix @code{buffer-} and have | |
1170 | underscores replaced with dashes. For instance, @code{undo_list} | |
29157371 | 1171 | stores the value of @code{buffer-undo-list}. |
b8d4c8d0 GM |
1172 | |
1173 | @item mark | |
c773345a CY |
1174 | The mark for the buffer. The mark is a marker, hence it is also |
1175 | included on the list @code{markers}. @xref{The Mark}. | |
b8d4c8d0 GM |
1176 | |
1177 | @item local_var_alist | |
c773345a CY |
1178 | The association list describing the buffer-local variable bindings of |
1179 | this buffer, not including the built-in buffer-local bindings that | |
1180 | have special slots in the buffer object. (Those slots are omitted | |
1181 | from this table.) @xref{Buffer-Local Variables}. | |
b8d4c8d0 GM |
1182 | |
1183 | @item major_mode | |
1184 | Symbol naming the major mode of this buffer, e.g., @code{lisp-mode}. | |
1185 | ||
1186 | @item mode_name | |
c773345a | 1187 | Pretty name of the major mode, e.g., @code{"Lisp"}. |
b8d4c8d0 GM |
1188 | |
1189 | @item keymap | |
c773345a CY |
1190 | @itemx abbrev_table |
1191 | @itemx syntax_table | |
1192 | @itemx category_table | |
1193 | @itemx display_table | |
1194 | These fields store the buffer's local keymap (@pxref{Keymaps}), abbrev | |
1195 | table (@pxref{Abbrev Tables}), syntax table (@pxref{Syntax Tables}), | |
1196 | category table (@pxref{Categories}), and display table (@pxref{Display | |
1197 | Tables}). | |
b8d4c8d0 GM |
1198 | |
1199 | @item downcase_table | |
c773345a CY |
1200 | @itemx upcase_table |
1201 | @itemx case_canon_table | |
1202 | These fields store the conversion tables for converting text to lower | |
1203 | case, upper case, and for canonicalizing text for case-fold search. | |
b8d4c8d0 GM |
1204 | @xref{Case Tables}. |
1205 | ||
b8d4c8d0 GM |
1206 | @item minor_modes |
1207 | An alist of the minor modes of this buffer. | |
1208 | ||
b8d4c8d0 | 1209 | @item pt_marker |
c773345a CY |
1210 | @itemx begv_marker |
1211 | @itemx zv_marker | |
1212 | These fields are only used in an indirect buffer, or in a buffer that | |
1213 | is the base of an indirect buffer. Each holds a marker that records | |
1214 | @code{pt}, @code{begv}, and @code{zv} respectively, for this buffer | |
b8d4c8d0 GM |
1215 | when the buffer is not current. |
1216 | ||
c773345a CY |
1217 | @item mode_line_format |
1218 | @itemx header_line_format | |
1219 | @itemx case_fold_search | |
1220 | @itemx tab_width | |
1221 | @itemx fill_column | |
1222 | @itemx left_margin | |
1223 | @itemx auto_fill_function | |
c773345a CY |
1224 | @itemx truncate_lines |
1225 | @itemx word_wrap | |
1226 | @itemx ctl_arrow | |
7d2d7cc0 GM |
1227 | @itemx bidi_display_reordering |
1228 | @itemx bidi_paragraph_direction | |
c773345a CY |
1229 | @itemx selective_display |
1230 | @itemx selective_display_ellipses | |
1231 | @itemx overwrite_mode | |
1232 | @itemx abbrev_mode | |
c773345a CY |
1233 | @itemx mark_active |
1234 | @itemx enable_multibyte_characters | |
1235 | @itemx buffer_file_coding_system | |
c773345a CY |
1236 | @itemx cache_long_line_scans |
1237 | @itemx point_before_scroll | |
1238 | @itemx left_fringe_width | |
1239 | @itemx right_fringe_width | |
1240 | @itemx fringes_outside_margins | |
1241 | @itemx scroll_bar_width | |
1242 | @itemx indicate_empty_lines | |
1243 | @itemx indicate_buffer_boundaries | |
1244 | @itemx fringe_indicator_alist | |
1245 | @itemx fringe_cursor_alist | |
1246 | @itemx scroll_up_aggressively | |
1247 | @itemx scroll_down_aggressively | |
1248 | @itemx cursor_type | |
1249 | @itemx cursor_in_non_selected_windows | |
1250 | These fields store the values of Lisp variables that are automatically | |
1251 | buffer-local (@pxref{Buffer-Local Variables}), whose corresponding | |
1252 | variable names have underscores replaced with dashes. For instance, | |
1253 | @code{mode_line_format} stores the value of @code{mode-line-format}. | |
b8d4c8d0 GM |
1254 | |
1255 | @item last_selected_window | |
1256 | This is the last window that was selected with this buffer in it, or @code{nil} | |
1257 | if that window no longer displays this buffer. | |
b8d4c8d0 GM |
1258 | @end table |
1259 | ||
1260 | @node Window Internals | |
520f2425 | 1261 | @subsection Window Internals |
b8d4c8d0 GM |
1262 | @cindex internals, of window |
1263 | @cindex window internals | |
1264 | ||
7d2d7cc0 GM |
1265 | The fields of a window (for a complete list, see the definition of |
1266 | @code{struct window} in @file{window.h}) include: | |
b8d4c8d0 GM |
1267 | |
1268 | @table @code | |
1269 | @item frame | |
1270 | The frame that this window is on. | |
1271 | ||
1272 | @item mini_p | |
1273 | Non-@code{nil} if this window is a minibuffer window. | |
1274 | ||
1275 | @item parent | |
1276 | Internally, Emacs arranges windows in a tree; each group of siblings has | |
1277 | a parent window whose area includes all the siblings. This field points | |
1278 | to a window's parent. | |
1279 | ||
1280 | Parent windows do not display buffers, and play little role in display | |
1281 | except to shape their child windows. Emacs Lisp programs usually have | |
1282 | no access to the parent windows; they operate on the windows at the | |
1283 | leaves of the tree, which actually display buffers. | |
1284 | ||
37b2bf43 XF |
1285 | @c FIXME: These two slots and the `buffer' slot below were replaced |
1286 | @c with a single slot `contents' on 2013-03-28. --xfq | |
b8d4c8d0 | 1287 | @item hchild |
ee2d5b5e CY |
1288 | @itemx vchild |
1289 | These fields contain the window's leftmost child and its topmost child | |
1290 | respectively. @code{hchild} is used if the window is subdivided | |
1291 | horizontally by child windows, and @code{vchild} if it is subdivided | |
7d2d7cc0 | 1292 | vertically. In a live window, only one of @code{hchild}, @code{vchild}, |
1df7defd | 1293 | and @code{buffer} (q.v.@:) is non-@code{nil}. |
b8d4c8d0 GM |
1294 | |
1295 | @item next | |
ee2d5b5e CY |
1296 | @itemx prev |
1297 | The next sibling and previous sibling of this window. @code{next} is | |
520f2425 GM |
1298 | @code{nil} if the window is the right-most or bottom-most in its group; |
1299 | @code{prev} is @code{nil} if it is the left-most or top-most in its | |
ee2d5b5e CY |
1300 | group. |
1301 | ||
1302 | @item left_col | |
1303 | The left-hand edge of the window, measured in columns, relative to the | |
1304 | leftmost column in the frame (column 0). | |
1305 | ||
1306 | @item top_line | |
1307 | The top edge of the window, measured in lines, relative to the topmost | |
1308 | line in the frame (line 0). | |
1309 | ||
1310 | @item total_cols | |
1311 | @itemx total_lines | |
1312 | The width and height of the window, measured in columns and lines | |
1313 | respectively. The width includes the scroll bar and fringes, and/or | |
1314 | the separator line on the right of the window (if any). | |
b8d4c8d0 GM |
1315 | |
1316 | @item buffer | |
ee2d5b5e | 1317 | The buffer that the window is displaying. |
b8d4c8d0 GM |
1318 | |
1319 | @item start | |
ee2d5b5e CY |
1320 | A marker pointing to the position in the buffer that is the first |
1321 | character displayed in the window. | |
b8d4c8d0 GM |
1322 | |
1323 | @item pointm | |
1324 | @cindex window point internals | |
1325 | This is the value of point in the current buffer when this window is | |
1326 | selected; when it is not selected, it retains its previous value. | |
1327 | ||
1328 | @item force_start | |
1329 | If this flag is non-@code{nil}, it says that the window has been | |
1330 | scrolled explicitly by the Lisp program. This affects what the next | |
1331 | redisplay does if point is off the screen: instead of scrolling the | |
1332 | window to show the text around point, it moves point to a location that | |
1333 | is on the screen. | |
1334 | ||
1335 | @item frozen_window_start_p | |
1336 | This field is set temporarily to 1 to indicate to redisplay that | |
1337 | @code{start} of this window should not be changed, even if point | |
1338 | gets invisible. | |
1339 | ||
1340 | @item start_at_line_beg | |
1341 | Non-@code{nil} means current value of @code{start} was the beginning of a line | |
1342 | when it was chosen. | |
1343 | ||
b8d4c8d0 GM |
1344 | @item use_time |
1345 | This is the last time that the window was selected. The function | |
1346 | @code{get-lru-window} uses this field. | |
1347 | ||
1348 | @item sequence_number | |
1349 | A unique number assigned to this window when it was created. | |
1350 | ||
1351 | @item last_modified | |
1352 | The @code{modiff} field of the window's buffer, as of the last time | |
1353 | a redisplay completed in this window. | |
1354 | ||
1355 | @item last_overlay_modified | |
1356 | The @code{overlay_modiff} field of the window's buffer, as of the last | |
1357 | time a redisplay completed in this window. | |
1358 | ||
1359 | @item last_point | |
1360 | The buffer's value of point, as of the last time a redisplay completed | |
1361 | in this window. | |
1362 | ||
1363 | @item last_had_star | |
1364 | A non-@code{nil} value means the window's buffer was ``modified'' when the | |
1365 | window was last updated. | |
1366 | ||
1367 | @item vertical_scroll_bar | |
1368 | This window's vertical scroll bar. | |
1369 | ||
7d2d7cc0 GM |
1370 | @item left_margin_cols |
1371 | @itemx right_margin_cols | |
ee2d5b5e | 1372 | The widths of the left and right margins in this window. A value of |
7d2d7cc0 GM |
1373 | @code{nil} means no margin. |
1374 | ||
1375 | @item left_fringe_width | |
1376 | @itemx right_fringe_width | |
1377 | The widths of the left and right fringes in this window. A value of | |
1378 | @code{nil} or @code{t} means use the values of the frame. | |
1379 | ||
1380 | @item fringes_outside_margins | |
1381 | A non-@code{nil} value means the fringes outside the display margins; | |
1382 | othersize they are between the margin and the text. | |
b8d4c8d0 GM |
1383 | |
1384 | @item window_end_pos | |
1385 | This is computed as @code{z} minus the buffer position of the last glyph | |
1386 | in the current matrix of the window. The value is only valid if | |
1387 | @code{window_end_valid} is not @code{nil}. | |
1388 | ||
1389 | @item window_end_bytepos | |
1390 | The byte position corresponding to @code{window_end_pos}. | |
1391 | ||
1392 | @item window_end_vpos | |
1393 | The window-relative vertical position of the line containing | |
1394 | @code{window_end_pos}. | |
1395 | ||
1396 | @item window_end_valid | |
1397 | This field is set to a non-@code{nil} value if @code{window_end_pos} is truly | |
7d2d7cc0 | 1398 | valid. This is @code{nil} if nontrivial redisplay is pre-empted, since in that |
b8d4c8d0 GM |
1399 | case the display that @code{window_end_pos} was computed for did not get |
1400 | onto the screen. | |
1401 | ||
b8d4c8d0 GM |
1402 | @item cursor |
1403 | A structure describing where the cursor is in this window. | |
1404 | ||
1405 | @item last_cursor | |
1406 | The value of @code{cursor} as of the last redisplay that finished. | |
1407 | ||
1408 | @item phys_cursor | |
1409 | A structure describing where the cursor of this window physically is. | |
1410 | ||
1411 | @item phys_cursor_type | |
7d2d7cc0 GM |
1412 | @c FIXME What is this? |
1413 | @c itemx phys_cursor_ascent | |
1414 | @itemx phys_cursor_height | |
1415 | @itemx phys_cursor_width | |
1416 | The type, height, and width of the cursor that was last displayed on | |
1417 | this window. | |
b8d4c8d0 GM |
1418 | |
1419 | @item phys_cursor_on_p | |
1420 | This field is non-zero if the cursor is physically on. | |
1421 | ||
1422 | @item cursor_off_p | |
7d2d7cc0 GM |
1423 | Non-zero means the cursor in this window is logically off. This is |
1424 | used for blinking the cursor. | |
b8d4c8d0 GM |
1425 | |
1426 | @item last_cursor_off_p | |
1427 | This field contains the value of @code{cursor_off_p} as of the time of | |
1428 | the last redisplay. | |
1429 | ||
1430 | @item must_be_updated_p | |
1431 | This is set to 1 during redisplay when this window must be updated. | |
1432 | ||
1433 | @item hscroll | |
1434 | This is the number of columns that the display in the window is scrolled | |
1435 | horizontally to the left. Normally, this is 0. | |
1436 | ||
1437 | @item vscroll | |
1438 | Vertical scroll amount, in pixels. Normally, this is 0. | |
1439 | ||
1440 | @item dedicated | |
1441 | Non-@code{nil} if this window is dedicated to its buffer. | |
1442 | ||
1443 | @item display_table | |
1444 | The window's display table, or @code{nil} if none is specified for it. | |
1445 | ||
1446 | @item update_mode_line | |
1447 | Non-@code{nil} means this window's mode line needs to be updated. | |
1448 | ||
1449 | @item base_line_number | |
1450 | The line number of a certain position in the buffer, or @code{nil}. | |
1451 | This is used for displaying the line number of point in the mode line. | |
1452 | ||
1453 | @item base_line_pos | |
1454 | The position in the buffer for which the line number is known, or | |
7d2d7cc0 GM |
1455 | @code{nil} meaning none is known. If it is a buffer, don't display |
1456 | the line number as long as the window shows that buffer. | |
b8d4c8d0 | 1457 | |
b8d4c8d0 GM |
1458 | @item column_number_displayed |
1459 | The column number currently displayed in this window's mode line, or @code{nil} | |
1460 | if column numbers are not being displayed. | |
1461 | ||
1462 | @item current_matrix | |
7d2d7cc0 GM |
1463 | @itemx desired_matrix |
1464 | Glyph matrices describing the current and desired display of this window. | |
b8d4c8d0 GM |
1465 | @end table |
1466 | ||
1467 | @node Process Internals | |
520f2425 | 1468 | @subsection Process Internals |
b8d4c8d0 GM |
1469 | @cindex internals, of process |
1470 | @cindex process internals | |
1471 | ||
7d2d7cc0 GM |
1472 | The fields of a process (for a complete list, see the definition of |
1473 | @code{struct Lisp_Process} in @file{process.h}) include: | |
b8d4c8d0 GM |
1474 | |
1475 | @table @code | |
1476 | @item name | |
1477 | A string, the name of the process. | |
1478 | ||
1479 | @item command | |
1480 | A list containing the command arguments that were used to start this | |
c73e02fa GM |
1481 | process. For a network or serial process, it is @code{nil} if the |
1482 | process is running or @code{t} if the process is stopped. | |
b8d4c8d0 GM |
1483 | |
1484 | @item filter | |
458e643b | 1485 | A function used to accept output from the process. |
b8d4c8d0 GM |
1486 | |
1487 | @item sentinel | |
458e643b | 1488 | A function called whenever the state of the process changes. |
b8d4c8d0 GM |
1489 | |
1490 | @item buffer | |
1491 | The associated buffer of the process. | |
1492 | ||
1493 | @item pid | |
1494 | An integer, the operating system's process @acronym{ID}. | |
7d2d7cc0 | 1495 | Pseudo-processes such as network or serial connections use a value of 0. |
b8d4c8d0 GM |
1496 | |
1497 | @item childp | |
7d2d7cc0 GM |
1498 | A flag, @code{t} if this is really a child process. For a network or |
1499 | serial connection, it is a plist based on the arguments to | |
1500 | @code{make-network-process} or @code{make-serial-process}. | |
b8d4c8d0 GM |
1501 | |
1502 | @item mark | |
1503 | A marker indicating the position of the end of the last output from this | |
1504 | process inserted into the buffer. This is often but not always the end | |
1505 | of the buffer. | |
1506 | ||
1507 | @item kill_without_query | |
ee2d5b5e CY |
1508 | If this is non-zero, killing Emacs while this process is still running |
1509 | does not ask for confirmation about killing the process. | |
b8d4c8d0 | 1510 | |
7d2d7cc0 GM |
1511 | @item raw_status |
1512 | The raw process status, as returned by the @code{wait} system call. | |
b8d4c8d0 GM |
1513 | |
1514 | @item status | |
1515 | The process status, as @code{process-status} should return it. | |
1516 | ||
1517 | @item tick | |
1518 | @itemx update_tick | |
1519 | If these two fields are not equal, a change in the status of the process | |
1520 | needs to be reported, either by running the sentinel or by inserting a | |
1521 | message in the process buffer. | |
1522 | ||
1523 | @item pty_flag | |
a2eb421b | 1524 | Non-@code{nil} if communication with the subprocess uses a pty; |
b8d4c8d0 GM |
1525 | @code{nil} if it uses a pipe. |
1526 | ||
1527 | @item infd | |
1528 | The file descriptor for input from the process. | |
1529 | ||
1530 | @item outfd | |
1531 | The file descriptor for output to the process. | |
1532 | ||
b8d4c8d0 GM |
1533 | @item tty_name |
1534 | The name of the terminal that the subprocess is using, | |
1535 | or @code{nil} if it is using pipes. | |
1536 | ||
1537 | @item decode_coding_system | |
1538 | Coding-system for decoding the input from this process. | |
1539 | ||
1540 | @item decoding_buf | |
1541 | A working buffer for decoding. | |
1542 | ||
1543 | @item decoding_carryover | |
1544 | Size of carryover in decoding. | |
1545 | ||
1546 | @item encode_coding_system | |
1547 | Coding-system for encoding the output to this process. | |
1548 | ||
1549 | @item encoding_buf | |
1550 | A working buffer for encoding. | |
1551 | ||
b8d4c8d0 GM |
1552 | @item inherit_coding_system_flag |
1553 | Flag to set @code{coding-system} of the process buffer from the | |
1554 | coding system used to decode process output. | |
c73e02fa GM |
1555 | |
1556 | @item type | |
1557 | Symbol indicating the type of process: @code{real}, @code{network}, | |
7d2d7cc0 | 1558 | @code{serial}. |
c73e02fa | 1559 | |
b8d4c8d0 | 1560 | @end table |
7d2d7cc0 | 1561 | |
d92d9c95 PE |
1562 | @node C Integer Types |
1563 | @section C Integer Types | |
1564 | @cindex integer types (C programming language) | |
1565 | ||
1566 | Here are some guidelines for use of integer types in the Emacs C | |
1567 | source code. These guidelines sometimes give competing advice; common | |
1568 | sense is advised. | |
1569 | ||
1570 | @itemize @bullet | |
1571 | @item | |
1572 | Avoid arbitrary limits. For example, avoid @code{int len = strlen | |
1573 | (s);} unless the length of @code{s} is required for other reasons to | |
1574 | fit in @code{int} range. | |
1575 | ||
1576 | @item | |
1577 | Do not assume that signed integer arithmetic wraps around on overflow. | |
1578 | This is no longer true of Emacs porting targets: signed integer | |
1579 | overflow has undefined behavior in practice, and can dump core or | |
1580 | even cause earlier or later code to behave ``illogically''. Unsigned | |
1581 | overflow does wrap around reliably, modulo a power of two. | |
1582 | ||
1583 | @item | |
1584 | Prefer signed types to unsigned, as code gets confusing when signed | |
1585 | and unsigned types are combined. Many other guidelines assume that | |
1586 | types are signed; in the rarer cases where unsigned types are needed, | |
1587 | similar advice may apply to the unsigned counterparts (e.g., | |
1588 | @code{size_t} instead of @code{ptrdiff_t}, or @code{uintptr_t} instead | |
1589 | of @code{intptr_t}). | |
1590 | ||
1591 | @item | |
1592 | Prefer @code{int} for Emacs character codes, in the range 0 ..@: 0x3FFFFF. | |
1593 | ||
1594 | @item | |
1595 | Prefer @code{ptrdiff_t} for sizes, i.e., for integers bounded by the | |
1596 | maximum size of any individual C object or by the maximum number of | |
1597 | elements in any C array. This is part of Emacs's general preference | |
1598 | for signed types. Using @code{ptrdiff_t} limits objects to | |
1599 | @code{PTRDIFF_MAX} bytes, but larger objects would cause trouble | |
1600 | anyway since they would break pointer subtraction, so this does not | |
1601 | impose an arbitrary limit. | |
1602 | ||
1603 | @item | |
1604 | Prefer @code{intptr_t} for internal representations of pointers, or | |
1605 | for integers bounded only by the number of objects that can exist at | |
1606 | any given time or by the total number of bytes that can be allocated. | |
1607 | Currently Emacs sometimes uses other types when @code{intptr_t} would | |
1608 | be better; fixing this is lower priority, as the code works as-is on | |
1609 | Emacs's current porting targets. | |
1610 | ||
1611 | @item | |
1612 | Prefer the Emacs-defined type @code{EMACS_INT} for representing values | |
1613 | converted to or from Emacs Lisp fixnums, as fixnum arithmetic is based | |
1614 | on @code{EMACS_INT}. | |
1615 | ||
1616 | @item | |
1617 | When representing a system value (such as a file size or a count of | |
1618 | seconds since the Epoch), prefer the corresponding system type (e.g., | |
1619 | @code{off_t}, @code{time_t}). Do not assume that a system type is | |
1620 | signed, unless this assumption is known to be safe. For example, | |
1621 | although @code{off_t} is always signed, @code{time_t} need not be. | |
1622 | ||
1623 | @item | |
1624 | Prefer the Emacs-defined type @code{printmax_t} for representing | |
09b73f08 | 1625 | values that might be any signed integer that can be printed, |
d92d9c95 PE |
1626 | using a @code{printf}-family function. |
1627 | ||
1628 | @item | |
1629 | Prefer @code{intmax_t} for representing values that might be any | |
1630 | signed integer value. | |
1631 | ||
d92d9c95 | 1632 | @item |
a2326811 PE |
1633 | Prefer @code{bool}, @code{false} and @code{true} for booleans. |
1634 | Using @code{bool} can make programs easier to read and a bit faster than | |
1635 | using @code{int}. Although it is also OK to use @code{int}, @code{0} | |
1636 | and @code{1}, this older style is gradually being phased out. When | |
d92d9c95 PE |
1637 | using @code{bool}, respect the limitations of the replacement |
1638 | implementation of @code{bool}, as documented in the source file | |
1639 | @file{lib/stdbool.in.h}, so that Emacs remains portable to pre-C99 | |
76377e46 PE |
1640 | platforms. In particular, boolean bitfields should be of type |
1641 | @code{bool_bf}, not @code{bool}, so that they work correctly even when | |
1642 | compiling Objective C with standard GCC. | |
1643 | ||
1644 | @item | |
1645 | In bitfields, prefer @code{unsigned int} or @code{signed int} to | |
1646 | @code{int}, as @code{int} is less portable: it might be signed, and | |
1647 | might not be. Single-bit bit fields should be @code{unsigned int} or | |
1648 | @code{bool_bf} so that their values are 0 or 1. | |
d92d9c95 PE |
1649 | @end itemize |
1650 | ||
7d2d7cc0 | 1651 | @c FIXME Mention src/globals.h somewhere in this file? |