Commit | Line | Data |
---|---|---|
a44af9f2 RS |
1 | @c -*-texinfo-*- |
2 | @c This is part of the GNU Emacs Lisp Reference Manual. | |
3 | @c Copyright (C) 1990, 1991, 1992, 1993 Free Software Foundation, Inc. | |
4 | @c See the file elisp.texi for copying conditions. | |
5 | @setfilename ../info/internals | |
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 to preload Lisp libraries into Emacs. | |
16 | * Pure Storage:: A kludge to make preloaded Lisp functions sharable. | |
17 | * Garbage Collection:: Reclaiming space for Lisp objects no longer used. | |
18 | * Writing Emacs Primitives:: Writing C code for Emacs. | |
19 | * Object Internals:: Data formats of buffers, windows, processes. | |
20 | @end menu | |
21 | ||
22 | @node Building Emacs, Pure Storage, GNU Emacs Internals, GNU Emacs Internals | |
23 | @appendixsec Building Emacs | |
24 | @cindex building Emacs | |
25 | @pindex temacs | |
26 | ||
27 | This section explains the steps involved in building the Emacs | |
28 | executable. You don't have to know this material to build and install | |
29 | Emacs, since the makefiles do all these things automatically. This | |
30 | information is pertinent to Emacs maintenance. | |
31 | ||
32 | Compilation of the C source files in the @file{src} directory | |
33 | produces an executable file called @file{temacs}, also called a | |
34 | @dfn{bare impure Emacs}. It contains the Emacs Lisp interpreter and I/O | |
35 | routines, but not the editing commands. | |
36 | ||
37 | @cindex @file{loadup.el} | |
38 | The command @w{@samp{temacs -l loadup}} uses @file{temacs} to create | |
39 | the real runnable Emacs executable. These arguments direct | |
40 | @file{temacs} to evaluate the Lisp files specified in the file | |
41 | @file{loadup.el}. These files set up the normal Emacs editing | |
42 | environment, resulting in an Emacs which is still impure but no longer | |
43 | bare. | |
44 | ||
45 | It takes a substantial time to load the standard Lisp files. Luckily, | |
46 | you don't have to do this each time you run Emacs; @file{temacs} can | |
47 | dump out an executable program called @file{emacs} which has these files | |
48 | preloaded. @file{emacs} starts more quickly because it does not need to | |
49 | load the files. This is the Emacs executable that is normally | |
50 | installed. | |
51 | ||
52 | To create @file{emacs}, use the command @samp{temacs -batch -l loadup | |
53 | dump}. The purpose of @samp{-batch} here is to prevent @file{temacs} | |
54 | from trying to initialize any of its data on the terminal; this ensures | |
55 | that the tables of terminal information are empty in the dumped Emacs. | |
56 | The argument @samp{dump} tells @file{loadup.el} to dump a new executable | |
57 | named @file{emacs}. | |
58 | ||
59 | Some operating systems don't support dumping. On those systems, you | |
60 | must start Emacs with the @samp{temacs -l loadup} command each time you | |
61 | use it. This takes a long time, but since you need to start Emacs once | |
62 | a day at most---or once a week if you never log out---the extra time is | |
63 | not too severe a problem. | |
64 | ||
65 | @cindex @file{site-load.el} | |
66 | You can specify additional files to preload by writing a library named | |
67 | @file{site-load.el} which loads them. You may need to increase the | |
68 | value of @code{PURESIZE}, in @file{src/puresize.h}, to make room for the | |
69 | additional files. (Try adding increments of 20000 until it is big | |
70 | enough.) However, the advantage of preloading additional files | |
71 | decreases as machines get faster. On modern machines, it is usually not | |
72 | advisable. | |
73 | ||
74 | @cindex @file{site-init.el} | |
75 | You can specify other things to be done in Lisp just before dumping by | |
76 | putting them in a library named @file{site-init.el}. However, if these | |
77 | things might alter the behavior that users expect from an ordinary | |
78 | unmodified Emacs, it is better to do them in @file{default.el}, so that | |
79 | users can override them if they wish. @xref{Start-up Summary}. | |
80 | ||
81 | Before @file{emacs} is dumped, the documentation strings for primitive | |
82 | and preloaded functions (and variables) need to be found in the file | |
83 | where they are stored. This is done by calling | |
84 | @code{Snarf-documentation} (@pxref{Accessing Documentation}). These | |
85 | strings were moved out of @file{emacs} to make it smaller. | |
86 | @xref{Documentation Basics}. | |
87 | ||
88 | @defun dump-emacs to-file from-file | |
89 | @cindex unexec | |
90 | This function dumps the current state of Emacs into an executable file | |
91 | @var{to-file}. It takes symbols from @var{from-file} (this is normally | |
92 | the executable file @file{temacs}). | |
93 | ||
94 | If you use this function in an Emacs that was already dumped, you must | |
95 | set @code{command-line-processed} to @code{nil} first for good results. | |
96 | @xref{Command Line Arguments}. | |
97 | @end defun | |
98 | ||
99 | @deffn Command emacs-version | |
100 | This function returns a string describing the version of Emacs that is | |
101 | running. It is useful to include this string in bug reports. | |
102 | ||
103 | @example | |
104 | @group | |
105 | (emacs-version) | |
106 | @result{} "GNU Emacs 19.22.1 of Fri Feb 27 1994 \ | |
107 | on slug (berkeley-unix)" | |
108 | @end group | |
109 | @end example | |
110 | ||
111 | Called interactively, the function prints the same information in the | |
112 | echo area. | |
113 | @end deffn | |
114 | ||
115 | @defvar emacs-build-time | |
116 | The value of this variable is the time at which Emacs was built at the | |
117 | local site. | |
118 | ||
119 | @example | |
120 | @group | |
121 | emacs-build-time | |
122 | @result{} "Fri Feb 27 14:55:57 1994" | |
123 | @end group | |
124 | @end example | |
125 | @end defvar | |
126 | ||
127 | @defvar emacs-version | |
128 | The value of this variable is the version of Emacs being run. It is a | |
129 | string such as @code{"19.22.1"}. | |
130 | @end defvar | |
131 | ||
132 | @node Pure Storage, Garbage Collection, Building Emacs, GNU Emacs Internals | |
133 | @appendixsec Pure Storage | |
134 | @cindex pure storage | |
135 | ||
136 | There are two types of storage in GNU Emacs Lisp for user-created Lisp | |
137 | objects: @dfn{normal storage} and @dfn{pure storage}. Normal storage is | |
138 | where all the new data which is created during an Emacs session is kept; | |
139 | see the following section for information on normal storage. Pure | |
140 | storage is used for certain data in the preloaded standard Lisp files: | |
141 | data that should never change during actual use of Emacs. | |
142 | ||
143 | Pure storage is allocated only while @file{temacs} is loading the | |
144 | standard preloaded Lisp libraries. In the file @file{emacs}, it is | |
145 | marked as read-only (on operating systems which permit this), so that | |
146 | the memory space can be shared by all the Emacs jobs running on the | |
147 | machine at once. Pure storage is not expandable; a fixed amount is | |
148 | allocated when Emacs is compiled, and if that is not sufficient for the | |
149 | preloaded libraries, @file{temacs} crashes. If that happens, you will | |
150 | have to increase the compilation parameter @code{PURESIZE} in the file | |
151 | @file{src/puresize.h}. This normally won't happen unless you try to | |
152 | preload additional libraries or add features to the standard ones. | |
153 | ||
154 | @defun purecopy object | |
155 | This function makes a copy of @var{object} in pure storage and returns | |
156 | it. It copies strings by simply making a new string with the same | |
157 | characters in pure storage. It recursively copies the contents of | |
158 | vectors and cons cells. It does not make copies of symbols, or any | |
159 | other objects, but just returns them unchanged. It signals an error if | |
160 | asked to copy markers. | |
161 | ||
162 | This function is used only while Emacs is being built and dumped; it is | |
163 | called only in the file @file{emacs/lisp/loaddefs.el}. | |
164 | @end defun | |
165 | ||
166 | @defvar pure-bytes-used | |
167 | The value of this variable is the number of bytes of pure storage | |
168 | allocated so far. Typically, in a dumped Emacs, this number is very | |
169 | close to the total amount of pure storage available---if it were not, | |
170 | we would preallocate less. | |
171 | @end defvar | |
172 | ||
173 | @defvar purify-flag | |
174 | This variable determines whether @code{defun} should make a copy of the | |
175 | function definition in pure storage. If it is non-@code{nil}, then the | |
176 | function definition is copied into pure storage. | |
177 | ||
178 | This flag is @code{t} while loading all of the basic functions for | |
179 | building Emacs initially (allowing those functions to be sharable and | |
180 | non-collectible). It is set to @code{nil} when Emacs is saved out | |
181 | as @file{emacs}. The flag is set and reset in the C sources. | |
182 | ||
183 | You should not change this flag in a running Emacs. | |
184 | @end defvar | |
185 | ||
186 | @node Garbage Collection, Writing Emacs Primitives, Pure Storage, GNU Emacs Internals | |
187 | @appendixsec Garbage Collection | |
188 | @cindex garbage collector | |
189 | ||
190 | @cindex memory allocation | |
191 | When a program creates a list or the user defines a new function (such | |
192 | as by loading a library), then that data is placed in normal storage. | |
193 | If normal storage runs low, then Emacs asks the operating system to | |
194 | allocate more memory in blocks of 1k bytes. Each block is used for one | |
195 | type of Lisp object, so symbols, cons cells, markers, etc.@: are | |
196 | segregated in distinct blocks in memory. (Vectors, buffers and certain | |
197 | other editing types, which are fairly large, are allocated in individual | |
198 | blocks, one per object, while strings are packed into blocks of 8k | |
199 | bytes.) | |
200 | ||
201 | It is quite common to use some storage for a while, then release it | |
202 | by, for example, killing a buffer or deleting the last pointer to an | |
203 | object. Emacs provides a @dfn{garbage collector} to reclaim this | |
204 | abandoned storage. (This name is traditional, but ``garbage recycler'' | |
205 | might be a more intuitive metaphor for this facility.) | |
206 | ||
207 | The garbage collector operates by scanning all the objects that have | |
208 | been allocated and marking those that are still accessible to Lisp | |
209 | programs. To begin with, all the symbols, their values and associated | |
210 | function definitions, and any data presently on the stack, are | |
211 | accessible. Any objects which can be reached indirectly through other | |
212 | accessible objects are also accessible. | |
213 | ||
214 | When this is finished, all inaccessible objects are garbage. No | |
215 | matter what the Lisp program or the user does, it is impossible to refer | |
216 | to them, since there is no longer a way to reach them. Their | |
217 | space might as well be reused, since no one will notice. That is what | |
218 | the garbage collector arranges to do. | |
219 | ||
220 | @cindex free list | |
221 | Unused cons cells are chained together onto a @dfn{free list} for | |
222 | future allocation; likewise for symbols and markers. The accessible | |
223 | strings are compacted so they are contiguous in memory; then the rest of | |
224 | the space formerly occupied by strings is made available to the string | |
225 | creation functions. Vectors, buffers, windows and other large objects | |
226 | are individually allocated and freed using @code{malloc}. | |
227 | ||
228 | @cindex CL note---allocate more storage | |
229 | @quotation | |
230 | @b{Common Lisp note:} unlike other Lisps, GNU Emacs Lisp does not | |
231 | call the garbage collector when the free list is empty. Instead, it | |
232 | simply requests the operating system to allocate more storage, and | |
233 | processing continues until @code{gc-cons-threshold} bytes have been | |
234 | used. | |
235 | ||
236 | This means that you can make sure that the garbage collector will not | |
237 | run during a certain portion of a Lisp program by calling the garbage | |
238 | collector explicitly just before it (provided that portion of the | |
239 | program does not use so much space as to force a second garbage | |
240 | collection). | |
241 | @end quotation | |
242 | ||
243 | @deffn Command garbage-collect | |
244 | This command runs a garbage collection, and returns information on | |
245 | the amount of space in use. (Garbage collection can also occur | |
246 | spontaneously if you use more than @code{gc-cons-threshold} bytes of | |
247 | Lisp data since the previous garbage collection.) | |
248 | ||
249 | @code{garbage-collect} returns a list containing the following | |
250 | information: | |
251 | ||
252 | @smallexample | |
253 | @group | |
254 | ((@var{used-conses} . @var{free-conses}) | |
255 | (@var{used-syms} . @var{free-syms}) | |
256 | (@var{used-markers} . @var{free-markers}) | |
257 | @var{used-string-chars} | |
258 | @var{used-vector-slots} | |
259 | (@var{used-floats} . @var{free-floats})) | |
260 | ||
261 | (garbage-collect) | |
262 | @result{} ((3435 . 2332) (1688 . 0) | |
263 | (57 . 417) 24510 3839 (4 . 1)) | |
264 | @end group | |
265 | @end smallexample | |
266 | ||
267 | Here is a table explaining each element: | |
268 | ||
269 | @table @var | |
270 | @item used-conses | |
271 | The number of cons cells in use. | |
272 | ||
273 | @item free-conses | |
274 | The number of cons cells for which space has been obtained from the | |
275 | operating system, but that are not currently being used. | |
276 | ||
277 | @item used-syms | |
278 | The number of symbols in use. | |
279 | ||
280 | @item free-syms | |
281 | The number of symbols for which space has been obtained from the | |
282 | operating system, but that are not currently being used. | |
283 | ||
284 | @item used-markers | |
285 | The number of markers in use. | |
286 | ||
287 | @item free-markers | |
288 | The number of markers for which space has been obtained from the | |
289 | operating system, but that are not currently being used. | |
290 | ||
291 | @item used-string-chars | |
292 | The total size of all strings, in characters. | |
293 | ||
294 | @item used-vector-slots | |
295 | The total number of elements of existing vectors. | |
296 | ||
297 | @item used-floats | |
298 | @c Emacs 19 feature | |
299 | The number of floats in use. | |
300 | ||
301 | @item free-floats | |
302 | @c Emacs 19 feature | |
303 | The number of floats for which space has been obtained from the | |
304 | operating system, but that are not currently being used. | |
305 | @end table | |
306 | @end deffn | |
307 | ||
308 | @defopt gc-cons-threshold | |
309 | The value of this variable is the number of bytes of storage that must | |
310 | be allocated for Lisp objects after one garbage collection in order to | |
311 | request another garbage collection. A cons cell counts as eight bytes, | |
312 | a string as one byte per character plus a few bytes of overhead, and so | |
313 | on. (Space allocated to the contents of buffers does not count.) Note | |
314 | that the new garbage collection does not happen immediately when the | |
315 | threshold is exhausted, but only the next time the Lisp evaluator is | |
316 | called. | |
317 | ||
318 | The initial threshold value is 100,000. If you specify a larger | |
319 | value, garbage collection will happen less often. This reduces the | |
320 | amount of time spent garbage collecting, but increases total memory use. | |
321 | You may want to do this when running a program which creates lots of | |
322 | Lisp data. | |
323 | ||
324 | You can make collections more frequent by specifying a smaller value, | |
325 | down to 10,000. A value less than 10,000 will remain in effect only | |
326 | until the subsequent garbage collection, at which time | |
327 | @code{garbage-collect} will set the threshold back to 10,000. | |
328 | @end defopt | |
329 | ||
330 | @c Emacs 19 feature | |
331 | @defun memory-limit | |
332 | This function returns the address of the last byte Emacs has allocated, | |
333 | divided by 1024. We divide the value by 1024 to make sure it fits in a | |
334 | Lisp integer. | |
335 | ||
336 | You can use this to get a general idea of how your actions affect the | |
337 | memory usage. | |
338 | @end defun | |
339 | ||
340 | @node Writing Emacs Primitives, Object Internals, Garbage Collection, GNU Emacs Internals | |
341 | @appendixsec Writing Emacs Primitives | |
342 | @cindex primitive function internals | |
343 | ||
344 | Lisp primitives are Lisp functions implemented in C. The details of | |
345 | interfacing the C function so that Lisp can call it are handled by a few | |
346 | C macros. The only way to really understand how to write new C code is | |
347 | to read the source, but we can explain some things here. | |
348 | ||
349 | An example of a special form is the definition of @code{or}, from | |
350 | @file{eval.c}. (An ordinary function would have the same general | |
351 | appearance.) | |
352 | ||
353 | @cindex garbage collection protection | |
354 | @smallexample | |
355 | @group | |
356 | DEFUN ("or", For, Sor, 0, UNEVALLED, 0, | |
357 | "Eval args until one of them yields non-NIL, then return that value.\n\ | |
358 | The remaining args are not evalled at all.\n\ | |
359 | @end group | |
360 | @group | |
361 | If all args return NIL, return NIL.") | |
362 | (args) | |
363 | Lisp_Object args; | |
364 | @{ | |
365 | register Lisp_Object val; | |
366 | Lisp_Object args_left; | |
367 | struct gcpro gcpro1; | |
368 | @end group | |
369 | ||
370 | @group | |
371 | if (NULL(args)) | |
372 | return Qnil; | |
373 | ||
374 | args_left = args; | |
375 | GCPRO1 (args_left); | |
376 | @end group | |
377 | ||
378 | @group | |
379 | do | |
380 | @{ | |
381 | val = Feval (Fcar (args_left)); | |
382 | if (!NULL (val)) | |
383 | break; | |
384 | args_left = Fcdr (args_left); | |
385 | @} | |
386 | while (!NULL(args_left)); | |
387 | @end group | |
388 | ||
389 | @group | |
390 | UNGCPRO; | |
391 | return val; | |
392 | @} | |
393 | @end group | |
394 | @end smallexample | |
395 | ||
396 | Let's start with a precise explanation of the arguments to the | |
397 | @code{DEFUN} macro. Here are the general names for them: | |
398 | ||
399 | @example | |
400 | DEFUN (@var{lname}, @var{fname}, @var{sname}, @var{min}, @var{max}, @var{interactive}, @var{doc}) | |
401 | @end example | |
402 | ||
403 | @table @var | |
404 | @item lname | |
405 | This is the name of the Lisp symbol to define with this | |
406 | function; in the example above, it is @code{or}. | |
407 | ||
408 | @item fname | |
409 | This is the C function name for this function. This is | |
410 | the name that is used in C code for calling the function. The name is, | |
411 | by convention, @samp{F} prepended to the Lisp name, with all dashes | |
412 | (@samp{-}) in the Lisp name changed to underscores. Thus, to call this | |
413 | function from C code, call @code{For}. Remember that the arguments must | |
414 | be of type @code{Lisp_Object}; various macros and functions for creating | |
415 | values of type @code{Lisp_Object} are declared in the file | |
416 | @file{lisp.h}. | |
417 | ||
418 | @item sname | |
419 | This is a C variable name to use for a structure that holds the data for | |
420 | the subr object that represents the function in Lisp. This structure | |
421 | conveys the Lisp symbol name to the initialization routine that will | |
422 | create the symbol and store the subr object as its definition. By | |
423 | convention, this name is always @var{fname} with @samp{F} replaced with | |
424 | @samp{S}. | |
425 | ||
426 | @item min | |
427 | This is the minimum number of arguments that the function requires. For | |
428 | @code{or}, no arguments are required. | |
429 | ||
430 | @item max | |
431 | This is the maximum number of arguments that the function accepts. | |
432 | Alternatively, it can be @code{UNEVALLED}, indicating a special form | |
433 | that receives unevaluated arguments. A function with the equivalent of | |
434 | an @code{&rest} argument would have @code{MANY} in this position. Both | |
435 | @code{UNEVALLED} and @code{MANY} are macros. This argument must be one | |
436 | of these macros or a number at least as large as @var{min}. It may not | |
437 | be greater than six. | |
438 | ||
439 | @item interactive | |
440 | This is an interactive specification, a string such as might be used as | |
441 | the argument of @code{interactive} in a Lisp function. In the case of | |
442 | @code{or}, it is 0 (a null pointer), indicating that @code{or} cannot be | |
443 | called interactively. A value of @code{""} indicates an interactive | |
444 | function taking no arguments. | |
445 | ||
446 | @item doc | |
447 | This is the documentation string. It is written just like a | |
448 | documentation string for a function defined in Lisp, except you must | |
449 | write @samp{\n\} at the end of each line. In particular, the first line | |
450 | should be a single sentence. | |
451 | @end table | |
452 | ||
453 | After the call to the @code{DEFUN} macro, you must write the list | |
454 | of argument names that every C function must have, followed by | |
455 | ordinary C declarations for them. Normally, all the arguments must | |
456 | be declared as @code{Lisp_Object}. If the function has no upper limit | |
457 | on the number of arguments in Lisp, then in C it receives two arguments: | |
458 | the number of Lisp arguments, and the address of a block containing their | |
459 | values. These have types @code{int} and @w{@code{Lisp_Object *}}. | |
460 | ||
461 | Within the function @code{For} itself, note the use of the macros | |
462 | @code{GCPRO1} and @code{UNGCPRO}. @code{GCPRO1} is used to ``protect'' | |
463 | a variable from garbage collection---to inform the garbage collector that | |
464 | it must look in that variable and regard its contents as an accessible | |
465 | object. This is necessary whenever you call @code{Feval} or anything | |
466 | that can directly or indirectly call @code{Feval}. At such a time, any | |
467 | Lisp object that you intend to refer to again must be protected somehow. | |
468 | @code{UNGCPRO} cancels the protection of the variables that are | |
469 | protected in the current function. It is necessary to do this explicitly. | |
470 | ||
471 | For most data types, it suffices to know that one pointer to the | |
472 | object is protected; as long as the object is not recycled, all pointers | |
473 | to it remain valid. This is not so for strings, because the garbage | |
474 | collector can move them. When a string is moved, any pointers to it | |
475 | that the garbage collector does not know about will not be properly | |
476 | relocated. Therefore, all pointers to strings must be protected across | |
477 | any point where garbage collection may be possible. | |
478 | ||
479 | The macro @code{GCPRO1} protects just one local variable. If you | |
480 | want to protect two, use @code{GCPRO2} instead; repeating @code{GCPRO1} | |
481 | will not work. There are also @code{GCPRO3} and @code{GCPRO4}. | |
482 | ||
483 | In addition to using these macros, you must declare the local | |
484 | variables such as @code{gcpro1} which they implicitly use. If you | |
485 | protect two variables, with @code{GCPRO2}, you must declare | |
486 | @code{gcpro1} and @code{gcpro2}, as it uses them both. Alas, we can't | |
487 | explain all the tricky details here. | |
488 | ||
489 | Defining the C function is not enough; you must also create the | |
490 | Lisp symbol for the primitive and store a suitable subr object | |
491 | in its function cell. This is done by adding code to an initialization | |
492 | routine. The code looks like this: | |
493 | ||
494 | @example | |
495 | defsubr (&@var{subr-structure-name}); | |
496 | @end example | |
497 | ||
498 | @noindent | |
499 | @var{subr-structure-name} is the name you used as the third argument to | |
500 | @code{DEFUN}. | |
501 | ||
502 | If you are adding a primitive to a file that already has Lisp | |
503 | primitives defined in it, find the function (near the end of the file) | |
504 | named @code{syms_of_@var{something}}, and add that function call to it. | |
505 | If the file doesn't have this function, or if you create a new file, add | |
506 | to it a @code{syms_of_@var{filename}} (e.g., @code{syms_of_myfile}). | |
507 | Then find the spot in @file{emacs.c} where all of these functions are | |
508 | called, and add a call to @code{syms_of_@var{filename}} there. | |
509 | ||
510 | This function @code{syms_of_@var{filename}} is also the place to | |
511 | define any C variables which are to be visible as Lisp variables. | |
512 | @code{DEFVAR_LISP} is used to make a C variable of type | |
513 | @code{Lisp_Object} visible in Lisp. @code{DEFVAR_INT} is used to make a | |
514 | C variable of type @code{int} visible in Lisp with a value that is an | |
515 | integer. | |
516 | ||
517 | Here is another function, with more complicated arguments. This comes | |
518 | from the code for the X Window System, and it demonstrates the use of | |
519 | macros and functions to manipulate Lisp objects. | |
520 | ||
521 | @smallexample | |
522 | @group | |
523 | DEFUN ("coordinates-in-window-p", Fcoordinates_in_window_p, | |
524 | Scoordinates_in_window_p, 2, 2, | |
525 | "xSpecify coordinate pair: \nXExpression which evals to window: ", | |
526 | "Return non-nil if POSITIONS is in WINDOW.\n\ | |
527 | \(POSITIONS is a list, (SCREEN-X SCREEN-Y)\)\n\ | |
528 | @end group | |
529 | @group | |
530 | Returned value is list of positions expressed\n\ | |
531 | relative to window upper left corner.") | |
532 | (coordinate, window) | |
533 | register Lisp_Object coordinate, window; | |
534 | @{ | |
535 | register Lisp_Object xcoord, ycoord; | |
536 | @end group | |
537 | ||
538 | @group | |
539 | if (!CONSP (coordinate)) wrong_type_argument (Qlistp, coordinate); | |
540 | CHECK_WINDOW (window, 2); | |
541 | xcoord = Fcar (coordinate); | |
542 | ycoord = Fcar (Fcdr (coordinate)); | |
543 | CHECK_NUMBER (xcoord, 0); | |
544 | CHECK_NUMBER (ycoord, 1); | |
545 | @end group | |
546 | @group | |
547 | if ((XINT (xcoord) < XINT (XWINDOW (window)->left)) | |
548 | || (XINT (xcoord) >= (XINT (XWINDOW (window)->left) | |
549 | + XINT (XWINDOW (window)->width)))) | |
550 | @{ | |
551 | return Qnil; | |
552 | @} | |
553 | XFASTINT (xcoord) -= XFASTINT (XWINDOW (window)->left); | |
554 | @end group | |
555 | @group | |
556 | if (XINT (ycoord) == (screen_height - 1)) | |
557 | return Qnil; | |
558 | @end group | |
559 | @group | |
560 | if ((XINT (ycoord) < XINT (XWINDOW (window)->top)) | |
561 | || (XINT (ycoord) >= (XINT (XWINDOW (window)->top) | |
562 | + XINT (XWINDOW (window)->height)) - 1)) | |
563 | @{ | |
564 | return Qnil; | |
565 | @} | |
566 | @end group | |
567 | @group | |
568 | XFASTINT (ycoord) -= XFASTINT (XWINDOW (window)->top); | |
569 | return (Fcons (xcoord, Fcons (ycoord, Qnil))); | |
570 | @} | |
571 | @end group | |
572 | @end smallexample | |
573 | ||
574 | Note that you cannot directly call functions defined in Lisp as, for | |
575 | example, the primitive function @code{Fcons} is called above. You must | |
576 | create the appropriate Lisp form, protect everything from garbage | |
577 | collection, and @code{Feval} the form, as was done in @code{For} above. | |
578 | ||
579 | @file{eval.c} is a very good file to look through for examples; | |
580 | @file{lisp.h} contains the definitions for some important macros and | |
581 | functions. | |
582 | ||
583 | @node Object Internals, , Writing Emacs Primitives, GNU Emacs Internals | |
584 | @appendixsec Object Internals | |
585 | @cindex object internals | |
586 | ||
587 | GNU Emacs Lisp manipulates many different types of data. The actual | |
588 | data are stored in a heap and the only access that programs have to it is | |
589 | through pointers. Pointers are thirty-two bits wide in most | |
590 | implementations. Depending on the operating system and type of machine | |
591 | for which you compile Emacs, twenty-four to twenty-six bits are used to | |
592 | address the object, and the remaining six to eight bits are used for a | |
593 | tag that identifies the object's type. | |
594 | ||
595 | Because all access to data is through tagged pointers, it is always | |
596 | possible to determine the type of any object. This allows variables to | |
597 | be untyped, and the values assigned to them to be changed without regard | |
598 | to type. Function arguments also can be of any type; if you want a | |
599 | function to accept only a certain type of argument, you must check the | |
600 | type explicitly using a suitable predicate (@pxref{Type Predicates}). | |
601 | @cindex type checking internals | |
602 | ||
603 | @menu | |
604 | * Buffer Internals:: Components of a buffer structure. | |
605 | * Window Internals:: Components of a window structure. | |
606 | * Process Internals:: Components of a process structure. | |
607 | @end menu | |
608 | ||
609 | @node Buffer Internals, Window Internals, Object Internals, Object Internals | |
610 | @appendixsubsec Buffer Internals | |
611 | @cindex internals, of buffer | |
612 | @cindex buffer internals | |
613 | ||
614 | Buffers contain fields not directly accessible by the Lisp programmer. | |
615 | We describe them here, naming them by the names used in the C code. | |
616 | Many are accessible indirectly in Lisp programs via Lisp primitives. | |
617 | ||
618 | @table @code | |
619 | @item name | |
620 | The buffer name is a string which names the buffer. It is guaranteed to | |
621 | be unique. @xref{Buffer Names}. | |
622 | ||
623 | @item save_modified | |
624 | This field contains the time when the buffer was last saved, as an integer. | |
625 | @xref{Buffer Modification}. | |
626 | ||
627 | @item modtime | |
628 | This field contains the modification time of the visited file. It is | |
629 | set when the file is written or read. Every time the buffer is written | |
630 | to the file, this field is compared to the modification time of the | |
631 | file. @xref{Buffer Modification}. | |
632 | ||
633 | @item auto_save_modified | |
634 | This field contains the time when the buffer was last auto-saved. | |
635 | ||
636 | @item last_window_start | |
637 | This field contains the @code{window-start} position in the buffer as of | |
638 | the last time the buffer was displayed in a window. | |
639 | ||
640 | @item undodata | |
641 | This field points to the buffer's undo stack. @xref{Undo}. | |
642 | ||
643 | @item syntax_table_v | |
644 | This field contains the syntax table for the buffer. @xref{Syntax Tables}. | |
645 | ||
646 | @item downcase_table | |
647 | This field contains the conversion table for converting text to lower case. | |
648 | @xref{Case Table}. | |
649 | ||
650 | @item upcase_table | |
651 | This field contains the conversion table for converting text to upper case. | |
652 | @xref{Case Table}. | |
653 | ||
654 | @item case_canon_table | |
655 | This field contains the conversion table for canonicalizing text for | |
656 | case-folding search. @xref{Case Table}. | |
657 | ||
658 | @item case_eqv_table | |
659 | This field contains the equivalence table for case-folding search. | |
660 | @xref{Case Table}. | |
661 | ||
662 | @item display_table | |
663 | This field contains the buffer's display table, or @code{nil} if it doesn't | |
664 | have one. @xref{Display Tables}. | |
665 | ||
666 | @item markers | |
667 | This field contains the chain of all markers that point into the | |
668 | buffer. At each deletion or motion of the buffer gap, all of these | |
669 | markers must be checked and perhaps updated. @xref{Markers}. | |
670 | ||
671 | @item backed_up | |
672 | This field is a flag which tells whether a backup file has been made | |
673 | for the visited file of this buffer. | |
674 | ||
675 | @item mark | |
676 | This field contains the mark for the buffer. The mark is a marker, | |
677 | hence it is also included on the list @code{markers}. @xref{The Mark}. | |
678 | ||
679 | @item local_var_alist | |
680 | This field contains the association list containing all of the variables | |
681 | local in this buffer, and their values. The function | |
682 | @code{buffer-local-variables} returns a copy of this list. | |
683 | @xref{Buffer-Local Variables}. | |
684 | ||
685 | @item mode_line_format | |
686 | This field contains a Lisp object which controls how to display the mode | |
687 | line for this buffer. @xref{Mode Line Format}. | |
688 | @end table | |
689 | ||
690 | @node Window Internals, Process Internals, Buffer Internals, Object Internals | |
691 | @appendixsubsec Window Internals | |
692 | @cindex internals, of window | |
693 | @cindex window internals | |
694 | ||
695 | Windows have the following accessible fields: | |
696 | ||
697 | @table @code | |
698 | @item frame | |
699 | The frame that this window is on. | |
700 | ||
701 | @item mini_p | |
702 | Non-@code{nil} if this window is a minibuffer window. | |
703 | ||
704 | @item height | |
705 | The height of the window, measured in lines. | |
706 | ||
707 | @item width | |
708 | The width of the window, measured in columns. | |
709 | ||
710 | @item buffer | |
711 | The buffer which the window is displaying. This may change often during | |
712 | the life of the window. | |
713 | ||
714 | @item dedicated | |
715 | Non-@code{nil} if this window is dedicated to its buffer. | |
716 | ||
717 | @item start | |
718 | The position in the buffer which is the first character to be displayed | |
719 | in the window. | |
720 | ||
721 | @item pointm | |
722 | @cindex window point internals | |
723 | This is the value of point in the current buffer when this window is | |
724 | selected; when it is not selected, it retains its previous value. | |
725 | ||
726 | @item left | |
727 | This is the left-hand edge of the window, measured in columns. (The | |
728 | leftmost column on the screen is @w{column 0}.) | |
729 | ||
730 | @item top | |
731 | This is the top edge of the window, measured in lines. (The top line on | |
732 | the screen is @w{line 0}.) | |
733 | ||
734 | @item next | |
735 | This is the window that is the next in the chain of siblings. | |
736 | ||
737 | @item prev | |
738 | This is the window that is the previous in the chain of siblings. | |
739 | ||
740 | @item force_start | |
741 | This is a flag which, if non-@code{nil}, says that the window has been | |
742 | scrolled explicitly by the Lisp program. At the next redisplay, if | |
743 | point is off the screen, instead of scrolling the window to show the | |
744 | text around point, point will be moved to a location that is on the | |
745 | screen. | |
746 | ||
747 | @item hscroll | |
748 | This is the number of columns that the display in the window is scrolled | |
749 | horizontally to the left. Normally, this is 0. | |
750 | ||
751 | @item use_time | |
752 | This is the last time that the window was selected. The function | |
753 | @code{get-lru-window} uses this field. | |
754 | ||
755 | @item display_table | |
756 | The window's display table, or @code{nil} if none is specified for it. | |
757 | @end table | |
758 | ||
759 | @node Process Internals, , Window Internals, Object Internals | |
760 | @appendixsubsec Process Internals | |
761 | @cindex internals, of process | |
762 | @cindex process internals | |
763 | ||
764 | The fields of a process are: | |
765 | ||
766 | @table @code | |
767 | @item name | |
768 | A string, the name of the process. | |
769 | ||
770 | @item command | |
771 | A list containing the command arguments that were used to start this | |
772 | process. | |
773 | ||
774 | @item filter | |
775 | A function used to accept output from the process instead of a buffer, | |
776 | or @code{nil}. | |
777 | ||
778 | @item sentinel | |
779 | A function called whenever the process receives a signal, or @code{nil}. | |
780 | ||
781 | @item buffer | |
782 | The associated buffer of the process. | |
783 | ||
784 | @item pid | |
785 | An integer, the Unix process @sc{id}. | |
786 | ||
787 | @item childp | |
788 | A flag, non-@code{nil} if this is really a child process. | |
789 | It is @code{nil} for a network connection. | |
790 | ||
791 | @item flags | |
792 | A symbol indicating the state of the process. Possible values include | |
793 | @code{run}, @code{stop}, @code{closed}, etc. | |
794 | ||
795 | @item reason | |
796 | An integer, the Unix signal number that the process received that | |
797 | caused the process to terminate or stop. If the process has exited, | |
798 | then this is the exit code it specified. | |
799 | ||
800 | @item mark | |
801 | A marker indicating the position of end of last output from this process | |
802 | inserted into the buffer. This is usually the end of the buffer. | |
803 | ||
804 | @item kill_without_query | |
805 | A flag, non-@code{nil} meaning this process should not cause | |
806 | confirmation to be needed if Emacs is killed. | |
807 | @end table |