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