1 This is Info file ../../info/internals.info, produced by Makeinfo
2 version 1.68 from the input file internals.texi.
4 INFO-DIR-SECTION XEmacs Editor
6 * Internals: (internals). XEmacs Internals Manual.
9 Copyright (C) 1992 - 1996 Ben Wing. Copyright (C) 1996, 1997 Sun
10 Microsystems. Copyright (C) 1994 - 1998 Free Software Foundation.
11 Copyright (C) 1994, 1995 Board of Trustees, University of Illinois.
13 Permission is granted to make and distribute verbatim copies of this
14 manual provided the copyright notice and this permission notice are
15 preserved on all copies.
17 Permission is granted to copy and distribute modified versions of
18 this manual under the conditions for verbatim copying, provided that the
19 entire resulting derived work is distributed under the terms of a
20 permission notice identical to this one.
22 Permission is granted to copy and distribute translations of this
23 manual into another language, under the above conditions for modified
24 versions, except that this permission notice may be stated in a
25 translation approved by the Foundation.
27 Permission is granted to copy and distribute modified versions of
28 this manual under the conditions for verbatim copying, provided also
29 that the section entitled "GNU General Public License" is included
30 exactly as in the original, and provided that the entire resulting
31 derived work is distributed under the terms of a permission notice
32 identical to this one.
34 Permission is granted to copy and distribute translations of this
35 manual into another language, under the above conditions for modified
36 versions, except that the section entitled "GNU General Public License"
37 may be included in a translation approved by the Free Software
38 Foundation instead of in the original English.
41 File: internals.info, Node: The Redisplay Mechanism, Next: Extents, Prev: Consoles; Devices; Frames; Windows, Up: Top
43 The Redisplay Mechanism
44 ***********************
46 The redisplay mechanism is one of the most complicated sections of
47 XEmacs, especially from a conceptual standpoint. This is doubly so
48 because, unlike for the basic aspects of the Lisp interpreter, the
49 computer science theories of how to efficiently handle redisplay are not
52 When working with the redisplay mechanism, remember the Golden Rules
55 1. It Is Better To Be Correct Than Fast.
57 2. Thou Shalt Not Run Elisp From Within Redisplay.
59 3. It Is Better To Be Fast Than Not To Be.
63 * Critical Redisplay Sections::
65 * Redisplay Piece by Piece::
68 File: internals.info, Node: Critical Redisplay Sections, Next: Line Start Cache, Up: The Redisplay Mechanism
70 Critical Redisplay Sections
71 ===========================
73 Within this section, we are defenseless and assume that the
74 following cannot happen:
78 2. Lisp code evaluation
82 We ensure (3) by calling `hold_frame_size_changes()', which will
83 cause any pending frame size changes to get put on hold till after the
84 end of the critical section. (1) follows automatically if (2) is met.
85 #### Unfortunately, there are some places where Lisp code can be called
86 within this section. We need to remove them.
88 If `Fsignal()' is called during this critical section, we will
91 If garbage collection is called during this critical section, we
92 simply return. #### We should abort instead.
94 #### If a frame-size change does occur we should probably actually
95 be preempting redisplay.
98 File: internals.info, Node: Line Start Cache, Next: Redisplay Piece by Piece, Prev: Critical Redisplay Sections, Up: The Redisplay Mechanism
103 The traditional scrolling code in Emacs breaks in a variable height
104 world. It depends on the key assumption that the number of lines that
105 can be displayed at any given time is fixed. This led to a complete
106 separation of the scrolling code from the redisplay code. In order to
107 fully support variable height lines, the scrolling code must actually be
108 tightly integrated with redisplay. Only redisplay can determine how
109 many lines will be displayed on a screen for any given starting point.
111 What is ideally wanted is a complete list of the starting buffer
112 position for every possible display line of a buffer along with the
113 height of that display line. Maintaining such a full list would be very
114 expensive. We settle for having it include information for all areas
115 which we happen to generate anyhow (i.e. the region currently being
116 displayed) and for those areas we need to work with.
118 In order to ensure that the cache accurately represents what
119 redisplay would actually show, it is necessary to invalidate it in many
120 situations. If the buffer changes, the starting positions may no longer
121 be correct. If a face or an extent has changed then the line heights
122 may have altered. These events happen frequently enough that the cache
123 can end up being constantly disabled. With this potentially constant
124 invalidation when is the cache ever useful?
126 Even if the cache is invalidated before every single usage, it is
127 necessary. Scrolling often requires knowledge about display lines which
128 are actually above or below the visible region. The cache provides a
129 convenient light-weight method of storing this information for multiple
130 display regions. This knowledge is necessary for the scrolling code to
131 always obey the First Golden Rule of Redisplay.
133 If the cache already contains all of the information that the
134 scrolling routines happen to need so that it doesn't have to go
135 generate it, then we are able to obey the Third Golden Rule of
136 Redisplay. The first thing we do to help out the cache is to always
137 add the displayed region. This region had to be generated anyway, so
138 the cache ends up getting the information basically for free. In those
139 cases where a user is simply scrolling around viewing a buffer there is
140 a high probability that this is sufficient to always provide the needed
141 information. The second thing we can do is be smart about invalidating
144 TODO - Be smart about invalidating the cache. Potential places:
146 * Insertions at end-of-line which don't cause line-wraps do not
147 alter the starting positions of any display lines. These types of
148 buffer modifications should not invalidate the cache. This is
149 actually a large optimization for redisplay speed as well.
151 * Buffer modifications frequently only affect the display of lines
152 at and below where they occur. In these situations we should only
153 invalidate the part of the cache starting at where the
156 In case you're wondering, the Second Golden Rule of Redisplay is not
160 File: internals.info, Node: Redisplay Piece by Piece, Prev: Line Start Cache, Up: The Redisplay Mechanism
162 Redisplay Piece by Piece
163 ========================
165 As you can begin to see redisplay is complex and also not well
166 documented. Chuck no longer works on XEmacs so this section is my take
167 on the workings of redisplay.
169 Redisplay happens in three phases:
171 1. Determine desired display in area that needs redisplay.
172 Implemented by `redisplay.c'
174 2. Compare desired display with current display Implemented by
177 3. Output changes Implemented by `redisplay-output.c',
178 `redisplay-x.c', `redisplay-msw.c' and `redisplay-tty.c'
180 Steps 1 and 2 are device-independant and relatively complex. Step 3
181 is mostly device-dependent.
183 Determining the desired display
185 Display attributes are stored in `display_line' structures. Each
186 `display_line' consists of a set of `display_block''s and each
187 `display_block' contains a number of `rune''s. Generally dynarr's of
188 `display_line''s are held by each window representing the current
189 display and the desired display.
191 The `display_line' structures are tighly tied to buffers which
192 presents a problem for redisplay as this connection is bogus for the
193 modeline. Hence the `display_line' generation routines are duplicated
194 for generating the modeline. This means that the modeline display code
195 has many bugs that the standard redisplay code does not.
197 The guts of `display_line' generation are in `create_text_block',
198 which creates a single display line for the desired locale. This
199 incrementally parses the characters on the current line and generates
200 redisplay structures for each.
202 Gutter redisplay is different. Because the data to display is stored
203 in a string we cannot use `create_text_block'. Instead we use
204 `create_text_string_block' which performs the same function as
205 `create_text_block' but for strings. Many of the complexities of
206 `create_text_block' to do with cursor handling and selective display
210 File: internals.info, Node: Extents, Next: Faces, Prev: The Redisplay Mechanism, Up: Top
217 * Introduction to Extents:: Extents are ranges over text, with properties.
218 * Extent Ordering:: How extents are ordered internally.
219 * Format of the Extent Info:: The extent information in a buffer or string.
220 * Zero-Length Extents:: A weird special case.
221 * Mathematics of Extent Ordering:: A rigorous foundation.
222 * Extent Fragments:: Cached information useful for redisplay.
225 File: internals.info, Node: Introduction to Extents, Next: Extent Ordering, Up: Extents
227 Introduction to Extents
228 =======================
230 Extents are regions over a buffer, with a start and an end position
231 denoting the region of the buffer included in the extent. In addition,
232 either end can be closed or open, meaning that the endpoint is or is
233 not logically included in the extent. Insertion of a character at a
234 closed endpoint causes the character to go inside the extent; insertion
235 at an open endpoint causes the character to go outside.
237 Extent endpoints are stored using memory indices (see `insdel.c'),
238 to minimize the amount of adjusting that needs to be done when
239 characters are inserted or deleted.
241 (Formerly, extent endpoints at the gap could be either before or
242 after the gap, depending on the open/closedness of the endpoint. The
243 intent of this was to make it so that insertions would automatically go
244 inside or out of extents as necessary with no further work needing to
245 be done. It didn't work out that way, however, and just ended up
246 complexifying and buggifying all the rest of the code.)
249 File: internals.info, Node: Extent Ordering, Next: Format of the Extent Info, Prev: Introduction to Extents, Up: Extents
254 Extents are compared using memory indices. There are two orderings
255 for extents and both orders are kept current at all times. The normal
256 or "display" order is as follows:
258 Extent A is ``less than'' extent B,
259 that is, earlier in the display order,
260 if: A-start < B-start,
261 or if: A-start = B-start, and A-end > B-end
263 So if two extents begin at the same position, the larger of them is
264 the earlier one in the display order (`EXTENT_LESS' is true).
266 For the e-order, the same thing holds:
268 Extent A is ``less than'' extent B in e-order,
269 that is, later in the buffer,
271 or if: A-end = B-end, and A-start > B-start
273 So if two extents end at the same position, the smaller of them is
274 the earlier one in the e-order (`EXTENT_E_LESS' is true).
276 The display order and the e-order are complementary orders: any
277 theorem about the display order also applies to the e-order if you swap
278 all occurrences of "display order" and "e-order", "less than" and
279 "greater than", and "extent start" and "extent end".
282 File: internals.info, Node: Format of the Extent Info, Next: Zero-Length Extents, Prev: Extent Ordering, Up: Extents
284 Format of the Extent Info
285 =========================
287 An extent-info structure consists of a list of the buffer or string's
288 extents and a "stack of extents" that lists all of the extents over a
289 particular position. The stack-of-extents info is used for
290 optimization purposes - it basically caches some info that might be
291 expensive to compute. Certain otherwise hard computations are easy
292 given the stack of extents over a particular position, and if the stack
293 of extents over a nearby position is known (because it was calculated
294 at some prior point in time), it's easy to move the stack of extents to
297 Given that the stack of extents is an optimization, and given that
298 it requires memory, a string's stack of extents is wiped out each time
299 a garbage collection occurs. Therefore, any time you retrieve the
300 stack of extents, it might not be there. If you need it to be there,
301 use the `_force' version.
303 Similarly, a string may or may not have an extent_info structure.
304 (Generally it won't if there haven't been any extents added to the
305 string.) So use the `_force' version if you need the extent_info
306 structure to be there.
308 A list of extents is maintained as a double gap array: one gap array
309 is ordered by start index (the "display order") and the other is
310 ordered by end index (the "e-order"). Note that positions in an extent
311 list should logically be conceived of as referring *to* a particular
312 extent (as is the norm in programs) rather than sitting between two
313 extents. Note also that callers of these functions should not be aware
314 of the fact that the extent list is implemented as an array, except for
315 the fact that positions are integers (this should be generalized to
316 handle integers and linked list equally well).
319 File: internals.info, Node: Zero-Length Extents, Next: Mathematics of Extent Ordering, Prev: Format of the Extent Info, Up: Extents
324 Extents can be zero-length, and will end up that way if their
325 endpoints are explicitly set that way or if their detachable property
326 is nil and all the text in the extent is deleted. (The exception is
327 open-open zero-length extents, which are barred from existing because
328 there is no sensible way to define their properties. Deletion of the
329 text in an open-open extent causes it to be converted into a closed-open
330 extent.) Zero-length extents are primarily used to represent
331 annotations, and behave as follows:
333 1. Insertion at the position of a zero-length extent expands the
334 extent if both endpoints are closed; goes after the extent if it
335 is closed-open; and goes before the extent if it is open-closed.
337 2. Deletion of a character on a side of a zero-length extent whose
338 corresponding endpoint is closed causes the extent to be detached
339 if it is detachable; if the extent is not detachable or the
340 corresponding endpoint is open, the extent remains in the buffer,
343 Note that closed-open, non-detachable zero-length extents behave
344 exactly like markers and that open-closed, non-detachable zero-length
345 extents behave like the "point-type" marker in Mule.
348 File: internals.info, Node: Mathematics of Extent Ordering, Next: Extent Fragments, Prev: Zero-Length Extents, Up: Extents
350 Mathematics of Extent Ordering
351 ==============================
353 The extents in a buffer are ordered by "display order" because that
354 is that order that the redisplay mechanism needs to process them in.
355 The e-order is an auxiliary ordering used to facilitate operations over
356 extents. The operations that can be performed on the ordered list of
357 extents in a buffer are
359 1. Locate where an extent would go if inserted into the list.
361 2. Insert an extent into the list.
363 3. Remove an extent from the list.
365 4. Map over all the extents that overlap a range.
367 (4) requires being able to determine the first and last extents that
370 NOTE: "overlap" is used as follows:
372 * two ranges overlap if they have at least one point in common.
373 Whether the endpoints are open or closed makes a difference here.
375 * a point overlaps a range if the point is contained within the
376 range; this is equivalent to treating a point P as the range [P,
379 * In the case of an *extent* overlapping a point or range, the extent
380 is normally treated as having closed endpoints. This applies
381 consistently in the discussion of stacks of extents and such below.
382 Note that this definition of overlap is not necessarily consistent
383 with the extents that `map-extents' maps over, since `map-extents'
384 sometimes pays attention to whether the endpoints of an extents
385 are open or closed. But for our purposes, it greatly simplifies
386 things to treat all extents as having closed endpoints.
388 First, define >, <, <=, etc. as applied to extents to mean
389 comparison according to the display order. Comparison between an
390 extent E and an index I means comparison between E and the range [I, I].
392 Also define e>, e<, e<=, etc. to mean comparison according to the
395 For any range R, define R(0) to be the starting index of the range
396 and R(1) to be the ending index of the range.
398 For any extent E, define E(next) to be the extent directly following
399 E, and E(prev) to be the extent directly preceding E. Assume E(next)
400 and E(prev) can be determined from E in constant time. (This is
401 because we store the extent list as a doubly linked list.)
403 Similarly, define E(e-next) and E(e-prev) to be the extents directly
404 following and preceding E in the e-order.
408 Let R be a range. Let F be the first extent overlapping R. Let L
409 be the last extent overlapping R.
411 Theorem 1: R(1) lies between L and L(next), i.e. L <= R(1) < L(next).
413 This follows easily from the definition of display order. The basic
414 reason that this theorem applies is that the display order sorts by
415 increasing starting index.
417 Therefore, we can determine L just by looking at where we would
418 insert R(1) into the list, and if we know F and are moving forward over
419 extents, we can easily determine when we've hit L by comparing the
420 extent we're at to R(1).
422 Theorem 2: F(e-prev) e< [1, R(0)] e<= F.
424 This is the analog of Theorem 1, and applies because the e-order
425 sorts by increasing ending index.
427 Therefore, F can be found in the same amount of time as operation
428 (1), i.e. the time that it takes to locate where an extent would go if
429 inserted into the e-order list.
431 If the lists were stored as balanced binary trees, then operation (1)
432 would take logarithmic time, which is usually quite fast. However,
433 currently they're stored as simple doubly-linked lists, and instead we
434 do some caching to try to speed things up.
436 Define a "stack of extents" (or "SOE") as the set of extents
437 (ordered in the display order) that overlap an index I, together with
438 the SOE's "previous" extent, which is an extent that precedes I in the
439 e-order. (Hopefully there will not be very many extents between I and
440 the previous extent.)
444 Let I be an index, let S be the stack of extents on I, let F be the
445 first extent in S, and let P be S's previous extent.
447 Theorem 3: The first extent in S is the first extent that overlaps
450 Proof: Any extent that overlaps [I, J] but does not include I must
451 have a start index > I, and thus be greater than any extent in S.
453 Therefore, finding the first extent that overlaps a range R is the
454 same as finding the first extent that overlaps R(0).
456 Theorem 4: Let I2 be an index such that I2 > I, and let F2 be the
457 first extent that overlaps I2. Then, either F2 is in S or F2 is
458 greater than any extent in S.
460 Proof: If F2 does not include I then its start index is greater than
461 I and thus it is greater than any extent in S, including F. Otherwise,
462 F2 includes I and thus is in S, and thus F2 >= F.
465 File: internals.info, Node: Extent Fragments, Prev: Mathematics of Extent Ordering, Up: Extents
470 Imagine that the buffer is divided up into contiguous,
471 non-overlapping "runs" of text such that no extent starts or ends
472 within a run (extents that abut the run don't count).
474 An extent fragment is a structure that holds data about the run that
475 contains a particular buffer position (if the buffer position is at the
476 junction of two runs, the run after the position is used) - the
477 beginning and end of the run, a list of all of the extents in that run,
478 the "merged face" that results from merging all of the faces
479 corresponding to those extents, the begin and end glyphs at the
480 beginning of the run, etc. This is the information that redisplay needs
481 in order to display this run.
483 Extent fragments have to be very quick to update to a new buffer
484 position when moving linearly through the buffer. They rely on the
485 stack-of-extents code, which does the heavy-duty algorithmic work of
486 determining which extents overly a particular position.
489 File: internals.info, Node: Faces, Next: Glyphs, Prev: Extents, Up: Top
497 File: internals.info, Node: Glyphs, Next: Specifiers, Prev: Faces, Up: Top
502 Glyphs are graphical elements that can be displayed in XEmacs
503 buffers or gutters. We use the term graphical element here in the
504 broadest possible sense since glyphs can be as mundane as text to as
505 arcane as a native tab widget.
507 In XEmacs, glyphs represent the uninstantiated state of graphical
508 elements, i.e. they hold all the information necessary to produce an
509 image on-screen but the image does not exist at this stage.
511 Glyphs are lazily instantiated by calling one of the glyph
512 functions. This usually occurs within redisplay when `Fglyph_height' is
513 called. Instantiation causes an image-instance to be created and
514 cached. This cache is on a device basis for all glyphs except
515 glyph-widgets, and on a window basis for glyph widgets. The caching is
516 done by `image_instantiate' and is necessary because it is generally
517 possible to display an image-instance in multiple domains. For instance
518 if we create a Pixmap, we can actually display this on multiple windows
519 - even though we only need a single Pixmap instance to do this. If
520 caching wasn't done then it would be necessary to create
521 image-instances for every displayable occurrance of a glyph - and every
522 usage - and this would be extremely memory and cpu intensive.
524 Widget-glyphs (a.k.a native widgets) are not cached in this way.
525 This is because widget-glyph image-instances on screen are toolkit
526 windows, and thus cannot be reused in multiple XEmacs domains. Thus
527 widget-glyphs are cached on a window basis.
529 Any action on a glyph first consults the cache before actually
530 instantiating a widget.
532 Widget-Glyphs in the MS-WIndows Environment
533 ===========================================
537 Widget-Glyphs in the X Environment
538 ==================================
540 Widget-glyphs under X make heavy use of lwlib for manipulating the
541 native toolkit objects. This is primarily so that different toolkits can
542 be supported for widget-glyphs, just as they are supported for features
543 such as menubars etc.
545 Lwlib is extremely poorly documented and quite hairy so here is my
546 understanding of what goes on.
548 Lwlib maintains a set of widget_instances which mirror the
549 hierarchical state of Xt widgets. I think this is so that widgets can
550 be updated and manipulated generically by the lwlib library. For
551 instance update_one_widget_instance can cope with multiple types of
552 widget and multiple types of toolkit. Each element in the widget
553 hierarchy is updated from its corresponding widget_instance by walking
554 the widget_instance tree recursively.
556 This has desirable properties such as lw_modify_all_widgets which is
557 called from glyphs-x.c and updates all the properties of a widget
558 without having to know what the widget is or what toolkit it is from.
559 Unfortunately this also has hairy properrties such as making the lwlib
560 code quite complex. And of course lwlib has to know at some level what
561 the widget is and how to set its properties.
564 File: internals.info, Node: Specifiers, Next: Menus, Prev: Glyphs, Up: Top
572 File: internals.info, Node: Menus, Next: Subprocesses, Prev: Specifiers, Up: Top
577 A menu is set by setting the value of the variable `current-menubar'
578 (which may be buffer-local) and then calling `set-menubar-dirty-flag'
579 to signal a change. This will cause the menu to be redrawn at the next
580 redisplay. The format of the data in `current-menubar' is described in
583 Internally the data in current-menubar is parsed into a tree of
584 `widget_value's' (defined in `lwlib.h'); this is accomplished by the
585 recursive function `menu_item_descriptor_to_widget_value()', called by
586 `compute_menubar_data()'. Such a tree is deallocated using
587 `free_widget_value()'.
589 `update_screen_menubars()' is one of the external entry points.
590 This checks to see, for each screen, if that screen's menubar needs to
591 be updated. This is the case if
593 1. `set-menubar-dirty-flag' was called since the last redisplay.
594 (This function sets the C variable menubar_has_changed.)
596 2. The buffer displayed in the screen has changed.
598 3. The screen has no menubar currently displayed.
600 `set_screen_menubar()' is called for each such screen. This
601 function calls `compute_menubar_data()' to create the tree of
602 widget_value's, then calls `lw_create_widget()',
603 `lw_modify_all_widgets()', and/or `lw_destroy_all_widgets()' to create
604 the X-Toolkit widget associated with the menu.
606 `update_psheets()', the other external entry point, actually changes
607 the menus being displayed. It uses the widgets fixed by
608 `update_screen_menubars()' and calls various X functions to ensure that
609 the menus are displayed properly.
611 The menubar widget is set up so that `pre_activate_callback()' is
612 called when the menu is first selected (i.e. mouse button goes down),
613 and `menubar_selection_callback()' is called when an item is selected.
614 `pre_activate_callback()' calls the function in activate-menubar-hook,
615 which can change the menubar (this is described in `menubar.c'). If
616 the menubar is changed, `set_screen_menubars()' is called.
617 `menubar_selection_callback()' enqueues a menu event, putting in it a
618 function to call (either `eval' or `call-interactively') and its
619 argument, which is the callback function or form given in the menu's
623 File: internals.info, Node: Subprocesses, Next: Interface to X Windows, Prev: Menus, Up: Top
628 The fields of a process are:
631 A string, the name of the process.
634 A list containing the command arguments that were used to start
638 A function used to accept output from the process instead of a
642 A function called whenever the process receives a signal, or `nil'.
645 The associated buffer of the process.
648 An integer, the Unix process ID.
651 A flag, non-`nil' if this is really a child process. It is `nil'
652 for a network connection.
655 A marker indicating the position of the end of the last output
656 from this process inserted into the buffer. This is often but not
657 always the end of the buffer.
660 If this is non-`nil', killing XEmacs while this process is still
661 running does not ask for confirmation about killing the process.
665 These two fields record 16 bits each of the process status
666 returned by the `wait' system call.
669 The process status, as `process-status' should return it.
673 If these two fields are not equal, a change in the status of the
674 process needs to be reported, either by running the sentinel or by
675 inserting a message in the process buffer.
678 Non-`nil' if communication with the subprocess uses a PTY; `nil'
682 The file descriptor for input from the process.
685 The file descriptor for output to the process.
688 The file descriptor for the terminal that the subprocess is using.
689 (On some systems, there is no need to record this, so the value is
693 The name of the terminal that the subprocess is using, or `nil' if
697 File: internals.info, Node: Interface to X Windows, Next: Index, Prev: Subprocesses, Up: Top
699 Interface to X Windows
700 **********************
705 File: internals.info, Node: Index, Prev: Interface to X Windows, Up: Top
712 * Amdahl Corporation: XEmacs.
713 * Andreessen, Marc: XEmacs.
714 * asynchronous subprocesses: Modules for Interfacing with the Operating System.
715 * Baur, Steve: XEmacs.
716 * Benson, Eric: Lucid Emacs.
717 * bridge, playing: XEmacs From the Outside.
718 * Buchholz, Martin: XEmacs.
719 * Bufbyte: Character-Related Data Types.
720 * Bufpos: Character-Related Data Types.
721 * Bytecount: Character-Related Data Types.
722 * bytecount_to_charcount: Working With Character and Byte Positions.
723 * Bytind: Character-Related Data Types.
724 * C vs. Lisp: The Lisp Language.
725 * caller-protects (GCPRO rule): Writing Lisp Primitives.
726 * case table: Modules for Other Aspects of the Lisp Interpreter and Object System.
727 * Charcount: Character-Related Data Types.
728 * charcount_to_bytecount: Working With Character and Byte Positions.
729 * charptr_emchar: Working With Character and Byte Positions.
730 * charptr_n_addr: Working With Character and Byte Positions.
731 * closer: Lstream Methods.
732 * closure: The XEmacs Object System (Abstractly Speaking).
733 * Coding for Mule: Coding for Mule.
734 * Common Lisp: The Lisp Language.
735 * compact_string_chars: compact_string_chars.
736 * conservative garbage collection: GCPROing.
737 * copy-on-write: General Coding Rules.
738 * critical redisplay sections: Critical Redisplay Sections.
739 * DEC_CHARPTR: Working With Character and Byte Positions.
740 * Devin, Matthieu: Lucid Emacs.
741 * display order of extents: Mathematics of Extent Ordering.
742 * dynamic array: Low-Level Modules.
743 * dynamic scoping: The Lisp Language.
744 * dynamic types: The Lisp Language.
745 * Emchar: Character-Related Data Types.
746 * Energize: Lucid Emacs.
748 * Epoch: Lucid Emacs.
749 * Extbyte: Character-Related Data Types.
750 * Extcount: Character-Related Data Types.
751 * extent fragment: Extent Fragments.
752 * extent mathematics: Mathematics of Extent Ordering.
753 * extent ordering: Mathematics of Extent Ordering.
754 * extents, display order: Mathematics of Extent Ordering.
755 * external widget: Modules for Interfacing with X Windows.
756 * flusher: Lstream Methods.
757 * Free Software Foundation: A History of Emacs.
758 * frob block: Introduction to Allocation.
759 * FSF: A History of Emacs.
760 * FSF Emacs <1>: GNU Emacs 20.
761 * FSF Emacs: GNU Emacs 19.
762 * garbage collection: Garbage Collection.
763 * garbage collection protection: Writing Lisp Primitives.
764 * garbage collection step by step: Garbage Collection - Step by Step.
765 * garbage collection, conservative: GCPROing.
766 * garbage collection, invocation: Invocation.
767 * garbage_collect_1: garbage_collect_1.
768 * gc_sweep: gc_sweep.
769 * GNU Emacs 19: GNU Emacs 19.
770 * GNU Emacs 20: GNU Emacs 20.
771 * Gosling, James <1>: Through Version 18.
772 * Gosling, James: The Lisp Language.
773 * Great Usenet Renaming: Through Version 18.
774 * Hackers (Steven Levy): A History of Emacs.
775 * hierarchy of windows: Window Hierarchy.
776 * history of Emacs: A History of Emacs.
777 * Illinois, University of: XEmacs.
778 * INC_CHARPTR: Working With Character and Byte Positions.
779 * interactive: Modules for Standard Editing Operations.
780 * interning: The XEmacs Object System (Abstractly Speaking).
781 * ITS (Incompatible Timesharing System): A History of Emacs.
782 * Java: The Lisp Language.
783 * Java vs. Lisp: The Lisp Language.
784 * Jones, Kyle: XEmacs.
785 * Kaplan, Simon: XEmacs.
786 * Levy, Steven: A History of Emacs.
787 * line start cache: Line Start Cache.
788 * Lisp vs. C: The Lisp Language.
789 * Lisp vs. Java: The Lisp Language.
790 * lstream: Modules for Interfacing with the File System.
791 * Lstream_close: Lstream Functions.
792 * Lstream_fgetc: Lstream Functions.
793 * Lstream_flush: Lstream Functions.
794 * Lstream_fputc: Lstream Functions.
795 * Lstream_fungetc: Lstream Functions.
796 * Lstream_getc: Lstream Functions.
797 * Lstream_new: Lstream Functions.
798 * Lstream_putc: Lstream Functions.
799 * Lstream_read: Lstream Functions.
800 * Lstream_reopen: Lstream Functions.
801 * Lstream_rewind: Lstream Functions.
802 * Lstream_set_buffering: Lstream Functions.
803 * Lstream_ungetc: Lstream Functions.
804 * Lstream_unread: Lstream Functions.
805 * Lstream_write: Lstream Functions.
806 * Lucid Emacs: Lucid Emacs.
807 * Lucid Inc.: Lucid Emacs.
808 * mark and sweep: Garbage Collection.
809 * mark method <1>: lrecords.
810 * mark method: Modules for Other Aspects of the Lisp Interpreter and Object System.
811 * mark_object: mark_object.
812 * marker: Lstream Methods.
813 * mathematics of extents: Mathematics of Extent Ordering.
814 * MAX_EMCHAR_LEN: Working With Character and Byte Positions.
815 * merging attempts: XEmacs.
816 * MIT: A History of Emacs.
817 * Mlynarik, Richard: GNU Emacs 19.
818 * MULE merged XEmacs appears: XEmacs.
819 * NAS: Modules for Interfacing with the Operating System.
820 * native sound: Modules for Interfacing with the Operating System.
821 * network connections: Modules for Interfacing with the Operating System.
822 * network sound: Modules for Interfacing with the Operating System.
823 * Niksic, Hrvoje: XEmacs.
824 * pane: Modules for the Basic Displayable Lisp Objects.
825 * permanent objects: The XEmacs Object System (Abstractly Speaking).
826 * pi, calculating: XEmacs From the Outside.
827 * pseudo_closer: Lstream Methods.
828 * pure space: Basic Lisp Modules.
829 * read syntax: The XEmacs Object System (Abstractly Speaking).
830 * read-eval-print: XEmacs From the Outside.
831 * reader: Lstream Methods.
832 * record type: How Lisp Objects Are Represented in C.
833 * Redisplay Piece by Piece: Redisplay Piece by Piece.
834 * relocating allocator: Low-Level Modules.
835 * rename to XEmacs: XEmacs.
836 * rewinder: Lstream Methods.
837 * RMS: A History of Emacs.
838 * scanner: Modules for Other Aspects of the Lisp Interpreter and Object System.
839 * scoping, dynamic: The Lisp Language.
840 * seekable_p: Lstream Methods.
841 * selections: Modules for Interfacing with X Windows.
842 * set_charptr_emchar: Working With Character and Byte Positions.
843 * Sexton, Harlan: Lucid Emacs.
844 * sound, native: Modules for Interfacing with the Operating System.
845 * sound, network: Modules for Interfacing with the Operating System.
846 * SPARCWorks: XEmacs.
847 * Stallman, Richard: A History of Emacs.
848 * subprocesses, asynchronous: Modules for Interfacing with the Operating System.
849 * subprocesses, synchronous: Modules for Interfacing with the Operating System.
850 * Sun Microsystems: XEmacs.
851 * sweep_bit_vectors_1: sweep_bit_vectors_1.
852 * sweep_lcrecords_1: sweep_lcrecords_1.
853 * sweep_strings: sweep_strings.
854 * synchronous subprocesses: Modules for Interfacing with the Operating System.
855 * taxes, doing: XEmacs From the Outside.
856 * TECO: A History of Emacs.
857 * temporary objects: The XEmacs Object System (Abstractly Speaking).
858 * Thompson, Chuck: XEmacs.
859 * types, dynamic: The Lisp Language.
860 * University of Illinois: XEmacs.
862 * window (in Emacs): Modules for the Basic Displayable Lisp Objects.
863 * window hierarchy: Window Hierarchy.
864 * window point internals: The Window Object.
866 * writer: Lstream Methods.
868 * XEmacs goes it alone: XEmacs.
869 * Zawinski, Jamie: Lucid Emacs.
projects / chise / xemacs-chise.git.1 / blob