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 @file{keyboard.c}, and is called
+for the event loop is contained in @file{cmdloop.c}, and is called
@code{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.
@example
-crt0.c
+ecrt0.c
lastfile.c
pre-crt0.c
@end example
@example
-prefix-args.c
-@end example
-
-This is actually the source for a small, self-contained program
-used during building.
-
-
-@example
universe.h
@end example
@section Basic Lisp Modules
@example
-emacsfns.h
lisp-disunion.h
lisp-union.h
lisp.h
@example
event-Xt.c
+event-msw.c
event-stream.c
event-tty.c
+events-mod.h
+gpmevent.c
+gpmevent.h
events.c
events.h
@end example
@example
-keyboard.c
+cmdloop.c
@end example
-@file{keyboard.c} contains functions that implement the actual editor
+@file{cmdloop.c} contains functions that implement the actual editor
command loop---i.e. the event loop that cyclically retrieves and
dispatches events. This code is also rather tricky, just like
@file{event-stream.c}.
@section Modules for the Basic Displayable Lisp Objects
@example
-device-ns.h
-device-stream.c
-device-stream.h
+console-msw.c
+console-msw.h
+console-stream.c
+console-stream.h
+console-tty.c
+console-tty.h
+console-x.c
+console-x.h
+console.c
+console.h
+@end example
+
+These modules implement the @dfn{console} Lisp object type. A console
+contains multiple display devices, but only one keyboard and mouse.
+Most of the time, a console will contain exactly one device.
+
+Consoles are the top of a lisp object inclusion hierarchy. Consoles
+contain devices, which contain frames, which contain windows.
+
+
+
+@example
+device-msw.c
device-tty.c
-device-tty.h
device-x.c
-device-x.h
device.c
device.h
@end example
@example
-frame-ns.h
+frame-msw.c
frame-tty.c
frame-x.c
-frame-x.h
frame.c
frame.h
@end example
@example
bitmaps.h
-glyphs-ns.h
+glyphs-eimage.c
+glyphs-msw.c
+glyphs-msw.h
+glyphs-widget.c
glyphs-x.c
glyphs-x.h
glyphs.c
@example
-objects-ns.h
+objects-msw.c
+objects-msw.h
objects-tty.c
objects-tty.h
objects-x.c
@example
+menubar-msw.c
+menubar-msw.h
menubar-x.c
menubar.c
+menubar.h
@end example
@example
+scrollbar-msw.c
+scrollbar-msw.h
scrollbar-x.c
scrollbar-x.h
scrollbar.c
@example
+toolbar-msw.c
toolbar-x.c
toolbar.c
toolbar.h
@end example
These modules decode GIF-format image files, for use with glyphs.
+These files were removed due to Unisys patent infringement concerns.
@example
redisplay-output.c
+redisplay-msw.c
redisplay-tty.c
redisplay-x.c
redisplay.c
Similar to other subsystems in XEmacs, lstreams are separated into
generic functions and a set of methods for the different types of
lstreams. @file{lstream.c} provides implementations of many different
-types of streams; others are provided, e.g., in @file{mule-coding.c}.
+types of streams; others are provided, e.g., in @file{file-coding.c}.
-@example
-msdos.c
-msdos.h
-@end example
-
-These modules are used for MS-DOS support, which does not work in
-XEmacs.
-
-
-
@node Modules for Interfacing with X Windows, Modules for Internationalization, Modules for Interfacing with the Operating System, A Summary of the Various XEmacs Modules
@section Modules for Interfacing with X Windows
@example
-xselect.c
+select-msw.c
+select-x.c
+select.c
+select.h
@end example
@cindex selections
mule-ccl.c
mule-charset.c
mule-charset.h
-mule-coding.c
-mule-coding.h
+file-coding.c
+file-coding.h
mule-mcpath.c
mule-mcpath.h
mule-wnnfns.c
just Asian languages (although they are generally the most complicated
to support). This code is still in beta.
-@file{mule-charset.*} and @file{mule-coding.*} provide the heart of the
+@file{mule-charset.*} and @file{file-coding.*} provide the heart of the
XEmacs MULE support. @file{mule-charset.*} implements the @dfn{charset}
Lisp object type, which encapsulates a character set (an ordered one- or
two-dimensional set of characters, such as US ASCII or JISX0208 Japanese
Kanji).
-@file{mule-coding.*} implements the @dfn{coding-system} Lisp object
+@file{file-coding.*} implements the @dfn{coding-system} Lisp object
type, which encapsulates a method of converting between different
encodings. An encoding is a representation of a stream of characters,
possibly from multiple character sets, using a stream of bytes or words,
file. To create one of these, copy an existing model and modify as
necessary.
+ @strong{Please note:} If you define an lrecord in an external
+dynamically-loaded module, you must use @code{DECLARE_EXTERNAL_LRECORD},
+@code{DEFINE_EXTERNAL_LRECORD_IMPLEMENTATION}, and
+@code{DEFINE_EXTERNAL_LRECORD_SEQUENCE_IMPLEMENTATION} instead of the
+non-EXTERNAL forms. These macros will dynamically add new type numbers
+to the global enum that records them, whereas the non-EXTERNAL forms
+assume that the programmer has already inserted the correct type numbers
+into the enum's code at compile-time.
+
The various methods in the lrecord implementation structure are:
@enumerate
tree recursively.
This has desirable properties such as lw_modify_all_widgets which is
-called from glyphs-x.c and updates all the properties of a widget
+called from @file{glyphs-x.c} and updates all the properties of a widget
without having to know what the widget is or what toolkit it is from.
Unfortunately this also has hairy properties such as making the lwlib
code quite complex. And of course lwlib has to know at some level what
projects / chise / xemacs-chise.git.1 / blobdiff