All lists are subscribed to and unsubscribed from using
standard majordomo commands.

1.3 Relations To Other Versions of Emacs

XEmacs was initially derived from a pre-alpha of GNU Emacs
from the Free Software Foundation.

XEmacs is not the same as GNU Emacs and is not developed by
the Free Software Foundation, but is kept in sync with recent
releases of GNU Emacs.

The name "XEmacs" has nothing to do with the X Window System,
and in fact version 21.0 (soon to be released), supports
Microsoft Windows as well; and all versions of XEmacs since
19.12 have included support for running in text (TTY)
mode.

supported platforms include all modern versions of Unix and
many older ones; version 21.0 (scheduled to be released
sometime in July) adds Microsoft Windows support

all of the source code to XEmacs is freely available, and is
in fact required to be so under the GNU Public
License

2. XEmacs Under the Hood

2.1 XEmacs the Operating System

Internally, XEmacs does not look like an editor but consists
primarily of just a Lisp interpreter, which is driven by a
generalized event loop and redisplay mechanism similar to what
you might find in the core of the X Window System (for
example).

The XEmacs Lisp interpreter "just happens" to have support for
some specialized objects, such as buffers, that can function
as the components of an editor.

Most of the actual editor functionality is written in Lisp and
is essentially an extension that sits on top of the XEmacs
core.

XEmacs can do very un-editorlike things; for example, try
running XEmacs using the command xemacs -batch -l
dunnet.

XEmacs can even be made to look like vi and in fact it has
been done numerous times. (The latest incarnation is called
viper and supports a number of levels of vi
compliance, allowing or disallowing various parts of XEmacs to
show through.)

The syntax is extremely regular. All function calls, all
operators and all syntactic constructs such as function
definitions, if blocks and while
blocks use the same format, which is a series of items
enclosed by parentheses.

The basic data item, a list, is also used to represent pieces
of code. This makes it very easy to pass around chunks of
code as data, which is very powerful and very useful in an
extension language.

Allocated memory is automatically reclaimed using garbage
collection. There is no need to keep track of memory and
explicitly free it as in C or C++.

XEmacs Lisp is a safe language--assuming that there are no
bugs in the Lisp interpreter, it is impossible to write Lisp
code that causes XEmacs to crash. This is also unlike C or
C++. If an error occurs, the Lisp interpreter gracefully
unwinds out of the code it has been executing and back to the
top level, and typically prints an explanatory message in the
minibuffer and then continues with the event loop.

XEmacs Lisp is completely dynamically typed, meaning that all
objects including integers and other numbers are tagged with
their type at run time. This makes it possible to write
powerful functions with less programming effort than is
required for C or C++ (which are almost entirely statically
typed) or Java (where static typing is used for simple types
like numbers and Boolean variables).

XEmacs Lisp has powerful and well designed facilities for
trapping and handling errors, exceptions and similar non-local
exits.

Lisp has a long history as a well-designed and
well-thought-out language that is designed for large and
complex tasks as well as simple ones. The latest incarnation
of Lisp is Common Lisp and XEmacs Lisp is gradually
incorporating more and more features of Common Lisp.

Many more recently designed programming languages such as Perl,
JavaScript, and Java address some but not all of these issues.
None of these languages address all of these issues, however, and
at the time that Emacs was being developed these languages were
not yet even a twinkling in the brain of their creators.

Unfortunately, despite all of the shortcomings of Perl, Java, and
JavaScript they are being developed much more actively than any
varieties of Lisp and have been used much more as Web extension
languages. Consequently, new programmers are much more likely to
be familiar with these languages than with Lisp, which makes
writing XEmacs Lisp extensions harder than it should be. For this
reason the XEmacs developers have considered writing a more
generalized scripting interface that would allow other languages
to be used to write extensions in addition to Lisp. Doing this is
a huge undertaking, however, and it may be many years before any
such system is in place.

3. History of XEmacs; Split and Merge Attempts

3.1 GNU Emacs History

1970's: Emacs begins life as a series of
editor macros for TECO

Early 1980's: Emacs rewritten in C as a
collaboration between Richard M. Stallman (RMS) and James
Gosling (the creator of Java)

1985: RMS releases GNU Emacs 16 with all
Gosling code removed

