-This is ../info/internals.info, produced by makeinfo version 4.0 from
-internals/internals.texi.
+This is Info file ../../info/internals.info, produced by Makeinfo
+version 1.68 from the input file internals.texi.
INFO-DIR-SECTION XEmacs Editor
START-INFO-DIR-ENTRY
-* Internals: (internals). XEmacs Internals Manual.
+* Internals: (internals). XEmacs Internals Manual.
END-INFO-DIR-ENTRY
Copyright (C) 1992 - 1996 Ben Wing. Copyright (C) 1996, 1997 Sun
* Rules When Writing New C Code::
* A Summary of the Various XEmacs Modules::
* Allocation of Objects in XEmacs Lisp::
-* Dumping::
* Events and the Event Loop::
* Evaluation; Stack Frames; Bindings::
* Symbols and Variables::
* Specifiers::
* Menus::
* Subprocesses::
-* Interface to the X Window System::
-* Index::
+* Interface to X Windows::
+* Index:: Index including concepts, functions, variables,
+ and other terms.
+ -- The Detailed Node Listing --
---- The Detailed Node Listing ---
+Here are other nodes that are inferiors of those already listed,
+mentioned here so you can get to them in one step:
A History of Emacs
* Through Version 18:: Unification prevails.
* Lucid Emacs:: One version 19 Emacs.
* GNU Emacs 19:: The other version 19 Emacs.
-* GNU Emacs 20:: The other version 20 Emacs.
* XEmacs:: The continuation of Lucid Emacs.
Rules When Writing New C Code
* General Coding Rules::
* Writing Lisp Primitives::
* Adding Global Lisp Variables::
-* Coding for Mule::
* Techniques for XEmacs Developers::
-Coding for Mule
-
-* Character-Related Data Types::
-* Working With Character and Byte Positions::
-* Conversion to and from External Data::
-* General Guidelines for Writing Mule-Aware Code::
-* An Example of Mule-Aware Code::
-
A Summary of the Various XEmacs Modules
* Low-Level Modules::
* Allocation from Frob Blocks::
* lrecords::
* Low-level allocation::
+* Pure Space::
* Cons::
* Vector::
* Bit Vector::
* String::
* Compiled Function::
-Garbage Collection - Step by Step
-
-* Invocation::
-* garbage_collect_1::
-* mark_object::
-* gc_sweep::
-* sweep_lcrecords_1::
-* compact_string_chars::
-* sweep_strings::
-* sweep_bit_vectors_1::
-
-Dumping
-
-* Overview::
-* Data descriptions::
-* Dumping phase::
-* Reloading phase::
-
-Dumping phase
-
-* Object inventory::
-* Address allocation::
-* The header::
-* Data dumping::
-* Pointers dumping::
-
Events and the Event Loop
* Introduction to Events::
* Character Sets::
* Encodings::
* Internal Mule Encodings::
-* CCL::
Encodings
* Internal String Encoding::
* Internal Character Encoding::
-Lstreams
+The Lisp Reader and Compiler
-* Creating an Lstream:: Creating an lstream object.
-* Lstream Types:: Different sorts of things that are streamed.
-* Lstream Functions:: Functions for working with lstreams.
-* Lstream Methods:: Creating new lstream types.
+Lstreams
Consoles; Devices; Frames; Windows
* Introduction to Consoles; Devices; Frames; Windows::
* Point::
* Window Hierarchy::
-* The Window Object::
The Redisplay Mechanism
* Critical Redisplay Sections::
* Line Start Cache::
-* Redisplay Piece by Piece::
Extents
* Extent Ordering:: How extents are ordered internally.
* Format of the Extent Info:: The extent information in a buffer or string.
* Zero-Length Extents:: A weird special case.
-* Mathematics of Extent Ordering:: A rigorous foundation.
+* Mathematics of Extent Ordering:: A rigorous foundation.
* Extent Fragments:: Cached information useful for redisplay.
+Faces
+
+Glyphs
+
+Specifiers
+
+Menus
+
+Subprocesses
+
+Interface to X Windows
+
\1f
File: internals.info, Node: A History of Emacs, Next: XEmacs From the Outside, Prev: Top, Up: Top
* XEmacs:: The continuation of Lucid Emacs.
\1f
-File: internals.info, Node: Through Version 18, Next: Lucid Emacs, Prev: A History of Emacs, Up: A History of Emacs
+File: internals.info, Node: Through Version 18, Next: Lucid Emacs, Up: A History of Emacs
Through Version 18
==================
displayable representations, and XEmacs provides a function
`redisplay()' that ensures that the display of all such objects matches
their internal state. Most of the time, a standard Lisp environment is
-in a "read-eval-print" loop--i.e. "read some Lisp code, execute it, and
-print the results". XEmacs has a similar loop:
+in a "read-eval-print" loop - i.e. "read some Lisp code, execute it,
+and print the results". XEmacs has a similar loop:
* read an event
installed by the top-level event loop, is executed; this prints
out the error and continues.) Routines can also specify cleanup
code (called an "unwind-protect") that will be called when control
- exits from a block of code, no matter how that exit occurs--i.e.
+ exits from a block of code, no matter how that exit occurs - i.e.
even if a function deeply nested below it causes a non-local exit
back to the top level.
"see" the local variable you declared. This is actually
considered a bug in Emacs Lisp and in all other early dialects of
Lisp, and was corrected in Common Lisp. (In Common Lisp, you can
- still declare dynamically scoped variables if you want to--they
- are sometimes useful--but variables by default are "lexically
+ still declare dynamically scoped variables if you want to - they
+ are sometimes useful - but variables by default are "lexically
scoped" as in C.)
For those familiar with Lisp, Emacs Lisp is modelled after MacLisp,
Unfortunately, there is no perfect language. Static typing allows a
compiler to catch programmer errors and produce more efficient code, but
-makes programming more tedious and less fun. For the foreseeable
-future, an Ideal Editing and Programming Environment (and that is what
-XEmacs aspires to) will be programmable in multiple languages: high
-level ones like Lisp for user customization and prototyping, and lower
-level ones for infrastructure and industrial strength applications. If
-I had my way, XEmacs would be friendly towards the Python, Scheme, C++,
-ML, etc... communities. But there are serious technical difficulties to
+makes programming more tedious and less fun. For the forseeable future,
+an Ideal Editing and Programming Environment (and that is what XEmacs
+aspires to) will be programmable in multiple languages: high level ones
+like Lisp for user customization and prototyping, and lower level ones
+for infrastructure and industrial strength applications. If I had my
+way, XEmacs would be friendly towards the Python, Scheme, C++, ML,
+etc... communities. But there are serious technical difficulties to
achieving that goal.
The word "application" in the previous paragraph was used
would be impossible to pre-determine and pre-specify the information for
all possible configurations.
- In fact, the `s/' and `m/' files are basically _evil_, since they
+ In fact, the `s/' and `m/' files are basically *evil*, since they
contain unmaintainable platform-specific hard-coded information.
XEmacs has been moving in the direction of having all system-specific
information be determined dynamically by `configure'. Perhaps someday
features of your system) from template files. You then run `make',
which compiles the auxiliary code and programs in `lib-src/' and
`lwlib/' and the main XEmacs executable in `src/'. The result of
-compiling and linking is an executable called `temacs', which is _not_
+compiling and linking is an executable called `temacs', which is *not*
the final XEmacs executable. `temacs' by itself is not intended to
function as an editor or even display any windows on the screen, and if
you simply run it, it will exit immediately. The `Makefile' runs
When the Lisp initialization code is done, the C code enters the
event loop, and stays there for the duration of the XEmacs process.
-The code for the event loop is contained in `cmdloop.c', and is called
+The code for the event loop is contained in `keyboard.c', and is called
`Fcommand_loop_1()'. Note that this event loop could very well be
written in Lisp, and in fact a Lisp version exists; but apparently,
doing this makes XEmacs run noticeably slower.
projects / chise / xemacs-chise.git.1 / blobdiff