+++ /dev/null
-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.
-END-INFO-DIR-ENTRY
-
- Copyright (C) 1992 - 1996 Ben Wing. Copyright (C) 1996, 1997 Sun
-Microsystems. Copyright (C) 1994 - 1998 Free Software Foundation.
-Copyright (C) 1994, 1995 Board of Trustees, University of Illinois.
-
- Permission is granted to make and distribute verbatim copies of this
-manual provided the copyright notice and this permission notice are
-preserved on all copies.
-
- Permission is granted to copy and distribute modified versions of
-this manual under the conditions for verbatim copying, provided that the
-entire resulting derived work is distributed under the terms of a
-permission notice identical to this one.
-
- Permission is granted to copy and distribute translations of this
-manual into another language, under the above conditions for modified
-versions, except that this permission notice may be stated in a
-translation approved by the Foundation.
-
- Permission is granted to copy and distribute modified versions of
-this manual under the conditions for verbatim copying, provided also
-that the section entitled "GNU General Public License" is included
-exactly as in the original, and provided that the entire resulting
-derived work is distributed under the terms of a permission notice
-identical to this one.
-
- Permission is granted to copy and distribute translations of this
-manual into another language, under the above conditions for modified
-versions, except that the section entitled "GNU General Public License"
-may be included in a translation approved by the Free Software
-Foundation instead of in the original English.
-
-\1f
-File: internals.info, Node: Top, Next: A History of Emacs, Prev: (dir), Up: (dir)
-
- This Info file contains v1.0 of the XEmacs Internals Manual.
-
-* Menu:
-
-* A History of Emacs:: Times, dates, important events.
-* XEmacs From the Outside:: A broad conceptual overview.
-* The Lisp Language:: An overview.
-* XEmacs From the Perspective of Building::
-* XEmacs From the Inside::
-* The XEmacs Object System (Abstractly Speaking)::
-* How Lisp Objects Are Represented in C::
-* Rules When Writing New C Code::
-* A Summary of the Various XEmacs Modules::
-* Allocation of Objects in XEmacs Lisp::
-* Events and the Event Loop::
-* Evaluation; Stack Frames; Bindings::
-* Symbols and Variables::
-* Buffers and Textual Representation::
-* MULE Character Sets and Encodings::
-* The Lisp Reader and Compiler::
-* Lstreams::
-* Consoles; Devices; Frames; Windows::
-* The Redisplay Mechanism::
-* Extents::
-* Faces::
-* Glyphs::
-* Specifiers::
-* Menus::
-* Subprocesses::
-* Interface to X Windows::
-* Index:: Index including concepts, functions, variables,
- and other terms.
-
- -- 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.
-* XEmacs:: The continuation of Lucid Emacs.
-
-Rules When Writing New C Code
-
-* General Coding Rules::
-* Writing Lisp Primitives::
-* Adding Global Lisp Variables::
-* Techniques for XEmacs Developers::
-
-A Summary of the Various XEmacs Modules
-
-* Low-Level Modules::
-* Basic Lisp Modules::
-* Modules for Standard Editing Operations::
-* Editor-Level Control Flow Modules::
-* Modules for the Basic Displayable Lisp Objects::
-* Modules for other Display-Related Lisp Objects::
-* Modules for the Redisplay Mechanism::
-* Modules for Interfacing with the File System::
-* Modules for Other Aspects of the Lisp Interpreter and Object System::
-* Modules for Interfacing with the Operating System::
-* Modules for Interfacing with X Windows::
-* Modules for Internationalization::
-
-Allocation of Objects in XEmacs Lisp
-
-* Introduction to Allocation::
-* Garbage Collection::
-* GCPROing::
-* Garbage Collection - Step by Step::
-* Integers and Characters::
-* Allocation from Frob Blocks::
-* lrecords::
-* Low-level allocation::
-* Pure Space::
-* Cons::
-* Vector::
-* Bit Vector::
-* Symbol::
-* Marker::
-* String::
-* Compiled Function::
-
-Events and the Event Loop
-
-* Introduction to Events::
-* Main Loop::
-* Specifics of the Event Gathering Mechanism::
-* Specifics About the Emacs Event::
-* The Event Stream Callback Routines::
-* Other Event Loop Functions::
-* Converting Events::
-* Dispatching Events; The Command Builder::
-
-Evaluation; Stack Frames; Bindings
-
-* Evaluation::
-* Dynamic Binding; The specbinding Stack; Unwind-Protects::
-* Simple Special Forms::
-* Catch and Throw::
-
-Symbols and Variables
-
-* Introduction to Symbols::
-* Obarrays::
-* Symbol Values::
-
-Buffers and Textual Representation
-
-* Introduction to Buffers:: A buffer holds a block of text such as a file.
-* The Text in a Buffer:: Representation of the text in a buffer.
-* Buffer Lists:: Keeping track of all buffers.
-* Markers and Extents:: Tagging locations within a buffer.
-* Bufbytes and Emchars:: Representation of individual characters.
-* The Buffer Object:: The Lisp object corresponding to a buffer.
-
-MULE Character Sets and Encodings
-
-* Character Sets::
-* Encodings::
-* Internal Mule Encodings::
-
-Encodings
-
-* Japanese EUC (Extended Unix Code)::
-* JIS7::
-
-Internal Mule Encodings
-
-* Internal String Encoding::
-* Internal Character Encoding::
-
-The Lisp Reader and Compiler
-
-Lstreams
-
-Consoles; Devices; Frames; Windows
-
-* Introduction to Consoles; Devices; Frames; Windows::
-* Point::
-* Window Hierarchy::
-
-The Redisplay Mechanism
-
-* Critical Redisplay Sections::
-* Line Start Cache::
-
-Extents
-
-* Introduction to Extents:: Extents are ranges over text, with properties.
-* 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.
-* 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
-
-A History of Emacs
-******************
-
- XEmacs is a powerful, customizable text editor and development
-environment. It began as Lucid Emacs, which was in turn derived from
-GNU Emacs, a program written by Richard Stallman of the Free Software
-Foundation. GNU Emacs dates back to the 1970's, and was modelled after
-a package called "Emacs", written in 1976, that was a set of macros on
-top of TECO, an old, old text editor written at MIT on the DEC PDP 10
-under one of the earliest time-sharing operating systems, ITS
-(Incompatible Timesharing System). (ITS dates back well before Unix.)
-ITS, TECO, and Emacs were products of a group of people at MIT who
-called themselves "hackers", who shared an idealistic belief system
-about the free exchange of information and were fanatical in their
-devotion to and time spent with computers. (The hacker subculture dates
-back to the late 1950's at MIT and is described in detail in Steven
-Levy's book `Hackers'. This book also includes a lot of information
-about Stallman himself and the development of Lisp, a programming
-language developed at MIT that underlies Emacs.)
-
-* Menu:
-
-* 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.
-
-\1f
-File: internals.info, Node: Through Version 18, Next: Lucid Emacs, Up: A History of Emacs
-
-Through Version 18
-==================
-
- Although the history of the early versions of GNU Emacs is unclear,
-the history is well-known from the middle of 1985. A time line is:
-
- * GNU Emacs version 15 (15.34) was released sometime in 1984 or 1985
- and shared some code with a version of Emacs written by James
- Gosling (the same James Gosling who later created the Java
- language).
-
- * GNU Emacs version 16 (first released version was 16.56) was
- released on July 15, 1985. All Gosling code was removed due to
- potential copyright problems with the code.
-
- * version 16.57: released on September 16, 1985.
-
- * versions 16.58, 16.59: released on September 17, 1985.
-
- * version 16.60: released on September 19, 1985. These later
- version 16's incorporated patches from the net, esp. for getting
- Emacs to work under System V.
-
- * version 17.36 (first official v17 release) released on December 20,
- 1985. Included a TeX-able user manual. First official unpatched
- version that worked on vanilla System V machines.
-
- * version 17.43 (second official v17 release) released on January 25,
- 1986.
-
- * version 17.45 released on January 30, 1986.
-
- * version 17.46 released on February 4, 1986.
-
- * version 17.48 released on February 10, 1986.
-
- * version 17.49 released on February 12, 1986.
-
- * version 17.55 released on March 18, 1986.
-
- * version 17.57 released on March 27, 1986.
-
- * version 17.58 released on April 4, 1986.
-
- * version 17.61 released on April 12, 1986.
-
- * version 17.63 released on May 7, 1986.
-
- * version 17.64 released on May 12, 1986.
-
- * version 18.24 (a beta version) released on October 2, 1986.
-
- * version 18.30 (a beta version) released on November 15, 1986.
-
- * version 18.31 (a beta version) released on November 23, 1986.
-
- * version 18.32 (a beta version) released on December 7, 1986.
-
- * version 18.33 (a beta version) released on December 12, 1986.
-
- * version 18.35 (a beta version) released on January 5, 1987.
-
- * version 18.36 (a beta version) released on January 21, 1987.
-
- * January 27, 1987: The Great Usenet Renaming. net.emacs is now
- comp.emacs.
-
- * version 18.37 (a beta version) released on February 12, 1987.
-
- * version 18.38 (a beta version) released on March 3, 1987.
-
- * version 18.39 (a beta version) released on March 14, 1987.
-
- * version 18.40 (a beta version) released on March 18, 1987.
-
- * version 18.41 (the first "official" release) released on March 22,
- 1987.
-
- * version 18.45 released on June 2, 1987.
-
- * version 18.46 released on June 9, 1987.
-
- * version 18.47 released on June 18, 1987.
-
- * version 18.48 released on September 3, 1987.
-
- * version 18.49 released on September 18, 1987.
-
- * version 18.50 released on February 13, 1988.
-
- * version 18.51 released on May 7, 1988.
-
- * version 18.52 released on September 1, 1988.
-
- * version 18.53 released on February 24, 1989.
-
- * version 18.54 released on April 26, 1989.
-
- * version 18.55 released on August 23, 1989. This is the earliest
- version that is still available by FTP.
-
- * version 18.56 released on January 17, 1991.
-
- * version 18.57 released late January, 1991.
-
- * version 18.58 released ?????.
-
- * version 18.59 released October 31, 1992.
-
-\1f
-File: internals.info, Node: Lucid Emacs, Next: GNU Emacs 19, Prev: Through Version 18, Up: A History of Emacs
-
-Lucid Emacs
-===========
-
- Lucid Emacs was developed by the (now-defunct) Lucid Inc., a maker of
-C++ and Lisp development environments. It began when Lucid decided they
-wanted to use Emacs as the editor and cornerstone of their C++
-development environment (called "Energize"). They needed many features
-that were not available in the existing version of GNU Emacs (version
-18.5something), in particular good and integrated support for GUI
-elements such as mouse support, multiple fonts, multiple window-system
-windows, etc. A branch of GNU Emacs called Epoch, written at the
-University of Illinois, existed that supplied many of these features;
-however, Lucid needed more than what existed in Epoch. At the time, the
-Free Software Foundation was working on version 19 of Emacs (this was
-sometime around 1991), which was planned to have similar features, and
-so Lucid decided to work with the Free Software Foundation. Their plan
-was to add features that they needed, and coordinate with the FSF so
-that the features would get included back into Emacs version 19.
-
- Delays in the release of version 19 occurred, however (resulting in
-it finally being released more than a year after what was initially
-planned), and Lucid encountered unexpected technical resistance in
-getting their changes merged back into version 19, so they decided to
-release their own version of Emacs, which became Lucid Emacs 19.0.
-
- The initial authors of Lucid Emacs were Matthieu Devin, Harlan
-Sexton, and Eric Benson, and the work was later taken over by Jamie
-Zawinski, who became "Mr. Lucid Emacs" for many releases.
-
- A time line for Lucid Emacs/XEmacs is
-
- * version 19.0 shipped with Energize 1.0, April 1992.
-
- * version 19.1 released June 4, 1992.
-
- * version 19.2 released June 19, 1992.
-
- * version 19.3 released September 9, 1992.
-
- * version 19.4 released January 21, 1993.
-
- * version 19.5 was a repackaging of 19.4 with a few bug fixes and
- shipped with Energize 2.0. Never released to the net.
-
- * version 19.6 released April 9, 1993.
-
- * version 19.7 was a repackaging of 19.6 with a few bug fixes and
- shipped with Energize 2.1. Never released to the net.
-
- * version 19.8 released September 6, 1993.
-
- * version 19.9 released January 12, 1994.
-
- * version 19.10 released May 27, 1994.
-
- * version 19.11 (first XEmacs) released September 13, 1994.
-
- * version 19.12 released June 23, 1995.
-
- * version 19.13 released September 1, 1995.
-
- * version 19.14 released June 23, 1996.
-
- * version 20.0 released February 9, 1997.
-
- * version 19.15 released March 28, 1997.
-
- * version 20.1 (not released to the net) April 15, 1997.
-
- * version 20.2 released May 16, 1997.
-
- * version 19.16 released October 31, 1997.
-
- * version 20.3 (the first stable version of XEmacs 20.x) released
- November 30, 1997. version 20.4 released February 28, 1998.
-
-\1f
-File: internals.info, Node: GNU Emacs 19, Next: GNU Emacs 20, Prev: Lucid Emacs, Up: A History of Emacs
-
-GNU Emacs 19
-============
-
- About a year after the initial release of Lucid Emacs, the FSF
-released a beta of their version of Emacs 19 (referred to here as "GNU
-Emacs"). By this time, the current version of Lucid Emacs was 19.6.
-(Strangely, the first released beta from the FSF was GNU Emacs 19.7.) A
-time line for GNU Emacs version 19 is
-
- * version 19.8 (beta) released May 27, 1993.
-
- * version 19.9 (beta) released May 27, 1993.
-
- * version 19.10 (beta) released May 30, 1993.
-
- * version 19.11 (beta) released June 1, 1993.
-
- * version 19.12 (beta) released June 2, 1993.
-
- * version 19.13 (beta) released June 8, 1993.
-
- * version 19.14 (beta) released June 17, 1993.
-
- * version 19.15 (beta) released June 19, 1993.
-
- * version 19.16 (beta) released July 6, 1993.
-
- * version 19.17 (beta) released late July, 1993.
-
- * version 19.18 (beta) released August 9, 1993.
-
- * version 19.19 (beta) released August 15, 1993.
-
- * version 19.20 (beta) released November 17, 1993.
-
- * version 19.21 (beta) released November 17, 1993.
-
- * version 19.22 (beta) released November 28, 1993.
-
- * version 19.23 (beta) released May 17, 1994.
-
- * version 19.24 (beta) released May 16, 1994.
-
- * version 19.25 (beta) released June 3, 1994.
-
- * version 19.26 (beta) released September 11, 1994.
-
- * version 19.27 (beta) released September 14, 1994.
-
- * version 19.28 (first "official" release) released November 1, 1994.
-
- * version 19.29 released June 21, 1995.
-
- * version 19.30 released November 24, 1995.
-
- * version 19.31 released May 25, 1996.
-
- * version 19.32 released July 31, 1996.
-
- * version 19.33 released August 11, 1996.
-
- * version 19.34 released August 21, 1996.
-
- * version 19.34b released September 6, 1996.
-
- In some ways, GNU Emacs 19 was better than Lucid Emacs; in some ways,
-worse. Lucid soon began incorporating features from GNU Emacs 19 into
-Lucid Emacs; the work was mostly done by Richard Mlynarik, who had been
-working on and using GNU Emacs for a long time (back as far as version
-16 or 17).
-
-\1f
-File: internals.info, Node: GNU Emacs 20, Next: XEmacs, Prev: GNU Emacs 19, Up: A History of Emacs
-
-GNU Emacs 20
-============
-
- On February 2, 1997 work began on GNU Emacs to integrate Mule. The
-first release was made in September of that year.
-
- A timeline for Emacs 20 is
-
- * version 20.1 released September 17, 1997.
-
- * version 20.2 released September 20, 1997.
-
- * version 20.3 released August 19, 1998.
-
-\1f
-File: internals.info, Node: XEmacs, Prev: GNU Emacs 20, Up: A History of Emacs
-
-XEmacs
-======
-
- Around the time that Lucid was developing Energize, Sun Microsystems
-was developing their own development environment (called "SPARCWorks")
-and also decided to use Emacs. They joined forces with the Epoch team
-at the University of Illinois and later with Lucid. The maintainer of
-the last-released version of Epoch was Marc Andreessen, but he dropped
-out and the Epoch project, headed by Simon Kaplan, lured Chuck Thompson
-away from a system administration job to become the primary Lucid Emacs
-author for Epoch and Sun. Chuck's area of specialty became the
-redisplay engine (he replaced the old Lucid Emacs redisplay engine with
-a ported version from Epoch and then later rewrote it from scratch).
-Sun also hired Ben Wing (the author of Win-Emacs, a port of Lucid Emacs
-to Microsoft Windows 3.1) in 1993, for what was initially a one-month
-contract to fix some event problems but later became a many-year
-involvement, punctuated by a six-month contract with Amdahl Corporation.
-
- In 1994, Sun and Lucid agreed to rename Lucid Emacs to XEmacs (a name
-not favorable to either company); the first release called XEmacs was
-version 19.11. In June 1994, Lucid folded and Jamie quit to work for
-the newly formed Mosaic Communications Corp., later Netscape
-Communications Corp. (co-founded by the same Marc Andreessen, who had
-quit his Epoch job to work on a graphical browser for the World Wide
-Web). Chuck then become the primary maintainer of XEmacs, and put out
-versions 19.11 through 19.14 in conjunction with Ben. For 19.12 and
-19.13, Chuck added the new redisplay and many other display improvements
-and Ben added MULE support (support for Asian and other languages) and
-redesigned most of the internal Lisp subsystems to better support the
-MULE work and the various other features being added to XEmacs. After
-19.14 Chuck retired as primary maintainer and Steve Baur stepped in.
-
- Soon after 19.13 was released, work began in earnest on the MULE
-internationalization code and the source tree was divided into two
-development paths. The MULE version was initially called 19.20, but was
-soon renamed to 20.0. In 1996 Martin Buchholz of Sun Microsystems took
-over the care and feeding of it and worked on it in parallel with the
-19.14 development that was occurring at the same time. After much work
-by Martin, it was decided to release 20.0 ahead of 19.15 in February
-1997. The source tree remained divided until 20.2 when the version 19
-source was finally retired at version 19.16.
-
- In 1997, Sun finally dropped all pretense of support for XEmacs and
-Martin Buchholz left the company in November. Since then, and mostly
-for the previous year, because Steve Baur was never paid to work on
-XEmacs, XEmacs has existed solely on the contributions of volunteers
-from the Free Software Community. Starting from 1997, Hrvoje Niksic and
-Kyle Jones have figured prominently in XEmacs development.
-
- Many attempts have been made to merge XEmacs and GNU Emacs, but they
-have consistently failed.
-
- A more detailed history is contained in the XEmacs About page.
-
-\1f
-File: internals.info, Node: XEmacs From the Outside, Next: The Lisp Language, Prev: A History of Emacs, Up: Top
-
-XEmacs From the Outside
-***********************
-
- XEmacs appears to the outside world as an editor, but it is really a
-Lisp environment. At its heart is a Lisp interpreter; it also
-"happens" to contain many specialized object types (e.g. buffers,
-windows, frames, events) that are useful for implementing an editor.
-Some of these objects (in particular windows and frames) have
-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:
-
- * read an event
-
- * dispatch the event (i.e. "do it")
-
- * redisplay
-
- Reading an event is done using the Lisp function `next-event', which
-waits for something to happen (typically, the user presses a key or
-moves the mouse) and returns an event object describing this.
-Dispatching an event is done using the Lisp function `dispatch-event',
-which looks up the event in a keymap object (a particular kind of
-object that associates an event with a Lisp function) and calls that
-function. The function "does" what the user has requested by changing
-the state of particular frame objects, buffer objects, etc. Finally,
-`redisplay()' is called, which updates the display to reflect those
-changes just made. Thus is an "editor" born.
-
- Note that you do not have to use XEmacs as an editor; you could just
-as well make it do your taxes, compute pi, play bridge, etc. You'd just
-have to write functions to do those operations in Lisp.
-
-\1f
-File: internals.info, Node: The Lisp Language, Next: XEmacs From the Perspective of Building, Prev: XEmacs From the Outside, Up: Top
-
-The Lisp Language
-*****************
-
- Lisp is a general-purpose language that is higher-level than C and in
-many ways more powerful than C. Powerful dialects of Lisp such as
-Common Lisp are probably much better languages for writing very large
-applications than is C. (Unfortunately, for many non-technical reasons
-C and its successor C++ have become the dominant languages for
-application development. These languages are both inadequate for
-extremely large applications, which is evidenced by the fact that newer,
-larger programs are becoming ever harder to write and are requiring ever
-more programmers despite great increases in C development environments;
-and by the fact that, although hardware speeds and reliability have been
-growing at an exponential rate, most software is still generally
-considered to be slow and buggy.)
-
- The new Java language holds promise as a better general-purpose
-development language than C. Java has many features in common with
-Lisp that are not shared by C (this is not a coincidence, since Java
-was designed by James Gosling, a former Lisp hacker). This will be
-discussed more later.
-
- For those used to C, here is a summary of the basic differences
-between C and Lisp:
-
- 1. Lisp has an extremely regular syntax. Every function, expression,
- and control statement is written in the form
-
- (FUNC ARG1 ARG2 ...)
-
- This is as opposed to C, which writes functions as
-
- func(ARG1, ARG2, ...)
-
- but writes expressions involving operators as (e.g.)
-
- ARG1 + ARG2
-
- and writes control statements as (e.g.)
-
- while (EXPR) { STATEMENT1; STATEMENT2; ... }
-
- Lisp equivalents of the latter two would be
-
- (+ ARG1 ARG2 ...)
-
- and
-
- (while EXPR STATEMENT1 STATEMENT2 ...)
-
- 2. Lisp is a safe language. Assuming there are no bugs in the Lisp
- interpreter/compiler, it is impossible to write a program that
- "core dumps" or otherwise causes the machine to execute an illegal
- instruction. This is very different from C, where perhaps the most
- common outcome of a bug is exactly such a crash. A corollary of
- this is that the C operation of casting a pointer is impossible
- (and unnecessary) in Lisp, and that it is impossible to access
- memory outside the bounds of an array.
-
- 3. Programs and data are written in the same form. The
- parenthesis-enclosing form described above for statements is the
- same form used for the most common data type in Lisp, the list.
- Thus, it is possible to represent any Lisp program using Lisp data
- types, and for one program to construct Lisp statements and then
- dynamically "evaluate" them, or cause them to execute.
-
- 4. All objects are "dynamically typed". This means that part of every
- object is an indication of what type it is. A Lisp program can
- manipulate an object without knowing what type it is, and can
- query an object to determine its type. This means that,
- correspondingly, variables and function parameters can hold
- objects of any type and are not normally declared as being of any
- particular type. This is opposed to the "static typing" of C,
- where variables can hold exactly one type of object and must be
- declared as such, and objects do not contain an indication of
- their type because it's implicit in the variables they are stored
- in. It is possible in C to have a variable hold different types
- of objects (e.g. through the use of `void *' pointers or
- variable-argument functions), but the type information must then be
- passed explicitly in some other fashion, leading to additional
- program complexity.
-
- 5. Allocated memory is automatically reclaimed when it is no longer
- in use. This operation is called "garbage collection" and
- involves looking through all variables to see what memory is being
- pointed to, and reclaiming any memory that is not pointed to and
- is thus "inaccessible" and out of use. This is as opposed to C,
- in which allocated memory must be explicitly reclaimed using
- `free()'. If you simply drop all pointers to memory without
- freeing it, it becomes "leaked" memory that still takes up space.
- Over a long period of time, this can cause your program to grow
- and grow until it runs out of memory.
-
- 6. Lisp has built-in facilities for handling errors and exceptions.
- In C, when an error occurs, usually either the program exits
- entirely or the routine in which the error occurs returns a value
- indicating this. If an error occurs in a deeply-nested routine,
- then every routine currently called must unwind itself normally
- and return an error value back up to the next routine. This means
- that every routine must explicitly check for an error in all the
- routines it calls; if it does not do so, unexpected and often
- random behavior results. This is an extremely common source of
- bugs in C programs. An alternative would be to do a non-local
- exit using `longjmp()', but that is often very dangerous because
- the routines that were exited past had no opportunity to clean up
- after themselves and may leave things in an inconsistent state,
- causing a crash shortly afterwards.
-
- Lisp provides mechanisms to make such non-local exits safe. When
- an error occurs, a routine simply signals that an error of a
- particular class has occurred, and a non-local exit takes place.
- Any routine can trap errors occurring in routines it calls by
- registering an error handler for some or all classes of errors.
- (If no handler is registered, a default handler, generally
- 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.
- even if a function deeply nested below it causes a non-local exit
- back to the top level.
-
- Note that this facility has appeared in some recent vintages of C,
- in particular Visual C++ and other PC compilers written for the
- Microsoft Win32 API.
-
- 7. In Emacs Lisp, local variables are "dynamically scoped". This
- means that if you declare a local variable in a particular
- function, and then call another function, that subfunction can
- "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
- scoped" as in C.)
-
- For those familiar with Lisp, Emacs Lisp is modelled after MacLisp,
-an early dialect of Lisp developed at MIT (no relation to the Macintosh
-computer). There is a Common Lisp compatibility package available for
-Emacs that provides many of the features of Common Lisp.
-
- The Java language is derived in many ways from C, and shares a
-similar syntax, but has the following features in common with Lisp (and
-different from C):
-
- 1. Java is a safe language, like Lisp.
-
- 2. Java provides garbage collection, like Lisp.
-
- 3. Java has built-in facilities for handling errors and exceptions,
- like Lisp.
-
- 4. Java has a type system that combines the best advantages of both
- static and dynamic typing. Objects (except very simple types) are
- explicitly marked with their type, as in dynamic typing; but there
- is a hierarchy of types and functions are declared to accept only
- certain types, thus providing the increased compile-time
- error-checking of static typing.
-
- The Java language also has some negative attributes:
-
- 1. Java uses the edit/compile/run model of software development. This
- makes it hard to use interactively. For example, to use Java like
- `bc' it is necessary to write a special purpose, albeit tiny,
- application. In Emacs Lisp, a calculator comes built-in without
- any effort - one can always just type an expression in the
- `*scratch*' buffer.
-
- 2. Java tries too hard to enforce, not merely enable, portability,
- making ordinary access to standard OS facilities painful. Java
- has an "agenda". I think this is why `chdir' is not part of
- standard Java, which is inexcusable.
-
- 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 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
-intentionally. XEmacs implements an API for programs written in Lisp
-that makes it a full-fledged application platform, very much like an OS
-inside the real OS.
-
-\1f
-File: internals.info, Node: XEmacs From the Perspective of Building, Next: XEmacs From the Inside, Prev: The Lisp Language, Up: Top
-
-XEmacs From the Perspective of Building
-***************************************
-
- The heart of XEmacs is the Lisp environment, which is written in C.
-This is contained in the `src/' subdirectory. Underneath `src/' are
-two subdirectories of header files: `s/' (header files for particular
-operating systems) and `m/' (header files for particular machine
-types). In practice the distinction between the two types of header
-files is blurred. These header files define or undefine certain
-preprocessor constants and macros to indicate particular
-characteristics of the associated machine or operating system. As part
-of the configure process, one `s/' file and one `m/' file is identified
-for the particular environment in which XEmacs is being built.
-
- XEmacs also contains a great deal of Lisp code. This implements the
-operations that make XEmacs useful as an editor as well as just a Lisp
-environment, and also contains many add-on packages that allow XEmacs to
-browse directories, act as a mail and Usenet news reader, compile Lisp
-code, etc. There is actually more Lisp code than C code associated with
-XEmacs, but much of the Lisp code is peripheral to the actual operation
-of the editor. The Lisp code all lies in subdirectories underneath the
-`lisp/' directory.
-
- The `lwlib/' directory contains C code that implements a generalized
-interface onto different X widget toolkits and also implements some
-widgets of its own that behave like Motif widgets but are faster, free,
-and in some cases more powerful. The code in this directory compiles
-into a library and is mostly independent from XEmacs.
-
- The `etc/' directory contains various data files associated with
-XEmacs. Some of them are actually read by XEmacs at startup; others
-merely contain useful information of various sorts.
-
- The `lib-src/' directory contains C code for various auxiliary
-programs that are used in connection with XEmacs. Some of them are used
-during the build process; others are used to perform certain functions
-that cannot conveniently be placed in the XEmacs executable (e.g. the
-`movemail' program for fetching mail out of `/var/spool/mail', which
-must be setgid to `mail' on many systems; and the `gnuclient' program,
-which allows an external script to communicate with a running XEmacs
-process).
-
- The `man/' directory contains the sources for the XEmacs
-documentation. It is mostly in a form called Texinfo, which can be
-converted into either a printed document (by passing it through TeX) or
-into on-line documentation called "info files".
-
- The `info/' directory contains the results of formatting the XEmacs
-documentation as "info files", for on-line use. These files are used
-when you enter the Info system using `C-h i' or through the Help menu.
-
- The `dynodump/' directory contains auxiliary code used to build
-XEmacs on Solaris platforms.
-
- The other directories contain various miscellaneous code and
-information that is not normally used or needed.
-
- The first step of building involves running the `configure' program
-and passing it various parameters to specify any optional features you
-want and compiler arguments and such, as described in the `INSTALL'
-file. This determines what the build environment is, chooses the
-appropriate `s/' and `m/' file, and runs a series of tests to determine
-many details about your environment, such as which library functions
-are available and exactly how they work. The reason for running these
-tests is that it allows XEmacs to be compiled on a much wider variety
-of platforms than those that the XEmacs developers happen to be
-familiar with, including various sorts of hybrid platforms. This is
-especially important now that many operating systems give you a great
-deal of control over exactly what features you want installed, and allow
-for easy upgrading of parts of a system without upgrading the rest. It
-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
-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
-we can `rm -rf src/s src/m'.
-
- When configure is done running, it generates `Makefile's and
-`GNUmakefile's and the file `src/config.h' (which describes the
-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*
-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
-`temacs' with certain options that cause it to initialize itself, read
-in a number of basic Lisp files, and then dump itself out into a new
-executable called `xemacs'. This new executable has been
-pre-initialized and contains pre-digested Lisp code that is necessary
-for the editor to function (this includes most basic editing functions,
-e.g. `kill-line', that can be defined in terms of other Lisp
-primitives; some initialization code that is called when certain
-objects, such as frames, are created; and all of the standard
-keybindings and code for the actions they result in). This executable,
-`xemacs', is the executable that you run to use the XEmacs editor.
-
- Although `temacs' is not intended to be run as an editor, it can, by
-using the incantation `temacs -batch -l loadup.el run-temacs'. This is
-useful when the dumping procedure described above is broken, or when
-using certain program debugging tools such as Purify. These tools get
-mighty confused by the tricks played by the XEmacs build process, such
-as allocation memory in one process, and freeing it in the next.
-
-\1f
-File: internals.info, Node: XEmacs From the Inside, Next: The XEmacs Object System (Abstractly Speaking), Prev: XEmacs From the Perspective of Building, Up: Top
-
-XEmacs From the Inside
-**********************
-
- Internally, XEmacs is quite complex, and can be very confusing. To
-simplify things, it can be useful to think of XEmacs as containing an
-event loop that "drives" everything, and a number of other subsystems,
-such as a Lisp engine and a redisplay mechanism. Each of these other
-subsystems exists simultaneously in XEmacs, and each has a certain
-state. The flow of control continually passes in and out of these
-different subsystems in the course of normal operation of the editor.
-
- It is important to keep in mind that, most of the time, the editor is
-"driven" by the event loop. Except during initialization and batch
-mode, all subsystems are entered directly or indirectly through the
-event loop, and ultimately, control exits out of all subsystems back up
-to the event loop. This cycle of entering a subsystem, exiting back out
-to the event loop, and starting another iteration of the event loop
-occurs once each keystroke, mouse motion, etc.
-
- If you're trying to understand a particular subsystem (other than the
-event loop), think of it as a "daemon" process or "servant" that is
-responsible for one particular aspect of a larger system, and
-periodically receives commands or environment changes that cause it to
-do something. Ultimately, these commands and environment changes are
-always triggered by the event loop. For example:
-
- * The window and frame mechanism is responsible for keeping track of
- what windows and frames exist, what buffers are in them, etc. It
- is periodically given commands (usually from the user) to make a
- change to the current window/frame state: i.e. create a new frame,
- delete a window, etc.
-
- * The buffer mechanism is responsible for keeping track of what
- buffers exist and what text is in them. It is periodically given
- commands (usually from the user) to insert or delete text, create
- a buffer, etc. When it receives a text-change command, it
- notifies the redisplay mechanism.
-
- * The redisplay mechanism is responsible for making sure that
- windows and frames are displayed correctly. It is periodically
- told (by the event loop) to actually "do its job", i.e. snoop
- around and see what the current state of the environment (mostly
- of the currently-existing windows, frames, and buffers) is, and
- make sure that that state matches what's actually displayed. It
- keeps lots and lots of information around (such as what is
- actually being displayed currently, and what the environment was
- last time it checked) so that it can minimize the work it has to
- do. It is also helped along in that whenever a relevant change to
- the environment occurs, the redisplay mechanism is told about
- this, so it has a pretty good idea of where it has to look to find
- possible changes and doesn't have to look everywhere.
-
- * The Lisp engine is responsible for executing the Lisp code in
- which most user commands are written. It is entered through a
- call to `eval' or `funcall', which occurs as a result of
- dispatching an event from the event loop. The functions it calls
- issue commands to the buffer mechanism, the window/frame
- subsystem, etc.
-
- * The Lisp allocation subsystem is responsible for keeping track of
- Lisp objects. It is given commands from the Lisp engine to
- allocate objects, garbage collect, etc.
-
- etc.
-
- The important idea here is that there are a number of independent
-subsystems each with its own responsibility and persistent state, just
-like different employees in a company, and each subsystem is
-periodically given commands from other subsystems. Commands can flow
-from any one subsystem to any other, but there is usually some sort of
-hierarchy, with all commands originating from the event subsystem.
-
- XEmacs is entered in `main()', which is in `emacs.c'. When this is
-called the first time (in a properly-invoked `temacs'), it does the
-following:
-
- 1. It does some very basic environment initializations, such as
- determining where it and its directories (e.g. `lisp/' and `etc/')
- reside and setting up signal handlers.
-
- 2. It initializes the entire Lisp interpreter.
-
- 3. It sets the initial values of many built-in variables (including
- many variables that are visible to Lisp programs), such as the
- global keymap object and the built-in faces (a face is an object
- that describes the display characteristics of text). This
- involves creating Lisp objects and thus is dependent on step (2).
-
- 4. It performs various other initializations that are relevant to the
- particular environment it is running in, such as retrieving
- environment variables, determining the current date and the user
- who is running the program, examining its standard input, creating
- any necessary file descriptors, etc.
-
- 5. At this point, the C initialization is complete. A Lisp program
- that was specified on the command line (usually `loadup.el') is
- called (temacs is normally invoked as `temacs -batch -l loadup.el
- dump'). `loadup.el' loads all of the other Lisp files that are
- needed for the operation of the editor, calls the `dump-emacs'
- function to write out `xemacs', and then kills the temacs process.
-
- When `xemacs' is then run, it only redoes steps (1) and (4) above;
-all variables already contain the values they were set to when the
-executable was dumped, and all memory that was allocated with
-`malloc()' is still around. (XEmacs knows whether it is being run as
-`xemacs' or `temacs' because it sets the global variable `initialized'
-to 1 after step (4) above.) At this point, `xemacs' calls a Lisp
-function to do any further initialization, which includes parsing the
-command-line (the C code can only do limited command-line parsing,
-which includes looking for the `-batch' and `-l' flags and a few other
-flags that it needs to know about before initialization is complete),
-creating the first frame (or "window" in standard window-system
-parlance), running the user's init file (usually the file `.emacs' in
-the user's home directory), etc. The function to do this is usually
-called `normal-top-level'; `loadup.el' tells the C code about this
-function by setting its name as the value of the Lisp variable
-`top-level'.
-
- 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 `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.
-
- Notice how much of the initialization is done in Lisp, not in C. In
-general, XEmacs tries to move as much code as is possible into Lisp.
-Code that remains in C is code that implements the Lisp interpreter
-itself, or code that needs to be very fast, or code that needs to do
-system calls or other such stuff that needs to be done in C, or code
-that needs to have access to "forbidden" structures. (One conscious
-aspect of the design of Lisp under XEmacs is a clean separation between
-the external interface to a Lisp object's functionality and its internal
-implementation. Part of this design is that Lisp programs are
-forbidden from accessing the contents of the object other than through
-using a standard API. In this respect, XEmacs Lisp is similar to
-modern Lisp dialects but differs from GNU Emacs, which tends to expose
-the implementation and allow Lisp programs to look at it directly. The
-major advantage of hiding the implementation is that it allows the
-implementation to be redesigned without affecting any Lisp programs,
-including those that might want to be "clever" by looking directly at
-the object's contents and possibly manipulating them.)
-
- Moving code into Lisp makes the code easier to debug and maintain and
-makes it much easier for people who are not XEmacs developers to
-customize XEmacs, because they can make a change with much less chance
-of obscure and unwanted interactions occurring than if they were to
-change the C code.
-
projects / chise / xemacs-chise.git.1 / blobdiff