October 1986: First release of GNU Emacs 18,
supporting many different versions of Unix, but still only
running on text terminals (TTY's)

1989?-1993:Version 19, supporting the X
window system, in planning for years and years

3.2 XEmacs History

Early 1992: Major collaboration problems and
delays cause Lucid to break with the FSF

April 1992: Lucid Emacs 19.0
released

Beginning of 1993: Sun Microsystems
collaborates with University of Illinois at Urbana-Champaign
(UIUC) to produce a version of Emacs called ERA ("Emacs
rewritten again") for use with an integrated development
environment; based off of Lucid Emacs

1996: Sun cuts back on funding; Ben Wing and
Chuck Thompson leave for other projects; XEmacs lies dormant
but is revived by new maintainer Steve Baur

February 1997: XEmacs 20.0 released; first
release with international support

1997: Sun drops funding entirely, some
funding from Altrasoft

1997-1998: Steve Baur rebuilds XEmacs
development and recruits a large team of core developers based
in many countries--both coasts of the US, Canada, England,
France, Germany, England, Croatia, and Russia.

1993 to present: XEmacs borrows and
synchronizes code from GNU Emacs version 19 and 20, in the
spirit of the "open source" model of free software
development; RMS does not allow code borrowing in the other
direction due to self-imposed copyright assignment
restrictions.

3.3 Merge Attempts

Since the initial split between Lucid Emacs and GNU Emacs, many
attempts at merging the two products have been made. Both sides
agree that it would be nice if development efforts could be
consolidated, and there have been at least two major merge
discussions made over the years, each involving hundreds of email
messages exchanged between RMS and the developers of Lucid
Emacs/XEmacs. Unfortunately, in all cases talks have broken down
over irreconcilable differences, including:

Control

RMS has difficulty sharing
control of programs that he is actively working on; and
especially with Emacs, which was the first GNU program and which
he considers his "baby".

Corporate involvement

Although XEmacs is and has always
been free, it has often been funded by corporations, and RMS is
not willing to work with corporations or honor their
priorities.

Copyright assignments

Because of the copyright
assignment problems mentioned earlier, much of the XEmacs code
would have to be thrown away and rewritten so as to satisfy FSF
copyright assignment rules.

Coding philosophy differences

Most of XEmacs is
designed around the modern programming principles of data
abstraction, data hiding, and modularization, and the XEmacs
developers follow these practices. This translates into a large
amount of infrastructure and many levels of indirection and it
makes the code harder to understand if you are not familiar with
it and just look at a small part of it; however, it makes the
code infinitely more maintainable in the presence of a large and
ever changing set of developers. RMS does not like data
abstraction; from his perspective as the primary and only
consistent maintainer of GNU Emacs, data abstraction adds a
whole lot of code that apparently does nothing, and without it
code is smaller and seemingly more simple. RMS's method of
coding also greatly increases the number of interdependencies
between different parts of the code, which would normally create
an impossible maintenance headache, but is apparently not a
problem for RMS. This philosophical difference not only makes
collaboration more difficult, but it has also caused almost all
of the Lisp extension interfaces that have been added in the
last six years to be designed incompatibly--in XEmacs, a new
programming concept usually causes the creation of a new
abstract data type, whereas in GNU Emacs, the basic non-abstract
Lisp data types such as lists and vectors are reused.

4. Newest Features

4.1 Features of Note in the About-to-be-Released Version 21.0

Support for installable packages, similar to packages under
Red Hat; the idea is that many more extension packages can be
made available in an easy-to-install form, but don't need to
be part of the main distribution, and can be updated
independent of the main releases.

No limit on the amount of buffer data (previously was 256 MG
on a 32 bit machine, now can use the full 4 GB if available)
.

4.2 Features to Come in the Near Future

internationalization support under Windows

full dialog boxes

some support for the emerging Unicode internationalization
standard

better organized bug reporting process

replacement of the notoriously complex and system-specific
unexec mechanism with a general and more reliable
mechanism

many improvements that make XEmacs easier to
customize

4.3 Features Further Off in the Future

full support for Unicode

ability to dynamically link C libraries into a running
XEmacs

possible replacement of or significant revision to the aging
Lisp engine, including such modern features as multithreading,
lexical scoping, full Common Lisp support and faster byte code
execution (possibly including just-in-time
compilation)

5. Comparison to vi, IDE Editors, and GNU Emacs

5.1 Comparison to vi

vi is lean and mean, quick to start up; XEmacs is the "kitchen
sink" and slow to start up

vi is a two mode editor where you have to switch between modes
to insert text and to move around and change text, and the
same keys are used for both purposes; XEmacs is a one mode
editor, where the ASCII keys always insert themselves as text,
and commands are given using control characters

vi is an editor and only an editor, whereas XEmacs purports to
be a whole environment, almost an operating system

traditional versions of vi support editing in only one buffer
(file), one frame and one window at a time; XEmacs allows many
or all of these at a time

XEmacs is more customizable

XEmacs generally provides many more GUI elements

the editors use very different approaches and neither is
"better" than the other; I and many other people use both
depending on the circumstance

5.2 Comparison to IDE Editors

XEmacs needs a bit of work in some GUI areas (especially
dialog boxes)

IDE editors are generally not very customizable, whereas
XEmacs is almost infinitely customizable.

IDE editors generally integrate only with the tools that they
were designed to integrate with, and work only with the
languages that they were designed to work with; whereas XEmacs
is much more general.

5.3 Comparison to GNU Emacs

XEmacs provides many GUI elements that are missing or
minimalistic in GNU Emacs, such as toolbars, scrollbars, a
mousable mode line, dialog boxes, etc. There is also a more
powerful interface for programming these and other GUI
elements.

XEmacs comes with many more packages integrated, and as of the
soon-to-be-released version 21.0, a powerful, installable
package system.

Pre-built binary distributions are provided for most
platforms.

The XEmacs development process is much more "bazaar"-like than
GNU Emacs [see "The Cathedral and the Bazaar" by Eric
Raymond]--development is by a team instead of primarily by a
single person, code and submissions are more likely to be
accepted (and it is not required to sign copyright assignment
papers), there is no bias against packages that integrate with
proprietary products, etc.

XEmacs allows for simultaneous X and TTY connections--for
example, you could leave your XEmacs session running at work
and then telnet into a machine from home, and, using the
gnuclient
-nw command, open up a TTY frame in the same XEmacs
session,
using the same open buffers, session settings, etc.