• Download
• FAQ
• Mailing lists
• Documentation
• People
• How to help
• Bugs
• Links

• Mailing lists
• Status of Services
• Near Future
• History of XEmacs
• XEmacs vs. GNU Emacs
• Screenshots
• Sites Created With XEmacs
• Year 2000 Statement
• Who Wrote XEmacs?
• XEmacs Contributors
• Website

• Download
• Optional Libraries
• Installation HOWTOs
• Quickstart Package Guide
• Documentation
• Installation resources
• Releases

• XEmacs Packages
• Other Interesting Sites
• Customization Links

• FAQ
• Reporting Bugs
• Troubleshooting resources
• Debugging

• How to help
• Open Issues
• Who Wrote XEmacs?
• XEmacs Contributors
• Dev team responsibilities
• Architecting XEmacs

A Tour of XEmacs

(For more information, see http://www.xemacs.org/.)

1. What is XEmacs?

1.1 What Does It Look Like From a User's Perspective?

• User interface elements:

  • buffers (a chunk of memory holding some text)

  • frames (window system windows): containing a menubar, a toolbar, one or more windows and a minibuffer

  • minibuffer (a line at the bottom of a frame where file names, search text, etc. are inputted and messages are displayed)

  • modelines (status lines directly below each pane of text, similar to the Netscape mailreader)

  • menus

  • windows (non-overlapping divisions of a frame, often called "panes" in other applications): consisting of a text area, a modeline and optionally horizontal and/or vertical scrollbars

  • toolbars

  • scrollbars

  • dialog boxes (not completely implemented, often the minibuffer is used instead)

• file name and command auto-completion in the minibuffer

• all behaviors can be customized (even changed completely) using the XEmacs Lisp extension language

• full internationalization support under Unix, including Asian languages (and a single document can include any mixture of supported languages)

• a huge library of installable packages--for example:

  • VM (a threaded mail reader)
  • GNUS (a powerful threaded mail and news reader)
  • shell buffers (a front end to shell/command line input that provides full XEmacs editing capabilities, file name and command completion, etc.)
  • EFS (provides transparent access to FTP sites as if they were local file systems)
  • W3 (a web browser)
  • modes for all common programming languages, with automatic indentation, syntax highlighting, etc.
  • lots of games (Tetris, Minesweeper, Adventure, etc.)
  • interfaces to most debuggers
  • etc.
  
  

• behaviors of packages are extensively customizable just like for the editor itself

• will simultaneously create frames on multiple X and TTY connections

1.2 How To Get More Information About XEmacs

• web site is at http://www.xemacs.org; look at http://www.xemacs.org/FAQ/ for the FAQ

• XEmacs itself is available from http://ftp.xemacs.org/pub/xemacs/

• the newsgroup comp.emacs.xemacs is devoted to XEmacs

• the mailing lists devoted to XEmacs include

  • xemacs@xemacs.org (bidirectionally gatewayed to and from comp.emacs.xemacs)

  • xemacs-beta@xemacs.org (primary mailing list for the development process of XEmacs)

  • xemacs-nt@xemacs.org (mailing list for the development of XEmacs under Microsoft Windows)

  • xemacs-announce@xemacs.org (low volume list for announcements)

  • xemacs-patches@xemacs.org (for submitting patches to the XEmacs sources)

  • xemacs-build-reports@xemacs.org (for build reports, success or failure--please provide as much configuration information as possible)

  • 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.

• XEmacs was called Lucid Emacs up through version 19.10.

1.4 Vital Statistics

• authors

  • initially Jamie Zawinski (19.0-19.10) and Richard Mlynarik (19.4-19.9)

  • after that, Chuck Thompson (19.8-19.14) and Ben Wing (19.8-19.14 and periodically after that)

  • currently (19.15-present), Steve Baur, Hrvoje Niksic, Kyle Jones, Kirill Katsnelson, Andy Piper, Martin Buchholz, Jonathan Harris and many others

  
  

• a relatively complete installation requires around 50 MB of disk space; a lean installation requires about 20 MB

• a typical running XEmacs session involves around 10 MB of memory

• 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.)

2.2 XEmacs Lisp

A typical XEmacs Lisp function looks something like this:

(defun zap-up-to-char (arg char)
      "Kill up to ARG'th occurrence of CHAR.
      Goes backward if ARG is negative; error if CHAR not found."
      (interactive "*p\ncZap up to char: ")
      (kill-region (point) (progn
      (search-forward (char-to-string char) nil nil arg)
      (goto-char (if (> arg 0) (1- (point)) (1+ (point))))
      (point))))

Some of the reasons why XEmacs uses Lisp are:

1. 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.

2. 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.

3. 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++.

4. 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.

5. 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).

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

7. 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

• 1991: Lucid Inc. contracts the Free Software Foundation (FSF) to enhance GNU Emacs for use with Lucid's C++ development environment Energize.

• 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

• May 1993: First release of GNU Emacs version 19

• September 1993: Lucid Emacs merges with ERA; Lucid Emacs 19.8 released

• 1994: Sun wants Lucid's name to not be in the editor; marketing types choose questionable name XEmacs

• June 1994: Lucid Emacs 19.10 released; Lucid goes bankrupt; Jamie Zawinski, primary Lucid Emacs maintainer joins Netscape (is now the evangelist for mozilla.org)

• September 1994: XEmacs 19.11 released, maintainer duties passed to Chuck Thompson and Ben Wing

• 1994-1995: XEmacs splits into versions 19 and 20 to facilitate these changes; other support provided by Amdahl and INS Engineering

• September 1995: XEmacs 19.13 released; major internal rewriting by Ben Wing (internationalization, multiple device support and more powerful image support) and Chuck Thompson (redisplay)

• 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.

• Full support under Microsoft Windows 95 and NT.

• Better Options menu support, rewritten to use the standard custom interface.

• 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

• IDE editors generally provide a more GUI-centric environment and closer integration with specific compiling and debugging products.

• 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.