XEmacs FAQ

This is the guide to the XEmacs Frequently Asked Questions list—a compendium of questions and answers pertaining to one of the finest programs ever written. XEmacs is much more than just a Text Editor.

This FAQ is freely redistributable. This FAQ is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

If you have a Web browser, the official hypertext version is at http://www.xemacs.org/FAQ/xemacs-faq.html

 — The Detailed Node Listing —

1 Introduction, Policy, Credits

1.0: What is XEmacs?

1.1: Getting XEmacs

1.2: Versions for Different Operating Systems

1.3: Getting Started

1.4: Getting Help

1.5: Contributing to XEmacs

1.6: Politics (XEmacs vs. GNU Emacs)

1.7: External Packages

1.8: Internationalization

2 Installation and Troubleshooting

2.0: Installation (General)

2.1: Package Installation

2.2: Unix/Mac OS X Installation (Also Relevant to Cygwin, MinGW)

2.3: Windows Installation (Windows, Cygwin, MinGW)

2.4: General Troubleshooting

2.5: Startup-Related Problems

3 Editing Functions

3.0: The Keyboard

3.1: The Mouse

3.2: Buffers, Text Editing

3.3: Text Selections

3.4: Editing Source Code

4 Display Functions

4.0: Textual Fonts and Colors

4.1: Syntax Highlighting (Font Lock)

4.2: The Modeline

4.3: The Cursor

4.4: The Menubar

4.5: The Toolbar

4.6: Scrollbars and Scrolling

4.7: The Gutter Tabs, The Progress Bar, Widgets

5 Interfacing with the Operating System and External Devices

5.0: X Window System and Resources

5.1: Microsoft Windows

5.2: Printing

5.3: Sound

5.4: Running an Interior Shell, Invoking Subprocesses

5.5: Multiple Device Support

6 Connecting to the Internet

6.0: General Mail and News

6.1: Reading Mail with VM

6.2: Reading Netnews and Mail with Gnus

6.3: FTP Access

6.4: Web Browsing with W3

7 Advanced Customization Using XEmacs Lisp

7.0: Emacs Lisp and ‘init.el’

7.1: Emacs Lisp Programming Techniques

7.2: Mathematics

8 Other External Packages

8.0: TeX

8.1: Other Unbundled Packages

8.2: Environments Built Around XEmacs

9 What the Future Holds

9.0: Changes

10 New information about old XEmacsen

10.0: XEmacs 21.1

11 Working with XEmacs source code repositories

11.0: The XEmacs repositories

11.1: Working with CVS

11.2: Working with Mercurial

1 Introduction, Policy, Credits

Learning XEmacs is a lifelong activity. Even people who have used Emacs for years keep discovering new features. Therefore this document cannot be complete. Instead it is aimed at the person who is either considering XEmacs for their own use, or has just obtained it and is wondering what to do next. It is also useful as a reference to available resources.

The previous maintainer of the FAQ was Anthony Rossini, who started it, after getting tired of hearing JWZ complain about repeatedly having to answer questions. Ben Wing then took over and did a massive update reorganizing the whole thing. At this point Anthony took back over, but then had to give it up again. Some of the other contributors to this FAQ are listed later in this document.

The previous version was converted to hypertext format, and edited by Steven L. Baur. It was converted back to texinfo by Hrvoje Niksic. The FAQ was then maintained by Andreas Kaempf, who passed it on to ChristianNybø, and then to Sandra Wambold.

The current version of the FAQ has been heavily redone by Ben Wing.

If you notice any errors or items which should be added or amended to this FAQ please send email to xemacs-beta@xemacs.org. Include ‘XEmacs FAQ’ on the Subject: line.

1.0: What is XEmacs?

1.1: Getting XEmacs

1.2: Versions for Different Operating Systems

1.3: Getting Started

1.4: Getting Help

1.5: Contributing to XEmacs

1.6: Politics (XEmacs vs. GNU Emacs)

1.7: External Packages

1.8: Internationalization

1.0: What is XEmacs?

Q1.0.1: What is XEmacs?

XEmacs is a powerful, highly customizable open source text editor and application development system, with full GUI support. It is protected under the GNU Public License and related to other versions of Emacs, in particular GNU Emacs. Its emphasis is on modern graphical user interface support and an open software development model, similar to Linux. XEmacs has an active development community numbering in the hundreds (and thousands of active beta testers on top of this), and runs on all versions of MS Windows, on Mac OS X, on Linux, and on nearly every other version of Unix in existence. Support for XEmacs has been supplied by Sun Microsystems, University of Illinois, Lucid, ETL/Electrotechnical Laboratory, Amdahl Corporation, BeOpen, and others, as well as the unpaid time of a great number of individual developers.

Q1.0.2: What is the current version of XEmacs?

XEmacs versions 21.4.* are releases made from the current stable sources. XEmacs versions 21.5.* (which will be released as 22.0) are releases made from the development sources. Check at http://www.xemacs.org for the current minor version. XEmacs versions 21.1.* were the previous stable releases, now retired.

XEmacs 20.4, released in February 1998, was the last release of v20.

XEmacs 19.16, released in November, 1997. was the last release of v19, and was also the last version without international language support.

Q1.0.3: How do you pronounce XEmacs?

The most common pronunciation is ‘Eks eemax’, ‘Eks'im&ks’ in Kirshenbaum IPA. (See http://www.kirshenbaum.net/IPA/ascii-ipa.pdf if you know the IPA already and want to know how to map from Kirshenbaum to it.)

Q1.0.4: What does XEmacs look like?

Screen snapshots are available at http://www.xemacs.org/About/Screenshots/index.html as part of the XEmacs website.

Q1.0.5: Who wrote XEmacs?

XEmacs is the result of the time and effort of many people, and the active developers have changed over time. There are two major components of the XEmacs effort – writing the code itself and providing all the support work (testing the code, releasing beta and final versions, handling patches, reading bug reports, maintaining the web site, managing the mailing lists, etc. etc.). Neither component would work without the other.

CODING

The primary code contributor over the years has been Ben Wing (active since late 1992). Between 1991 and 1995, large amounts of coding was contributed by Jamie Zawinski and Chuck Thompson. Many other people have authored major subsystems or otherwise contributed large amounts of code, including Andy Piper, Hrvoje Niksic, Jerry James, Jonathan Harris, Kyle Jones, Martin Buchholz, Michael Sperber, Olivier Galibert, Richard Mlynarik, Stig, William Perry and plenty of others.

Primary XEmacs-specific subsystems and their authors:

Objects

• - Conversion from 26-bit to 28-bit pointers and integers, lrecords, lcrecords: Richard Mlynarik, 1994
• - Conversion to 32-bit pointers and 31-bit integers: Kyle Jones, Martin Buchholz
• - Portable dumper, object descriptions: Olivier Galibert
• - KKCC (new garbage collector), ephemerons, weak boxes: Michael Sperber and students
• - Random object work (object equal and hash methods, weak lists, lcrecord lists, bit vectors, dynarr, blocktype, opaque, string resizing): Ben Wing
• - Profiling: Ben Wing
• - Some byte-compilation and hash-table improvements: Martin Buchholz
• - Bignum: Jerry James

Internationalization/Mule

• - mostly Ben Wing; many ideas for future work, Stephen Turnbull

I/O

• - Basic event/event-stream implementation: Jamie Zawinski
• - Most event work since 1994: Ben Wing
• - Asynchronous stuff (async timeouts, signals, quit-checking): Ben Wing
• - Process method abstraction, Windows process work: Kirill Katsnelson
• - Misc-user events, async timeouts, most quit-checking and signal code, most other work since 1994: Ben Wing
• - Lstreams: Ben Wing

Display

• - Redisplay mechanism: implementation, Chuck Thompson; additional work, lots of people
• - Glyphs: mostly Ben Wing
• - Specifiers: Ben Wing
• - Extents: initial implementation, someone at Lucid; rewrite, 1994, Ben Wing
• - Widgets: Andy Piper
• - JPEG/PNG/TIFF image converters: Ben Wing, William Perry, Jareth Hein, others (see comment in ‘glyphs-eimage.c’)
• - Menus: Jamie Zawinski, someone at Lucid (Lucid menus)
• - Scrollbars: Chuck Thompson, ??? (Lucid scrollbar)
• - Multi-device/device-independence work (console/device/etc methods): Ben Wing, prototype by chuck thompson
• - Faces: first implementation, Jamie Zawinski; second, chuck; third, Ben Wing
• - Fonts/colors: first implementation, Jamie Zawinski; further work, Ben Wing
• - Toolbars: implementation, chuck, much interface work, Ben Wing
• - Gutters, tabs: andy piper

Device subsystems

• - X Windows: Jamie Zawinski, Ben Wing, others
• - GTK: William Perry, Malcolm Purvis
• - MS Windows: initial implementation, Jonathan Harris; some more work, Andy Piper, Ben Wing
• - TTY: Chuck Thompson, Ben Wing
• - Cygwin: Andy Piper

Misc

• - Configure: initial porting from fsf, Chuck Thompson; conversion to autoconf 2, much rewriting, Martin Buchholz
• - Most initialization-related code: Ben Wing
• - Internals manual, much of Lisp manual: Ben Wing
• - FSF synching: initial sync with FSF 19, Richard Mlynarik, further work, Ben Wing

SUPPORT

Currently, support duties are handled by many different people.

Release managers have been

• - Stephen Turnbull (April 2001 - January 2003, March 2004 - present, 21.2.47 - 21.4.12, 21.5.2 - 21.5.7, 21.5.17 - present)
• - Vin Shelton (May 2003 - present, 21.4.13 - present)
• - Steve Youngs (July 2002 - September 2003, 21.5.8 - 21.5.16)
• - Martin Buchholz (December 1998, November 1999 - May 2001, 21.2.7 - 21.2.8, 21.2.21 - 21.2.46, 21.5.0 - 21.5.1)
• - Steve Baur (early 1997 - December 1998, February 1999 - November 1999, 19.15 - 21.2.5, 21.2.9 - 21.2.20)
• - Andy Piper (December 1998, 21.2.6)
• - Chuck Thompson (June 1994 - September 1996, 19.11 - 19.14)
• - Jamie Zawinski (April 1991 - June 1994, 19.0 - 19.10)

The recent overlapping dates are intentional, since two or three trees are maintained simultaneously at any point.

Other major support work:

• - Adrian Aichner wrote and maintains the web site.
• - Stephen Turnbull has produced many of the beta and semi-stable releases and has attempted to be the "face" of XEmacs on the newsgroups and mailing lists.
• - Steve Youngs currently produces the beta releases (???).
• - Steve Youngs, Ville Skyttä, and now Norbert Koch have taken turns maintaining the packages.
• - Vin Shelton maintains the stable releases.
• - Testing - #### Norbert, Adrian, ???

Portraits and email of some of the major developers:

• Andy Piper
  
  
• Ben Wing
  
  
• Chuck Thompson
  
  
• Hrvoje Niksic
  
  
• Jamie Zawinski
  
  
• Martin Buchholz
  
  
• Richard Mlynarik
  
  
• Stephen Turnbull
• Steve Baur
  
  

Many other people have contributed to XEmacs; this is partially enumerated in the ‘About XEmacs’ option in the Help menu.

Q1.0.6: Who wrote the FAQ?

The current version of this FAQ was created by Ben Wing.

Previous contributors to the FAQ include

• SL Baur
• Hrvoje Niksic
• Curtis.N.Bingham
• Georges Brun-Cottan
• Richard Caley
• Richard Cognot
• Mark Daku
• William G. Dubuque
• Eric Eide
• Alain Fauconnet
• Chris Flatters
• Evelyn Ginsparg
• Marty Hall
• Darrell Kindred
• David Moore
• Arup Mukherjee
• Juergen Nickelsen
• Kevin R. Powell
• Justin Sheehy
• Stig
• Aki Vehtari

1.1: Getting XEmacs

Q1.1.1: Where can I find XEmacs?

To download XEmacs, visit the XEmacs WWW page at http://www.xemacs.org/Download/. The most up-to-date list of distribution sites can always be found there. Try to pick a site that is networkologically close to you. If you know of other mirrors of the XEmacs archives, please send e-mail to mailto:webmaster@xemacs.org and we will list them here as well.

The canonical distribution point is ftp.xemacs.org, available either through HTTP (http://ftp.xemacs.org/) or anonymous FTP (ftp://ftp.xemacs.org/pub/xemacs/).

Q1.1.2: Are binaries available?

MS Windows binaries are available at http://www.xemacs.org/Download/win32/ for the native versions of 21.4 and 21.1. Cygwin binaries are now available as part of the standard Cygwin installation process. XEmacs also comes pre-built as part of many Linux distributions, such as Red Hat and SuSE.

Otherwise, you will need to build XEmacs yourself or get your system administrator to do it. Generally, this is not a difficult process under Unix and Mac OS X, as XEmacs has been tested under all of the common Unix versions and under Mac OS X and comes with an extensive configure script that is able to automatically detect most aspects of the configuration of your particular system.

Q1.1.3: How do I get the bleeding-edge sources?

If you are interested in developing XEmacs, or getting the absolutely most recent, up-to-the-moment, bleeding-edge source code, you can directly access the master CVS source tree (read-only, of course, until you ask for and are granted permission to directly modify portions of the source tree) at cvs.xemacs.org. Directions on how to access the source tree are located at http://www.xemacs.org/Develop/cvsaccess.html.

Nightly CVS snapshots are available at http://www.dk.xemacs.org/Download/CVS-snapshots/.

Q1.1.4: Where can I obtain a printed copy of the XEmacs User’s Manual?

Pre-printed manuals are not available. If you are familiar with TeX, you can generate your own manual from the XEmacs sources.

HTML and Postscript versions of XEmacs manuals are available from the XEmacs web site at http://www.xemacs.org/Documentation/index.html.

1.2: Versions for Different Operating Systems

Q1.2.1: Do I need X11 to run XEmacs?

No. The name XEmacs is unfortunate in the sense that it is not an X Window System-only version of Emacs. XEmacs has full color support on a color-capable character terminal.

Q1.2.2: What versions of Unix does XEmacs run on?

XEmacs is regularly tested on Linux, Solaris and OpenSolaris, HP/UX, FreeBSD, OpenBSD, Cygwin, Mac OS X, and probably others. It should work on all versions of Unix created in the last 10 years or so, perhaps with a bit of work on more obscure platforms to correct bit-rot. It uses a sophisticated configuration system to auto-detect zillions of features that are implemented differently in different versions of Unix, so it will probably work on your vendor’s version, possibly with a bit of tweaking, even if we’ve never heard of it.

For problems with particular machines and versions of Unix, see the ‘PROBLEMS’ file.

Much effort has gone into making XEmacs work on as many different machines, configurations, and compilers as possible.

Much effort has gone into making XEmacs 64-bit clean.

Much effort has gone into removing system-specific code, and replacing such code with autodetection at configure time.

The XEmacs core should build "out of the box" on most Unix-like systems.

XEmacs 21.2 was tested and ‘make check’ succeeded on these Unix configurations as of 2001-02-10:

alphaev56-dec-osf4.0e (both Compaq C and gcc)
i386-unknown-freebsd4.2
i386-unknown-netbsdelf1.5
i586-sco-sysv5uw7.0.1 (both SCO's cc and gcc)
i686-pc-linux-gnu
hppa2.0-hp-hpux10.20 (both HP's ANSI cc and gcc)
mips-sgi-irix6.5 (both MIPSpro cc and gcc)
rs6000-ibm-aix4.3.0.0 (both IBM's xlc and gcc)
sparc-sun-solaris2.6 (both Sun's Forte C and gcc)
sparc-sun-solaris2.7 (both Sun's Forte C and gcc)
sparc-sun-sunos4.1.4 (gcc)

Some systems have a dual mode 32-bit/64-bit compiler. On most of these, XEmacs requires the ‘--pdump’ (in XEmacs 21.5, ‘--enable-pdump’) configure option to build correctly with the 64-bit version of the compiler.

mips-sgi-irix6.5, CC="gcc -mabi=64"
mips-sgi-irix6.5, CC="cc -64"
rs6000-ibm-aix4.3.0.0, CC="cc -q64"

On most of these systems, XEmacs also builds with a C++ compiler, but not "out of the box". This feature is only for use by the maintainers.

XEmacs 21.2 is known not to work on any machines with m680x0 processors. Sorry, all you sun3 and Unix PC nostalgia buffs out there.

VMS has never been supported by XEmacs. In fact, all the old VMS code inherited from Emacs has been removed. Sorry, all you VMS fans out there.

Q1.2.3: Is there a port of XEmacs to Microsoft Windows?

Yes. Beginning with release 21.0, XEmacs has worked under MS Windows and is fully-featured and actively developed. A group of dedicated developers actively maintains and improves the Windows-specific portions of the code. Some of the core developers, in fact, use Windows as their only development environment, and some features, such as printing, actually work better on Windows than native Unix and Mac OS X. The mailing list at xemacs-winnt@xemacs.org is dedicated to that effort (please use the -request address to subscribe). (Despite its name, XEmacs actually works on all versions of Windows.)

The list name is misleading, as XEmacs supports and has been compiled on Windows 95, Windows 98, Windows NT, Windows 2000, Windows ME, Windows XP, and all newer versions of Windows. The MS Windows-specific code is based on Microsoft Win32 API, and will not work on MS Windows 3.x or on MS-DOS.

XEmacs also supports the Cygwin and MinGW development and runtime environments, where it also uses native Windows code for graphical features. In addition, under Cygwin it is possible to compile XEmacs to use an X server (and XFree86 is available as part of the standard Cygwin installation).

Q1.2.4: Can I build XEmacs on MS Windows with X support? Do I need to?

Yes, you can, but no you do not need to. In fact, we recommend that you use a native-GUI version unless you have a specific need for an X version.

Q1.2.5: What are Cygwin and MinGW, and do I need them to run XEmacs?

To answer the second part of the question: No, you, you don’t need Cygwin or MinGW to build or to run XEmacs. But if you have them and want to use them, XEmacs supports these environments.

(One important reason to support Cygwin is that it lets the MS Windows developers test out their code in a Unix environment without actually having to have a Unix machine around. For this reason alone, Cygwin support is likely to remain supported for a long time in XEmacs. Same goes for the X support under Cygwin, for the same reasons. MinGW support, on the other hand, depends on volunteers to keep it up to date; but this is generally not hard.)

Cygwin is a set of tools providing Unix-like API on top of Win32. It makes it easy to port large Unix programs without significant changes to their source code. It is a development environment as well as a runtime environment.

When built with Cygwin, XEmacs supports all display types – TTY, X & Win32 GUI, and can be built with support for all three simultaneously. If you build with Win32 GUI support then the Cygwin version uses the majority of the Windows-specific code, which is mostly related to display. If you want to build with X support you need X libraries (and an X server to display XEmacs on); see Q2.3.7: How do I compile with X support?. TTY and Win32 GUI require no additional libraries beyond what comes standard with Cygwin.

The advantages of the Cygwin version are that it integrates well with the Cygwin environment for existing Cygwin users; uses configure so building with different features is very easy; and actively supports X & TTY. Furthermore, the entire Cygwin environment and compiler are free, whereas Visual C++ costs money.

The disadvantage is that it requires the whole Cygwin environment, whereas the native port requires only a suitable MS Windows compiler. Also, it follows the Unix filesystem and process model very closely (some will undoubtedly view this as an advantage).

See http://www.cygwin.com/ for more information on Cygwin.

MinGW is a collection of header files and import libraries that allow one to use GCC under the Cygwin environment to compile and produce exactly the same native Win32 programs that you can using Visual C++. Programs compiled with MinGW make use of the standard Microsoft runtime library ‘MSVCRT.DLL’, present on all Windows systems, and look, feel, and act like a standard Visual-C-produced application. (The only difference is the compiler.) This means that, unlike a standardly-compiled Cygwin application, no extra runtime support (e.g. Cygwin’s ‘cygwin1.dll’) is required. This, along with the fact that GCC is free (and works in a nice Unix-y way in a nice Unix-y environment, for those die-hard Unix hackers out there), is the main advantage of MinGW. It is also potentially faster than Cygwin because it has less overhead when calling Windows, but you lose the POSIX emulation layer, which makes Unix programs harder to port. (But this is irrelevant for XEmacs since it’s already ported to Win32.)

See http://www.mingw.org/ for more information on MinGW.

Q1.2.6: What are the differences between the various MS Windows emacsen?

XEmacs, Win-Emacs, DOS Emacs, NT Emacs, this is all very confusing. Could you briefly explain the differences between them?

Here is a recount of various Emacs versions running on MS Windows:

• XEmacs
  • - Beginning with XEmacs 19.12, XEmacs’ architecture was redesigned in such a way to allow clean support of multiple window systems. At this time the TTY support was added, making X and TTY the first two "window systems" supported by XEmacs. The 19.12 design is the basis for the current native MS Windows code.
  • - Some time during 1997, David Hobley (soon joined by Marc Paquette) imported some of the NT-specific portions of GNU Emacs, making XEmacs with X support compile under Windows NT, and creating the "X" port.
  • - Several months later, Jonathan Harris sent out initial patches to use the Win32 API, thus creating the native port. Since then, various people have contributed, including Kirill M. Katsnelson (contributed support for menubars, subprocesses and network, as well as loads of other code), Andy Piper (ported XEmacs to Cygwin environment, contributed Windows unexec, Windows-specific glyphs and toolbars code, and more), Ben Wing (loads of improvements; primary MS Windows developer since 2000), Jeff Sparkes (contributed scrollbars support) and many others.
• NT Emacs
  • - NT Emacs was an early version of GNU Emacs 19 modified to compile and run under MS Windows 95 and NT using the native Win32 API. It was written by Geoff Voelker, and has long since been incorporated into the mainline GNU Emacs distribution.
• Win-Emacs
  • - Win-Emacs was a port of Lucid Emacs 19.6 to MS Windows using X compatibility libraries. Win-Emacs was written by Ben Wing. The MS Windows code never made it back to Lucid Emacs, and its creator (Pearl Software) has long since gone out of business.
• GNU Emacs for DOS
  • - GNU Emacs features support for MS-DOS and DJGPP (D.J. Delorie’s DOS port of GCC). Such an Emacs is heavily underfeatured, because it does not support long file names, lacks proper subprocesses support, and is far too big compared with typical DOS editors.
• GNU Emacs compiled with Win32
  • - Starting with GNU Emacs 19.30, it has been possible to compile GNU Emacs under MS Windows using the DJGPP compiler and X libraries. The result is very similar to GNU Emacs compiled under MS DOS, only it works somewhat better because it runs in 32-bit mode, makes use of all the system memory, supports long file names, etc.

Q1.2.7: How does the port cope with differences in the Windows user interface?

The XEmacs (and Emacs in general) user interface is pretty different from what is expected of a typical MS Windows program. How does the MS Windows port cope with it?

As a general rule, we follow native MS Windows conventions as much as possible. 21.4 is a fairly complete Windows application, supporting native printing, system file dialog boxes, tool tips, etc. In cases where there’s a clear UI conflict, we currently use normal Unix XEmacs behavior by default, but make sure the MS Windows "look and feel" (mark via shift-arrow, self-inserting deletes region, Alt selects menu items, etc.) is easily configurable (respectively: using the variable shifted-motion-keys-select-region in 21.4 and above [it’s in fact the default in these versions], or the ‘pc-select’ package; using the ‘pending-del’ package; and setting the variable menu-accelerator-enabled to menu-force in 21.4 and above). In fact, if you use the sample ‘init.el’ file as your init file, you will get all these behaviors automatically turned on.

In future versions, some of these features might be turned on by default in the MS Windows environment.

Q1.2.8: Is there a port of XEmacs to the Macintosh?

Yes.

XEmacs 21.5 (perhaps 21.4 also?) works on MacOS X, although it certainly will not feel very much like a Mac application as it has no Mac-specific code in it.

There is also a port of XEmacs 19.14 that works on all recent versions of MacOS, from 8.1 through MacOS X, by Pitts Jarvis (recently deceased). It runs in an equivalent of TTY mode only (one single Macintosh window, 25 colors), but has a large number of Mac-specific additions. It’s available at http://homepage.mac.com/pjarvis/xemacs.html.

Q1.2.9: Is there a port of XEmacs to MS-DOS?

No. We have never supported running on MS-DOS or Windows 3.1, and in fact have long since deleted all MS-DOS-related code. We’re not particularly interested in patches for these platforms, as they would introduce huge amounts of code clutter due to the woefully underfeatured nature of these systems. (See GNU Emacs for a port to MS-DOS.)

Q1.2.10: Is there a port of XEmacs to OS/2?

No, but Alexander Nikolaev <avn_1251@mail.ru> was at one point working on it.

Q1.2.11: Is there a port of XEmacs to NextStep?

Carl Edman, apparently no longer at cedman@princeton.edu, did the port of GNU Emacs to NeXTstep and expressed interest in doing the XEmacs port, but never went any farther.

Q1.2.12: Is there a port of XEmacs to VMS?

VMS has never been supported by XEmacs. In fact, all the old VMS code inherited from GNU Emacs has been removed. Sorry, all you VMS fans out there.

1.3: Getting Started

Q1.3.1: What is an ‘init.el’ or ‘.emacs’ and is there a sample one?

The ‘init.el’ or ‘.emacs’ file is used to customize XEmacs to your tastes. Starting in 21.4, the preferred location for the init file is ‘~/.xemacs/init.el’; in previous versions, it was ‘~/.emacs’. 21.4 still accepts the old location, but the first time you run it, it will ask to migrate your file to the new location. If you answer yes, the file will be moved, and a "compatibility" ‘.emacs’ file will be placed in the old location so that you can still run older versions of XEmacs, and versions of GNU Emacs, which expect the old location. The ‘.emacs’ file present is just a stub that loads the real file in ‘~/.xemacs/init.el’.

No two init files are alike, nor are they expected to be alike, but that’s the point. The XEmacs distribution contains an excellent starter example in the ‘etc/’ directory called ‘sample.init.el’ (starting in 21.4) or ‘sample.emacs’ in older versions. Copy this file from there to ‘~/.xemacs/init.el’ (starting in 21.4) or ‘~/.emacs’ in older versions, where ‘~’ means your home directory, of course. Then edit it to suit.

You may bring the ‘sample.init.el’ or ‘sample.emacs’ file into an XEmacs buffer from the menubar. (The menu entry for it is always under the ‘Help’ menu, but its location under that has changed in various versions. Recently, look under the ‘Samples’ submenu.) To determine the location of the ‘etc/’ directory type the command C-h v data-directory <RET>.

Q1.3.2: Where do I put my ‘init.el’ file?

‘init.el’ is the name of the init file starting with 21.4, and is located in the subdirectory ‘.xemacs/’ of your home directory. In prior versions, the init file is called ‘.emacs’ and is located in your home directory.

Your home directory under Windows is determined by the ‘HOME’ environment variable. If this is not set, it defaults to ‘C:\’. To set this variable, modify ‘AUTOEXEC.BAT’ under Windows 95/98, or select ‘Control Panel->System->Advanced->Environment Variables...’ under Windows NT/2000.

Q1.3.3: Can I use the same ‘init.el’ with the other Emacs?

Yes. The sample ‘init.el’ included in the XEmacs distribution will show you how to handle different versions and flavors of Emacs.

Q1.3.4: Any good XEmacs tutorials around?

There’s the XEmacs tutorial available from the Help Menu under ‘Help->Tutorials’, or by typing C-h t. To check whether it’s available in a non-english language, type C-u C-h t TAB, type the first letters of your preferred language, then type <RET>.

Q1.3.5: May I see an example of a useful XEmacs Lisp function?

The following function does a little bit of everything useful. It does something with the prefix argument, it examines the text around the cursor, and it’s interactive so it may be bound to a key. It inserts copies of the current word the cursor is sitting on at the cursor. If you give it a prefix argument: C-u 3 M-x double-word then it will insert 3 copies.

(defun double-word (count)
  "Insert a copy of the current word underneath the cursor"
  (interactive "*p")
  (let (here there string)
    (save-excursion
      (forward-word -1)
      (setq here (point))
      (forward-word 1)
      (setq there (point))
      (setq string (buffer-substring here there)))
    (while (>= count 1)
      (insert string)
      (decf count))))

The best way to see what is going on here is to let XEmacs tell you. Put the code into an XEmacs buffer, and do a C-h f with the cursor sitting just to the right of the function you want explained. Eg. move the cursor to the SPACE between interactive and ‘"*p"’ and hit C-h f to see what the function interactive does. Doing this will tell you that the * requires a writable buffer, and p converts the prefix argument to a number, and interactive allows you to execute the command with M-x.

Q1.3.6: And how do I bind it to a key?

To bind to a key do:

(global-set-key "\C-cd" 'double-word)

Or interactively, M-x global-set-key and follow the prompts.

Q1.3.7: What’s the difference between a macro and a function?

Quoting from the Lisp Reference (a.k.a Lispref) Manual:

Macros enable you to define new control constructs and other language features. A macro is defined much like a function, but instead of telling how to compute a value, it tells how to compute another Lisp expression which will in turn compute the value. We call this expression the expansion of the macro.

Macros can do this because they operate on the unevaluated expressions for the arguments, not on the argument values as functions do. They can therefore construct an expansion containing these argument expressions or parts of them.

Do not confuse the two terms with keyboard macros, which are another matter, entirely. A keyboard macro is a key bound to several other keys. Refer to manual for details.

Q1.3.8: What is Custom?

Custom is a system for customizing XEmacs options.

You can access Advanced (Customize) from the Options menu or invoking one of customize commands by typing eg. M-x customize, M-x customize-face, M-x customize-variable or M-x customize-apropos.

There is also new ‘browser’ mode for Customize. Try it out with M-x customize-browse

1.4: Getting Help

Q1.4.1: Where can I get help?

Probably the easiest way, if everything is installed, is to use Info, by pressing C-h i, or looking for an Info item on the Help Menu. M-x apropos can be used to look for particular commands.

For items not found in the manual, try reading this FAQ and reading the Usenet group comp.emacs.xemacs.

If you choose to post to a newsgroup, please use comp.emacs.xemacs. Please do not post XEmacs related questions to gnu.emacs.help.

If you cannot post or read Usenet news, there is a corresponding mailing list xemacs-news@xemacs.org which is available. It can be subscribed to via the Mailman Web interface or by sending mail to to xemacs-news-request@xemacs.org with ‘subscribe’ in the body of the message. See also http://www.xemacs.org/Lists/#xemacs-news. To cancel a subscription, you may use the xemacs-news-request@xemacs.org address or the Web interface. Send a message with a subject of ‘unsubscribe’ to be removed.

Q1.4.2: Which mailing lists are there?

For complete, up-to-date info on the lists and how to subscribe, see http://www.xemacs.org/Lists/.

‘comp.emacs.xemacs’

is a Usenet newsgroup for XEmacs users to discuss problems and issues that arise for them. It’s not generally an appropriate place to ask about apparent bugs (use ‘xemacs-beta’), or future plans (use ‘xemacs-design’).

‘xemacs-announce’

is a read-only, low volume list for announcements concerning the XEmacs project and new releases of the XEmacs software.

‘xemacs-beta’

is an open list for bug reports about beta versions of XEmacs. This includes the bug reports themselves, by both users and developers, as well as queries, follow-ups, and discussions further determining their nature and status. This is the primary channel for this kind of discussion; related code changes will usually not be applied until they have been discussed here. When such discussions touch on significant changes to the code (in particular, structural changes), or on changes to API’s or external functionality, they should be moved to ‘xemacs-design’. Requests and proposals for non-bug-related changes do not belong on ‘xemacs-beta’, and should be sent to ‘xemacs-design’ instead.

‘xemacs-beta-ja’

is an open list for bug reports and design discussion related to Mule features, including Japanese handling, in beta versions of XEmacs. Japanese is the preferred language of discussion. For most timely presentation to reviewers, please consider sending appropriate discussion to ‘xemacs-mule’ or ‘xemacs-design’ in English when convenient for the participants in discussion. When possible, bug reports not related to Mule (including Japanese) should be reported on ‘xemacs-beta’ in English.

‘xemacs-buildreports’

is an open list for submission of build-reports on beta versions of XEmacs. For information on what the build-reports should contain, please see the ‘etc/BETA’ file which is included in each beta distribution.

‘xemacs-cvs’

is a read-only list for notices and information on what has been committed to the XEmacs CVS trees, by whom, and for what.

‘xemacs-design’

is an open list for discussing the design of XEmacs. This includes discussion about planned and ongoing changes to functionality and API changes and additions as well as requests for them. This is the primary channel for this kind of discussion; related code changes will usually not be applied until they have been discussed here. This does not include bug reports, which go to ‘xemacs-beta’.

‘xemacs-mule’

is an open mailing list for discussion of International extensions to XEmacs including Mule, XIM, I18n issues, etc, and is not confined to developmental issues. This list is not restricted to English, postings in all languages are welcome.

‘xemacs-news’

is an open list for discussion and bug reporting for XEmacs. This mailing list is bi-directionally gatewayed with the USENET newsgroup comp.emacs.xemacs.

‘xemacs-nt’

is a developers-only mailing list and is intended for people who wish to work actively on the porting of XEmacs to Microsoft Windows NT and Microsoft Windows ’95.

‘xemacs-patches’

is an open, moderated list for submission of patches to the XEmacs distribution and its packages. Anyone may subscribe or submit to xemacs-patches, but all submissions are reviewed by the list moderator before they are distributed to the list. Discussion is not appropriate on xemacs-patches.

‘xemacs-users-ja’

is an open list for discussion and bug reporting for XEmacs. Japanese is the preferred language of discussion. It is not gated to comp.emacs.xemacs or the ‘xemacs’ list. For fastest response, bugs not specifically related to Japanese or Mule features should be reported on ‘xemacs-beta’ (in English).

‘xemacs-users-ru’

is an open list for discussion and bug reporting for XEmacs. Russian is the preferred language of discussion. It is not gated to comp.emacs.xemacs or the ‘xemacs’ list. For fastest response, bugs not specifically related to Russian or Mule features should be reported on ‘xemacs-beta’ (in English).

Q1.4.3: Where are the mailing lists archived?

The archives can be found at http://list-archive.xemacs.org

Q1.4.4: How can I get two instances of info?

Before 21.4, you can’t. The info package does not provide for multiple info buffers. In 21.4, this should be fixed. #### how?

Q1.4.5: How do I add new Info directories?

You use something like:

(setq Info-directory-list (cons
                           (expand-file-name "~/info")
                           Info-default-directory-list))

David Masterson writes:

Emacs Info and XEmacs Info do many things differently. If you’re trying to support a number of versions of Emacs, here are some notes to remember:

1. Emacs Info scans Info-directory-list from right-to-left while XEmacs Info reads it from left-to-right, so append to the correct end of the list.
2. Use Info-default-directory-list to initialize Info-directory-list if it is available at startup, but not all Emacsen define it.
3. Emacs Info looks for a standard ‘dir’ file in each of the directories scanned from #1 and magically concatenates them together.
4. XEmacs Info looks for a ‘localdir’ file (which consists of just the menu entries from a ‘dir’ file) in each of the directories scanned from #1 (except the first), does a simple concatenation of them, and magically attaches the resulting list to the end of the menu in the ‘dir’ file in the first directory.

Another alternative is to convert the documentation to HTML with texi2html and read it from a web browser like Lynx or W3.

1.5: Contributing to XEmacs

Q1.5.1: How do I submit changes to the FAQ?

The FAQ is actively maintained and modified regularly. All links should be up to date. Unfortunately, some of the information is out of date – a situation which the FAQ maintainer is working on. All submissions are welcome, please e-mail submissions to XEmacs FAQ maintainers.

Please make sure that ‘XEmacs FAQ’ appears on the Subject: line. If you think you have a better way of answering a question, or think a question should be included, we’d like to hear about it. Questions and answers included into the FAQ will be edited for spelling and grammar and will be attributed. Answers appearing without attribution are either from versions of the FAQ dated before May 1996 or are from previous FAQ maintainers. Answers quoted from Usenet news articles will always be attributed, regardless of the author.

Q1.5.2: How do I become a beta tester?

Send an email message to xemacs-beta-request@xemacs.org with the line ‘subscribe’ in the body of the message.

Be prepared to get your hands dirty, as beta testers are expected to identify problems as best they can.

Q1.5.3: How do I contribute to XEmacs itself?

It depends on the knowledge and time you possess. If you are able, by all means become a beta tester (see section Q1.5.2: How do I become a beta tester?). If you are a programmer, try to build XEmacs and see if you can improve it.

Otherwise, you can still help by using XEmacs as your everyday editor (for pre-built binary versions, see section Q1.1.2: Are binaries available?) and reporting bugs you find to the mailing list.

Another area where we need help is the documentation: We need good documentation for building XEmacs and for using it. This FAQ is a small step in that direction.

Ben Wing ben@xemacs.org writes:

BTW if you have a wish list of things that you want added, you have to speak up about it! More specifically, you can do the following if you want a feature added (in increasing order of usefulness):

• Make a posting about a feature you want added.
• Become a beta tester and make more postings about those same features.
• Convince us that you’re going to use the features in some cool and useful way.
• Come up with a clear and well-thought-out API concerning the features.
• Write the code to implement a feature and send us a patch.

(not that we’re necessarily requiring you to write the code, but we can always hope :)

Q1.5.4: How do I get started developing XEmacs?

First, get yourself set up under CVS so that you can access the CVS repositories containing the XEmacs sources and the XEmacs packages.

Next, set up your layout. This is important, as a good layout will facilitate getting things done efficiently, while a bad layout will could lead to disaster, as you can’t figure out which code is the most recent, which can be thrown away, etc. We suggest the following layout: (feel free to make changes)

• Everything goes under ‘/src/xemacs’ (use a different directory if you want). From now, instead of saying ‘/src/xemacs’, we use ‘<xsrc-top>’, to make it easier in case someone picked a different directory.
• Package source is in ‘<xsrc-top>/package-src’.
• Installed packages go under ‘<xsrc-top>/xemacs-packages’, and ‘<xsrc-top>/mule-packages’.
• A "workspace" is a complete copy of the sources, in which you do work of a particular kind. Workspaces can be differentiated by which branch of the source tree they extend off of – usually either the stable or experimental, unless other branches have been created (for example, Ben created a branch for his Mule work because (1) the project was long-term and involved an enormous number of changes, (2) people wanted to be able to look at what his work in progress, and (3) he wanted to be able to check things in and in general use source-code control, since it was a long-term project). Workspaces are also differentiated in what their purpose is – general working workspace, workspace for particular projects, workspace keeping the latest copy of the code in one of the branches without mods, etc.
• Various workspaces are subdirectories under ‘<xsrc-top>’, e.g.:
  • ‘<xsrc-top>/working’ (the workspace you’re actively working on, periodically synched up with the latest trunk)
  • ‘<xsrc-top>/stable’ (for making changes to the stable version of XEmacs, which sits on a branch)
  • ‘<xsrc-top>/unsigned-removal’ (a workspace for a specific, difficult task that’s going to affect lots of source and take a long time, and so best done in its own workspace without the interference of other work you’re doing. Also, you can commit just this one large change, separate from all the other changes).
  • ‘<xsrc-top>/latest’ (a copy of the latest sources on the trunk, i.e. the experimental version of XEmacs, with no patches in it; either update it periodically, by hand, or set up a cron job to do it automatically). Set it up so it can be built, and build it so you have a working XEmacs. (Building it might also go into the cron job.)

    This workspace serves a number of purposes:

    1. You always have a recent version of XEmacs you can compare against when something you’re working on breaks. It’s true that you can do this with cvs diff, but when you need to do some serious investigation, this method just fails.
    2. You (almost) always have a working, up-to-date executable that can be used when your executable is crashing and you need to keep developing it, or when you need an ‘xemacs’ to build packages, etc.
    3. When creating new workspaces, you can just copy the ‘latest’ workspace using GNU cp -a. You have all the .elc’s built, everything else probably configured, any spare files in place (e.g. some annoying xpm.dll under Windows, etc.).
  • ‘<xsrc-top>/latest-stable/’ (equivalent to ‘<xsrc-top>/latest/’, but for the Stable branch of XEmacs, rather than the Experimental branch of XEmacs). This may or may not be necessary depending on how much development you do of the stable branch.
• ‘<xsrc-top>/xemacsweb’ is a workspace for working on the XEmacs web site.
• ‘<xsrc-top>/in-patches’ for patches received from email and saved to files.
• ‘<xsrc-top>/out-patches’ for locally-generated patches to be sent to xemacs-patches@xemacs.org. Less useful now that the patcher util has been developed.
• ‘<xsrc-top>/build’, for build trees when compiling and testing XEmacs with various configuration options turned off and on. The scripts in xemacs-builds/ben (see below) can be used to automate building XEmacs workspaces with many different configuration options and automatically filtering out the normal output so that you see only the abnormal output.
• ‘<xsrc-top>/xemacs-builds’, for the xemacs-builds module, which you need to check out separately in CVS. This contains scripts used for building XEmacs, automating and simplifying using CVS, etc. Under various people’s directories are their own build and other scripts. The currently most-maintained scripts are under ben/, where there are easily configurable scripts that can be used to easily build any workspace (esp. if you’ve more or less followed the layout presented above) unattended, with one or more configuration states (there’s a pre-determined list of the most useful, but it’s easy to change). The output is filtered and split up in various ways so that you can identify which output came from where, and you can see the output either full or with all "normal" output except occasional status messages filtered so that you only see the abnormal ones.

Q1.5.5: What’s the basic layout of the code?

The file ‘configure’ is a shell script to acclimate XEmacs to the oddities of your processor and operating system. It will create a file named ‘Makefile’ (a script for the ‘make’ program), which helps automate the process of building and installing emacs. See INSTALL for more detailed information.

The file ‘configure.in’ is the input used by the autoconf program to construct the ‘configure’ script. Since XEmacs has configuration requirements that autoconf can’t meet, ‘configure.in’ uses an unholy marriage of custom-baked configuration code and autoconf macros; it may be wise to avoid rebuilding ‘configure’ from ‘configure.in’ when possible.

The file ‘Makefile.in’ is a template used by ‘configure’ to create ‘Makefile’.

There are several subdirectories:

1. ‘src’ holds the C code for XEmacs (the XEmacs Lisp interpreter and its primitives, the redisplay code, and some basic editing functions).
2. ‘lisp’ holds the XEmacs Lisp code for XEmacs (most everything else).
3. ‘lib-src’ holds the source code for some utility programs for use by or with XEmacs, like movemail and etags.
4. ‘etc’ holds miscellaneous architecture-independent data files XEmacs uses, like the tutorial text. The contents of the ‘lisp’, ‘info’ and ‘man’ subdirectories are architecture-independent too.
5. ‘lwlib’ holds the C code for the X toolkit objects used by XEmacs.
6. ‘info’ holds the Info documentation tree for XEmacs.
7. ‘man’ holds the source code for the XEmacs online documentation.
8. ‘nt’ holds files used compiling XEmacs under Microsoft Windows.

1.6: Politics (XEmacs vs. GNU Emacs)

Q1.6.1: What is GNU Emacs?

GNU Emacs and XEmacs are related open-source text editors. Both derive from GNU Emacs version 18; the split between the two happened in 1991 (for comparison, the oldest versions of GNU Emacs date from 1984). For information on GNU Emacs, see http://www.gnu.org/software/emacs/emacs.html.

Q1.6.2: How does XEmacs differ from GNU Emacs?

For a detailed description of the differences between GNU Emacs and XEmacs and a detailed history of XEmacs, check out the

NEWS file

User-Visible Editing Features

XEmacs in general tries hard to conform to exist user-interface standards, and to work "out-of-the-box" without the need for obscure customization changes. GNU Emacs, particularly version 21, has gotten better about this (in many cases by copying the XEmacs behavior!), but still has some weirdnesses. For example, the standard method of selecting text using the Shift key works out-of-the-box in XEmacs.

XEmacs has a built-in toolbar. Four toolbars can actually be configured simultaneously: top, bottom, left, and right toolbars.

XEmacs has vertical and horizontal scrollbars. Unlike in GNU Emacs 19 (which provides a primitive form of vertical scrollbar), these are true toolkit scrollbars. A look-alike Motif scrollbar is provided for those who don’t have Motif. (Even for those who do, the look-alike may be preferable as it is faster.)

XEmacs has buffer tabs along the top of the frame (although the position can be changed) that make it very easy to switch buffers.

The menubar under XEmacs is better-designed, with more thought put into it.

XEmacs can ask questions using popup dialog boxes. Any command executed from a menu will ask yes/no questions with dialog boxes, while commands executed via the keyboard will use the minibuffer.

XEmacs under MS Windows provides uses the standard file-dialog box for opening and saving files. Standard menu-accelerator behavior can easily be enabled using the Options menu, and integrates well into the existing keymap.

XEmacs has (still experimental) support for widgets of various sorts – buttons, text boxes, sliders, progress bars, etc. A progress bar is used in font lock to show the progress.

Experimental support for drag-and-drop protocols is provided from XEmacs 21.

General Platform Support

If you’re running on a machine with audio hardware, you can specify sound files for XEmacs to play instead of the default X beep. See the documentation of the function load-sound-file and the variable sound-alist. XEmacs also supports the network sound protocols NAS and EsounD.

XEmacs 21 supports database protocols with LISP bindings, currently including Berkeley DB, LDAP, and PostgreSQL (21.2 only).

XEmacs 20 and 21 support the Canna, Wnn, and SJ3 Japanese input method servers directly, as well as through the X Input Method (XIM) protocol. GNU Emacs 20 supports only the XIM protocol. Both Emacsen support the Quail family of input methods (implemented in LISP) for many languages.

XEmacs provides support for ToolTalk on systems that have it.

Packaged LISP Libraries

Many more packages are provided standard with XEmacs than with GNU Emacs 19 or 20.

XEmacs 21 supports an integrated package management system which uses EFS to download, then automatically install prebuilt LISP libraries. This allows XEmacs users much more straightforward access to the "latest and greatest" version of any given library.

We are working on a standard method for enabling, disabling and otherwise controlling packages, which should make them very easy to use.

LISP Programming

From XEmacs 20 on, characters are a separate type. Characters can be converted to integers (and many integers can be converted to characters), but characters are not integers. GNU Emacs 19, XEmacs 19, Mule 2.3 (an extensive patch to GNU Emacs 18.55 and 19.x), and GNU Emacs 20 (incorporating Mule 3 and later Mule 4) represent them as integers.

From XEmacs 20 on, the buffer is treated as an array of characters, and the representation of buffer text is not exposed to LISP. The GNU Emacs 20 functions like buffer-as-multibyte are not supported.

In XEmacs, events are first-class objects. GNU Emacs 19 represents them as integers, which obscures the differences between a key gesture and the ancient ASCII code used to represent a particular overlapping subset of them.

In XEmacs, keymaps are first-class opaque objects. GNU Emacs 19 represents them as complicated combinations of association lists and vectors. If you use the advertised functional interface to manipulation of keymaps, the same code will work in XEmacs, GNU Emacs 18, and GNU Emacs 19; if your code depends on the underlying implementation of keymaps, it will not.

XEmacs uses "extents" to represent all non-textual aspects of buffers; GNU Emacs 19 uses two distinct objects, "text properties" and "overlays", which divide up the functionality between them. Extents are a superset of the union of the functionality of the two GNU Emacs data types. The full GNU Emacs 19 interface to text properties and overlays is supported in XEmacs (with extents being the underlying representation).

Extents can be made to be copied into strings, and then restored, by kill and yank. Thus, one can specify this behavior on either "extents" or "text properties", whereas in GNU Emacs 19 text properties always have this behavior and overlays never do.

Window System Programming Interface

XEmacs uses the MIT "Xt" toolkit instead of raw Xlib calls, which makes it be a more well-behaved X citizen (and also improves portability). A result of this is that it is possible to include other Xt "Widgets" in the XEmacs window. Also, XEmacs understands the standard Xt command-line arguments.

XEmacs supports Motif applications, generic Xt (e.g. Athena) applications, and raw Xlib applications. An XEmacs variant which supports GTK+ is available (integration as an option in the XEmacs mainline is planned for XEmacs 22), although code to take advantage of the support is as yet scarce.

An XEmacs frame can be placed within an "external client widget" managed by another application. This allows an application to use an XEmacs frame as its text pane rather than the standard Text widget that is provided with Motif or Athena.

Community Participation

Joining the XEmacs development team is simple. Mail to XEmacs Developers, and you’re in! (If you want to be, of course. You’re also welcome to just post development-related questions and bug reports.) The GNU Emacs development team and internal mailing lists are still by invitation only.

The "bleeding edge" of mainline XEmacs development is available by anonymous CVS as are some subsidiary branches (check out the xemacs-gtk module for the latest in GUI features!)

Development and maintenance of Lisp libraries is separated from the core editor development at a fairly low level. This provides better modularization and a better division of responsibility between external library maintainers and the XEmacs core development team. Even for packages the size of Gnus, XEmacs users normally have access to a pre-built version within a few weeks of a major release, and minor updates often within days.

CVS commit authority is broadly dispersed. Recognized maintainers of LISP libraries who are willing to maintain XEmacs packaged versions automatically qualify for CVS accounts for their packages.

Q1.6.3: How much does XEmacs differ?

RMS has asserted at times that XEmacs is merely a "patch" on top of GNU Emacs (see section Q1.6.4: Is XEmacs "GNU"?). In fact, probably not more than 5% of the code, if that, remains unchanged, and nearly 14 years of work has gone into XEmacs at this point. (GNU Emacs itself is only than 20 years old, and thus XEmacs has existed as a separate product for over 2/3 of the lifespan of GNU Emacs.) As a point of comparison, XEmacs 21.5 has perhaps 65,000 more lines of C code than GNU Emacs 21.2.

However, the XEmacs developers strive to keep their code compatible with GNU Emacs, especially on the Lisp level. Much effort goes into "synching" the XEmacs Elisp code with recent GNU Emacs releases so as to benefit from GNU Emacs development work. (In contrast, almost no code from XEmacs has made it into GNU Emacs, and in fact the GNU Emacs developers are instructed by RMS not to even look at XEmacs source code! This stems from self-imposed licensing restrictions on the part of GNU Emacs – and almost certainly out of hostility, as well.)

Q1.6.4: Is XEmacs "GNU"?

RMS insists on the term "GNU XEmacs" and maintains that

XEmacs is GNU software because it’s a modified version of a GNU program. And it is GNU software because the FSF is the copyright holder for most of it, and therefore the legal responsibility for protecting its free status falls on us whether we want it or not. This is why the term "GNU XEmacs" is legitimate.

In fact, FSF is not the copyright holder for most of the code, as very little unmodified FSF code remains (see section Q1.6.3: How much does XEmacs differ?).

Furthermore, RMS’s assertion that XEmacs is "GNU" seems rather bizarre to the XEmacs developers given RMS’s hostility and general lack of interest in cooperation. "GNU" software in general is part of the GNU Project, is distributed by it on their FTP site, and receives support (or at least cooperation), as well as implicit endorsement, from it. The GNU Project, however, has never supported XEmacs and never distributed XEmacs, and RMS’s hostility is the farthest thing possible from an endorsement. In fact, the GNU Project distributes a number of non-GNU software projects on the FSF web site, but again XEmacs is not one of them.

Q1.6.5: What is the correct way to refer to XEmacs and GNU Emacs?

Unfortunately even the naming of these two applications has become politicized. Much of this stems from RMS, who has a history of politicizing similar issues. (Compare the controversy over "Lignux" and "GNU/Linux".) We would prefer that the terms "XEmacs" and "GNU Emacs" be used, which are neutral and acceptable to most people. RMS, however, is not willing to accept these terms. He insists that, if his product is called "GNU Emacs", then ours must be called "GNU XEmacs". (For our opinion of this term, See section Q1.6.4: Is XEmacs "GNU"?.) On the other hand, if our product is to be called "XEmacs", as we prefer, then his product must simply be called "Emacs". The intent of this seems clear: RMS wants to make sure the names reflect his view that his version is the "real" Emacs and ours is merely a derivative, second-class product (see section Q1.6.3: How much does XEmacs differ?).

The XEmacs developers hope that you will use the neutral terms "XEmacs" and "GNU Emacs" for these two specific products. "Emacs", on the other hand, is a generic term for a class of programmable text editors with a similar look-and-feel, and usually a Lisp-based extension language. These trace themselves back to early editors such as EINE, ZWEI, ZMACS and Multics Emacs. See (internals)A History of Emacs section ‘A History of Emacs’ in XEmacs Internals Manual.

We also call upon RMS, in the spirit of furthering cooperation, to stop politicizing this issue and use the neutral terms "XEmacs" and "GNU Emacs". We have already acceded to RMS’ wishes in this respect, and we expect him to do the same. (In the past, the XEmacs developers often used the terms "FSF Emacs" or "FSFmacs" or "RMSmacs" in reference to GNU Emacs; these terms were apparently modeled after RMS’ own usage of "Gosmacs" and "Gosling Emacs" in reference to Unipress Emacs, produced by James Gosling. RMS, however, considers such terms to be insulting, so we refrain from using them as much as possible in preference to GNU Emacs.)

Q1.6.6: Why haven’t XEmacs and GNU Emacs merged?

There are currently irreconcilable differences in the views about technical, programming, design, organizational and legal matters between Richard Stallman (RMS), the author and leader of the GNU Emacs project, and the XEmacs development team which provide little hope for a merge to take place in the short-term future. There have been repeated attempts at merging by all of the major XEmacs developers, starting from the early days of Lucid Emacs (in 1991), but they have all failed. RMS has very strong views about how GNU Emacs should be structured and how his project should be run, and during the repeated merge efforts has never demonstrated any realistic interest in sufficiently compromising or ceding control to allow a middle ground to be found. The basic problem seems to be the very different goals of RMS and the XEmacs project. The primary goals of the XEmacs project are technical and organizational – we want to create the best editor possible, and to make it as easy as possible for people around the world to contribute. The primary goals of RMS, on the other hand, are political, and GNU Emacs, and any potential merge efforts with XEmacs, are strictly subservient to these goals. In fact, in many ways RMS sees GNU Emacs as the "poster child" of his aims, the one program in the GNU project that above all others must set an example to the world. (This has to do with the fact that GNU Emacs was the first program in the GNU project, and the only one that he is still personally involved with on a day-to-day basis.) Given his goals, his position is completely reasonable – but unfortunately, makes any merge impossible.

From the XEmacs perspective, the most intractable issues appear to be legal and organizational, specifically:

• RMS requires "legal papers" to be signed for all contributions of code to GNU Emacs over 10 lines or so, transferring the copyright and all legal rights to the code to the Free Software Foundation. XEmacs does not and has never required this, since it has the practical effect of discouraging individual and in particular corporate contributions – corporations will almost never sign away their legal rights to code since it makes it impossible to reuse the code in any product that whose license is not compatible with the GNU General Public License. Since RMS has shown no inclination to compromise on this issue, a merge would require that most of the existing XEmacs code would need to be thrown away and rewritten – something the XEmacs developers are understandably reluctant to do.
• A repeated stumbling block in the merge talks has been the issue of organizational control over the resulting product. RMS has made it clear that he intends to have final say over design issues in a merged Emacs. Unfortunately, RMS and the XEmacs developers have repeatedly clashed over design decisions, and RMS’ insistence on getting his way in such disagreements was the very reason for the split in the first place. This same issue has come up again and again in merge talks and we have never been able to come to a satisfactory resolution. To the extent that RMS is willing to compromise at all, it appears to be of a purely political rather than technical nature – "If we support this feature of yours, we also get to support this other feature of mine." The XEmacs developers cannot see how such a process would lead to anything but a mess of incompatible things hodgepodged together.
• Because of the years of separate development, distinct and incompatible interfaces have developed and merging would be extremely difficult even with the above non-technical issues resolved. The problem has been exacerbated by the issue of legal papers – because XEmacs code is not "kosher" from RMS’ perspective, he discourages developers from even looking at it out of legal concerns. Although it is still possible to read the XEmacs documentation and run the program, the practical effect of this prohibition has been to strongly discourage code-sharing and cooperative development – although a great deal of GNU Emacs code has been incorporated into XEmacs, practically none has gone the other direction.

If you have a comment to add regarding the merge, it is a good idea to avoid posting to the newsgroups, because of the very heated flamewars that often result. Mail your questions to xemacs-beta@xemacs.org and emacs-devel@gnu.org.

1.7: External Packages

Q1.7.1: What is the package system?

In order to reduce the size and increase the maintainability of XEmacs, the majority of the Elisp packages that came with previous releases have been unbundled. They have been replaced by the package system. Each elisp add-on (or groups of them when they are small) now comes in its own tarball that contains a small search hierarchy.

You select just the ones you need. Install them by untarring them into the right place. On startup XEmacs will find them, set up the load path correctly, install autoloads, etc, etc.

See section Q2.1.1: How do I install the packages?, for more info on how to download and install the packages.

Q1.7.2: Which external packages are there?

Normal Packages

A very broad collection of elisp packages.

Sun

Support for Sparcworks.

ada

Ada language support.

apel

A Portable Emacs Library. Used by XEmacs MIME support.

auctex

Basic TeX/LaTeX support.

bbdb

The Big Brother Data Base: a rolodex-like database program.

build

Build XEmacs from within (UNIX, Windows).

c-support

Basic single-file add-ons for editing C code.

calc

Emacs calculator.

calendar

Calendar and diary support.

cc-mode

C, C++, Objective-C, Java, CORBA IDL, Pike and AWK language support.

clearcase

New Clearcase Version Control for XEmacs (UNIX, Windows).

clearcase

Support for the Clearcase version control system.

cookie

"Fortune cookie"-style messages. Includes Spook (suspicious phrases) and Yow (Zippy quotes).

crisp

Crisp/Brief emulation.

debug

GUD, gdb, dbx debugging support.

dictionary

Interface to RFC2229 dictionary servers.

dired

The DIRectory EDitor is for manipulating, and running commands on files in a directory.

docbookide

DocBook editing support.

ecb

Emacs source code browser.

ecrypto

Crypto functionality in Emacs Lisp.

edebug

An Emacs Lisp debugger.

ediff

Interface over GNU patch.

edit-utils

Miscellaneous editor extensions, you probably need this.

edt

DEC EDIT/EDT emulation.

efs

Treat files on remote systems the same as local files.

eieio

Enhanced Implementation of Emacs Interpreted Objects.

elib

Portable Emacs Lisp utilities library.

emerge

Another interface over GNU patch.

erc

ERC is an Emacs InternetRelayChat client.

escreen

Multiple editing sessions within a single frame (like screen).

eshell

Command shell implemented entirely in Emacs Lisp.

ess

ESS: Emacs Speaks Statistics.

eterm

Terminal emulation.

eudc

Emacs Unified Directory Client (LDAP, PH).

footnote

Footnoting in mail message editing modes.

forms

Forms editing support (obsolete, use Widget instead).

fortran-modes

Fortran support.

fortran-modes

Fortran language support.

frame-icon

Set up mode-specific icons for each frame under XEmacs.

fsf-compat

GNU Emacs compatibility files.

games

Tetris, Sokoban, and Snake.

general-docs

General documentation. Presently, empty.

gnats

XEmacs bug reports.

gnus

The Gnus Newsreader and Mailreader.

haskell-mode

Haskell editing support.

hm–html-menus

HTML editing.

hyperbole

Hyperbole: The Everyday Info Manager.

ibuffer

Advanced replacement for buffer-menu.

idlwave

Editing and Shell mode for the Interactive Data Language.

igrep

Enhanced front-end for Grep.

ilisp

Front-end for interacting with Inferior Lisp (external lisps).

ispell

Spell-checking with GNU ispell.

jde

Integrated Development Environment for Java.

liece

IRC (Internet Relay Chat) client for Emacs. Note, this package is deprecated and will be removed, use riece instead.

mail-lib

Fundamental lisp files for providing email support.

mailcrypt

Support for messaging encryption with PGP.

mew

Messaging in an Emacs World; a MIME-based email program.

mh-e

The XEmacs Interface to the MH Mail System.

mine

Elisp implementation of the game ’Minehunt’.

misc-games

Other amusements and diversions.

mmm-mode

Support for Multiple Major Modes within a single buffer.

net-utils

Miscellaneous Networking Utilities.

ocaml

Objective Caml editing support.

oo-browser

OO-Browser: The Multi-Language Object-Oriented Code Browser.

ocaml

Objective Caml editing support.

os-utils

Miscellaneous single-file O/S utilities, for printing, archiving, compression, remote shells, etc.

pc

PC style interface emulation.

pcl-cvs

CVS frontend.

pcomplete

Provides programmatic completion.

perl-modes

Perl support.

pgg

Emacs interface to various PGP implementations.

prog-modes

Support for various programming languages.

ps-print

Printing functions and utilities.

psgml

Validated HTML/SGML editing.

psgml-dtds

A collection of DTDs for psgml. Note that this package is deprecated and will be removed in the future, most likely Q2/2003. Instead of using this, you should install needed DTDs yourself.

python-modes

Python language support.

reftex

Emacs support for LaTeX cross-references, citations.

riece

IRC (Internet Relay Chat) client for Emacs.

rmail

An obsolete Emacs mailer. If you do not already use it don’t start.

ruby-modes

Ruby support.

sasl

Simple Authentication and Security Layer (SASL) library.

scheme

Front-end support for Inferior Scheme.

semantic

Semantic bovinator (Yacc/Lex for XEmacs). Includes Senator.

sgml

SGML/Linuxdoc-SGML editing.

sh-script

Support for editing shell scripts.

sieve

Manage Sieve email filtering scripts.

slider

User interface tool.

sml-mode

SML editing support.

sounds-au

XEmacs Sun sound files.

sounds-wav

XEmacs Microsoft sound files.

speedbar

Provides a separate frame with convenient references.

strokes

Mouse enhancement utility.

supercite

An Emacs citation tool for News & Mail messages.

texinfo

XEmacs TeXinfo support.

text-modes

Miscellaneous support for editing text files.

textools

Miscellaneous TeX support.

time

Display time & date on the modeline.

tm

Emacs MIME support. Not needed for gnus >= 5.8.0.

tooltalk

Support for building with Tooltalk.

tpu

DEC EDIT/TPU support.

tramp

Remote shell-based file editing. This is similar to EFS or Ange-FTP, but works with rsh/ssh and rcp/scp.

vc

Version Control for Free systems.

vc-cc

Version Control for ClearCase (UnFree) systems.

vhdl

Support for VHDL.

view-process

A Unix process browsing tool.

viper

VI emulation support.

vm

An Emacs mailer.

w3

A Web browser.

x-symbol

Semi WYSIWYG for LaTeX, HTML, etc, using additional fonts.

xemacs-base

Fundamental XEmacs support, you almost certainly need this.

xemacs-devel

XEmacs Lisp developer support. This package contains utilities for supporting Lisp development. It is a single-file package so it may be tailored.

xlib

Emacs interface to X server.

xslide

XSL editing support.

xslt-process

A minor mode for (X)Emacs which allows running an XSLT processor on a buffer.

xwem

X Emacs Window Manager.

zenirc

ZENIRC IRC Client.

Mule Support (mule)

MULti-lingual Enhancement. Support for world scripts such as Latin, Arabic, Cyrillic, Chinese, Japanese, Greek, Hebrew etc. To use these packages your XEmacs must be compiled with Mule support.

edict

MULE: Lisp Interface to EDICT, Kanji Dictionary.

egg-its

MULE: Wnn (4.2 and 6) support. SJ3 support.

latin-unity

MULE: find single ISO 8859 character set to encode a buffer.

latin-unity

Unify character sets in a buffer. When characters belong to disjoint character sets, this attempts to translate the characters so that they belong to one character set. If the buffer coding system is not sufficient, this suggests different coding systems.

leim

MULE: Quail. All non-English and non-Japanese language support.

locale

MULE: Localized menubars and localized splash screens.

lookup

Dictionary support. (This isn’t an English dictionary program)

mule-base

MULE: Basic Mule support, required for building with Mule.

mule-ucs

MULE: Extended coding systems (including Unicode) for XEmacs.

mule-ucs

Extended coding systems (including Unicode) for XEmacs.

skk

Another Japanese Language Input Method. Can be used without a separate process running as a dictionary server.

Q1.7.3: Do I need to have the packages to run XEmacs?

Strictly speaking, no. XEmacs will build and install just fine without any packages installed. However, only the most basic editing functions will be available with no packages installed, so installing packages is an essential part of making your installed XEmacs _useful_.

Q1.7.4: Is there a way to find which package has particular functionality?

If you want to find out which package contains the functionality you are looking for, use M-x package-get-package-provider, and give it a symbol that is likely to be in that package.

For example, if some code you want to use has a (require 'thingatpt) in it:

	M-x package-get-package-provider RET thingatpt RET

which will return something like: ‘(fsf-compat "1.08").’

1.8: Internationalization

Q1.8.1: What is the status of internationalization support aka MULE (including Asian language support)?

Both the stable and development versions of XEmacs include internationalization support (aka MULE). MULE currently (21.4) works on UNIX and Linux systems. It is possible to build with MULE on Windows systems, but if you really need MULE on Windows, it is recommended that you build and use the development (21.5) version, and deal with the instability of the development tree. Binaries compiled without MULE support run faster than MULE capable XEmacsen.

Q1.8.2: How can I help with internationalization?

If you would like to help, you may want to join the xemacs-mule@xemacs.org mailing list. Especially needed are people who speak/write languages other than English, who are willing to use XEmacs/MULE regularly, and have some experience with Elisp.

Translations of the TUTORIAL and man page are welcome, and XEmacs does support multilingual menus, but we have few current translations.

See section How do I become a Beta Tester?.

Q1.8.3: How do I type non-ASCII characters?

See section How can you type in special characters in XEmacs?, in part 3 of this FAQ, for some simple methods that also work in non-MULE builds of XEmacs (but only for one-octet coded character sets, and mostly for ISO 8859/1). Many of the methods available for Cyrillic (see section How about Cyrillic modes?) work without MULE. MULE has more general capabilities. See section Please explain the various input methods in MULE/XEmacs.

See section How do I display non-ASCII characters?, which covers display of non-ASCII characters.

Q1.8.4: Can XEmacs messages come out in a different language?

The message-catalog support was written but is badly bit-rotted. XEmacs 20 and 21 did not support it, and early releases of XEmacs 22 will not either.

However, menubar localization does work. To enable it, add to your ‘Emacs’ file entries like this:

Emacs*XlwMenu.resourceLabels:                   True
Emacs*XlwMenu.file.labelString:                 Fichier
Emacs*XlwMenu.openInOtherWindow.labelString: 	In anderem Fenster oeffnen

The name of the resource is derived from the non-localized entry by removing punctuation and capitalizing as above.

Q1.8.5: Please explain the various input methods in MULE/XEmacs

Mule supports a wide variety of input methods. There are three basic classes: Lisp implementations, generic platform support, and library interfaces.

Lisp implementations include Quail, which provides table-driven input methods for almost all the character sets that Mule supports (including all of the ISO 8859 family, the Indic languages, Thai, and so on), and SKK, for Japanese. (SKK also supports an interface to an external "dictionary server" process.) Quail supports both typical "dead-key" methods (eg, in the "latin-1-prefix" method, " a produces ä, LATIN SMALL LETTER A WITH DIAERESIS), and the complex dictionary-based phonetic methods used for Asian ideographic languages like Chinese.

Lisp implementations can be less powerful (but they are not perceptibly inefficient), and of course are not portable to non-Emacs applications. The incompatibility can be very annoying. On the other hand, they require no special platform support or external libraries, so if you can display the characters, Mule can input them for you and you can edit, anywhere.

Generic platform support is currently limited to the X Input Method (XIM) framework, although support for MSIME (for MS Windows) is planned, and IIIMF (Sun’s Internet-Intranet Input Method Framework) support is extremely desirable. XIM is enabled at build time by use of the ‘--with-xim’ flag to configure. For use of XIM, see your platform documentation. However, normally the input method you use is specified via the ‘LANG’ and ‘XMODIFIERS’ environment variables.

Of course, input skills are portable across most applications. However, especially in modern GUI systems the habit of using bucky bits has fallen into sad disuse, and many XIM systems are poorly configured for use with Emacs. For example, the kinput2 input manager (a separate process providing an interface between Japanese dictionary servers such as Canna and Wnn, and the application) tends to gobble up keystrokes generating Meta characters. This means that to edit while using an XIM input method, you must toggle the input method off every time you want to use M-f. Your mileage may vary.

Library interfaces are most common for Japanese, although Wnn supports Chinese (traditional and simplified) and Korean. There are Chinese and Korean input servers available, but we do not know of any patches for XEmacs to use them directly. You can use them via IM-enabled terminals, by manipulating the terminal coding systems. We describe only the Japanese-oriented systems here. The advantage of these systems is that they are very powerful, and on platforms where they are available there is typically a wide range of applications that support them. Thus your input skills are portable across applications.

Mule provides built-in interfaces to the following input methods: Wnn4, Wnn6, Canna, and SJ3. These can be configured at build time. There are patches available (no URL, sorry) to support the SKK server, as well. Wnn and SJ3 use the egg user interface. The interface for Canna is specialized to Canna.

Wnn supports Japanese, Chinese and Korean. It is made by OMRON and Kyôto University. It is a powerful and complex system. Wnn4 is free and Wnn6 is not. Wnn uses grammatical hints and probability of word association, so in principle Wnn can be cleverer than other methods.

Canna, made by NEC, supports only Japanese. It is a simple and powerful system. Canna uses only grammar, but its grammar and dictionary are quite sophisticated. So for standard modern Japanese, Canna seems cleverer than Wnn4. In addition, the UNIX version of Canna is free (now there is a Microsoft Windows version).

SJ3, by Sony, supports only Japanese.

Egg consists of following parts:

1. Input character Translation System (ITS) layer. It translates ASCII inputs to Kana/PinYin/Hangul characters.
2. Kana/PinYin/Hangul to Kanji transfer layer. The interface layer to network Kana-Kanji server (Wnn and Sj3).

These input methods are modal. They have a raw (alphabet) mode, a phonetic input mode, and Kana-Kanji transfer mode. However there are mode-less input methods for Egg and Canna. ‘boiled-egg’ is a mode-less input method running on Egg. For Canna, ‘canna.el’ has a tiny boiled-egg-like command, (canna-boil), and there are some boiled-egg-like utilities.

Much of this information was provided by MORIOKA Tomohiko.

Q1.8.6: How do I portably code for MULE/XEmacs?

MULE has evolved rapidly over the last few years, and the original third party patch (for GNU Emacs 19), GNU Emacs 20+, and XEmacs 20+ have quite different implementations. The APIs also vary although recent versions of XEmacs have tended to converge to the GNU Emacs standard.

MULE implementations are going to continue to evolve. Both GNU Emacs and XEmacs are working hard on Unicode support, which will involve new APIs and probably variations on old ones. For XEmacs 22, the old ISO 2022-based system for recognizing encodings will be replaced by a much more flexible system, which should improve accuracy of automatic coding detections, but will also involve new APIs.

MORIOKA Tomohiko writes:

The application implementor must write separate code for these mule variants. [Please don’t hesitate to report these variants to us; they are not, strictly speaking, bugs, but they give third-party developers the same kind of creepy-crawly feeling. We’ll do what we can. – Ed.]

MULE and the next version of Emacs are similar but the symbols are very different—requiring separate code as well.

Namely we must support 3 kinds of mule variants and 4 or 5 or 6 kinds of emacs variants... (;_;) I’m shocked, so I wrote a wrapper package called emu to provide a common interface. [There is an XEmacs package of APEL which provides much more comprehensive coverage. Be careful, however; APEL has problems of its own. – Ed.]

I have the following suggestions about dealing with mule variants:

• (featurep 'mule) t on all mule variants
• (boundp 'MULE) is t on only MULE. Maybe the next version of Emacs will not have this symbol.
• MULE has a variable mule-version. Perhaps the next version of Emacs will have this variable as well.

Following is a sample to distinguish mule variants:

(if (featurep 'mule) (cond ((boundp 'MULE) ;; for original Mule ) ((string-match "XEmacs" emacs-version) ;; for XEmacs with Mule ) (t ;; for next version of Emacs )) ;; for old emacs variants )

Q1.8.7: How about Cyrillic modes?

Ilya Zakharevich writes:

There is a cyrillic mode in the file ‘mysetup.zip’ in ftp://ftp.math.ohio-state.edu/pub/users/ilya/emacs/. This is a modification to Valery Alexeev’s ‘russian.el’ which can be obtained from

http://www.math.uga.edu/~valery/russian.el.

Dima Barsky writes:

There is another cyrillic mode for both GNU Emacs and XEmacs by Dmitrii (Mitya) Manin at http://kulichki-lat.rambler.ru/centrolit/manin/cyr.el.

Rebecca Ore writes:

The fullest resource I found on Russian language use (in and out of XEmacs) is http://www.ibiblio.org/sergei/Software/Software.html

Q1.8.8: Does XEmacs support Unicode?

To get Unicode support, you need a Mule-enabled XEmacs.

21.5 has internal support for Unicode and supports it fully, although we don’t yet use it as the internal encoding.

21.4 supports Unicode partially – as an external encoding for files, processes, and terminals, but without font support. See section How does XEmacs display Unicode?. To get Unicode support in 21.4, install Mule-UCS from packages in the usual way, and put

(require 'un-define)
(set-coding-priority-list '(utf-8))
(set-coding-category-system 'utf-8 'utf-8)

in your init file to enable the UTF-8 coding system. You may wish to view the documentation of set-coding-priority-list if you find that files that are not UTF-8 are being mis-recognized as UTF-8.

Install standard national fonts (not Unicode fonts) for all character sets you use. See section How does XEmacs display Unicode??.

Mule-UCS also supports 16-bit forms of Unicode (UTF-16). It does not support 31-bit forms of Unicode (UTF-32 or UCS-4).

Q1.8.9: How does XEmacs display Unicode?

Mule doesn’t have a Unicode charset internally, so there’s nothing to bind a Unicode registry to. It would not be straightforward to create, either, because Unicode is not ISO 2022-compatible. You’d have to translate it to multiple 96x96 pages.

This means that Mule-UCS uses ordinary national fonts for display. This is not really a problem, except for those languages that use the Unified Han characters. The problem here is that Mule-UCS maps from Unicode code points to national character sets in a deterministic way. By default, this means that Japanese fonts are tried first, then Chinese, then Korean. To change the priority ordering, use the command ‘un-define-change-charset-order’.

It also means you can’t use Unicode fonts directly, at least not without extreme hackery. You can run -nw with (set-terminal-coding-system ’utf-8) if you really want a Unicode font for some reason.

Real Unicode support will be introduced in XEmacs 22.0.

2 Installation and Troubleshooting

This is part 2 of the XEmacs Frequently Asked Questions list. This section is devoted to Installation, Maintenance and Troubleshooting.

2.0: Installation (General)

2.1: Package Installation

2.2: Unix/Mac OS X Installation (Also Relevant to Cygwin, MinGW)

2.3: Windows Installation (Windows, Cygwin, MinGW)

2.4: General Troubleshooting

2.5: Startup-Related Problems

2.0: Installation (General)

Q2.0.1: How do I build and install XEmacs?

See the file ‘etc/NEWS’ for information on new features and other user-visible changes since the last version of XEmacs.

The file ‘INSTALL’ in the top-level directory says how to bring up XEmacs on Unix and Cygwin, once you have loaded the entire subtree of this directory.

See the file ‘nt/README’ for instructions on building XEmacs for Microsoft Windows.

See section Q2.1.1: How do I install the packages?, for the installation of (essential) add on packages.

Q2.0.2: Where do I find external libraries?

All external libraries used by XEmacs can be found on the XEmacs web site http://www.xemacs.org/Download/optLibs.html.

The library versions available here are known to work with XEmacs. (Newer versions will probably work as well but we can’t guarantee it.) We try to keep the libraries up-to-date but may not always succeed. Check the above page for the canonical locations of the external libraries, allowing you to download the latest, bleeding-edge versions.

Q2.0.3: How do I specify the paths that XEmacs uses for finding files?

You can specify what paths to use by using a number of different flags when running configure. See the section MAKE VARIABLES in the top-level file INSTALL in the XEmacs distribution for a listing of those flags.

Most of the time, however, the simplest fix is: do not specify paths as you might for GNU Emacs. XEmacs can generally determine the necessary paths dynamically at run time. The only path that generally needs to be specified is the root directory to install into. That can be specified by passing the --prefix flag to configure. For a description of the XEmacs install tree, please consult the ‘NEWS’ file.

Q2.0.4: Running XEmacs without installing

How can I just try XEmacs without installing it?

XEmacs will run in place without requiring installation and copying of the Lisp directories, and without having to specify a special build-time flag. It’s the copying of the Lisp directories that requires so much space. XEmacs is largely written in Lisp.

A good method is to make a shell alias for xemacs:

alias xemacs=/src/xemacs-21.5/src/xemacs

(You will obviously use whatever directory you downloaded the source tree to instead of ‘/src/xemacs-21.5’).

This will let you run XEmacs without massive copying.

Q2.0.5: XEmacs is too big

The space required by the installation directories can be reduced dramatically if desired. Gzip all the .el files. Remove all the packages you’ll never want to use. Remove the TexInfo manuals. Remove the Info (and use just hardcopy versions of the manual). Remove most of the stuff in etc. Remove or gzip all the source code. Gzip or remove the C source code. Configure it so that copies are not made of the support lisp.

These are all Emacs Lisp source code and bytecompiled object code. You may safely gzip everything named *.el here. You may remove any package you don’t use. Nothing bad will happen if you delete a package that you do not use. You must be sure you do not use it though, so be conservative at first.

Any package with the possible exceptions of xemacs-base, and EFS are candidates for removal. Ask yourself, Do I ever want to use this package? If the answer is no, then it is a candidate for removal.

First, gzip all the .el files. Then go about package by package and start gzipping the .elc files. Then run XEmacs and do whatever it is you normally do. If nothing bad happens, then remove the package. You can remove a package via the PUI interface (M-x pui-list-packages, then press d to mark the packages you wish to delete, and then x to delete them.

Another method is to do M-x package-get-delete-package.

2.1: Package Installation

Q2.1.1: How do I install the packages?

There are three ways to install the packages.

1. Manually, all at once, using the ’Sumo Tarball’.
2. Manually, using individual package tarballs.
3. Automatically, using the package tools from XEmacs.

If you don’t want to mess with the packages, it is easiest to just grab them manually, all at once. (For the other two ways, See section Q2.1.2: Can I install the packages individually?, and See section Q2.1.3: Can I install the packages automatically?.) Download the file

‘xemacs-sumo.tar.gz’

For an XEmacs compiled with Mule you also need

‘xemacs-mule-sumo.tar.gz’

These are in the ‘packages’ directory on your XEmacs mirror archive: ftp://ftp.xemacs.org/pub/xemacs/packages or its mirrors. N.B. They are called ’Sumo Tarballs’ for good reason. They are currently about 19MB and 4.5MB (gzipped) respectively.

Install them on Unix and Mac OS X using the shell/Terminal command

cd $prefix/share/xemacs ; gunzip -c <tarballname> | tar xf -

Where ‘$prefix’ is what you gave to the ‘--prefix’ flag to ‘configure’, and defaults to ‘/usr/local’.

If you have GNU tar you can use:

cd $prefix/share/xemacs ; tar zxvf <tarballname>

If you have the packages somewhere nonstandard and don’t want to bother with ‘$prefix’ (for example, you’re a developer and are compiling the packages yourself, and want your own private copy of everything), you can also directly specify this using ‘configure’. To do this with 21.5 and above use the ‘--with-late-packages’ parameter to specify the directory under which you untarred the above tarballs. Under 21.4 and previous you need to use ‘--package-path’. Using these options looks something like this:

   configure --package-path="~/.xemacs::/src/xemacs/site-packages:/src/xemacs/xemacs-packages:/src/xemacs/mule-packages" ...

Under Windows, you need to place the above ‘tar.gz’ files in the directory specified using the ‘PACKAGE_PREFIX’ value in ‘nt/config.inc’ and by default is ‘\Program Files\XEmacs’. (To untar a ‘tar.gz’ file you will need to use a utility such as WinZip, unless you have Cygwin or a similar environment installed, in which case the above Unix shell command should work fine.) If you want the packages somewhere else, just change ‘PACKAGE_PREFIX’.

Note that XEmacs finds the packages automatically anywhere underneath the directory tree where it expects to find the packages. All you need to do is put stuff there; you don’t need to run any program to tell XEmacs to find the packages, or do anything of that sort.

However, XEmacs will only notice newly installed packages when it starts up, so you will have to restart if you are already running XEmacs.

For more details, See (xemacs)Startup Paths section ‘Startup Paths’ in the XEmacs User’s Manual, and See (xemacs)Packages section ‘Packages’ in the XEmacs User’s Manual.

As the Sumo tarballs are not regenerated as often as the individual packages, it is recommended that you use the automatic package tools afterwards to pick up any recent updates.

NOTE: For detailed information about how the package hierarchies work, See (lispref)Package Overview section ‘Package Overview’ in the XEmacs Lisp Reference Manual.

Q2.1.2: Can I install the packages individually?

Yes, you can download individual packages from the FTP site (see section Q2.1.1: How do I install the packages?). Since packages are automatically noticed at startup, you just have to put them in the right place.

Note: If you are upgrading packages already installed, it’s best to remove the old package first (see section Q2.1.4: Can I upgrade or remove packages?).

For example if we are installing the ‘xemacs-base’ package (version 1.48):

   mkdir $prefix/share/xemacs/xemacs-packages RET # if it does not exist yet
   cd $prefix/share/xemacs/xemacs-packages RET
   gunzip -c /path/to/xemacs-base-1.48-pkg.tar.gz | tar xvf - RET

Or if you have GNU tar, the last step can be:

   tar zxvf /path/to/xemacs-base-1.48-pkg.tar.gz RET

For MULE related packages, it is best to untar into the ‘mule-packages’ hierarchy, i.e. for the ‘mule-base’ package, version 1.37:

   mkdir $prefix/share/xemacs/mule-packages RET # if it does not exist yet
   cd $prefix/share/xemacs/mule-packages RET
   gunzip -c /path/to/mule-base-1.37-pkg.tar.gz | tar xvf - RET

Or if you have GNU tar, the last step can be:

   tar zxvf /path/to/mule-base-1.37-pkg.tar.gz RET

Q2.1.3: Can I install the packages automatically?

XEmacs comes with some tools to make the periodic updating and installing easier. It will notice if new packages or versions are available and will fetch them from the FTP site.

Unfortunately this requires that a few packages are already in place. You will have to install them by hand as above or use a SUMO tarball. This requirement will hopefully go away in the future. The packages you need are:

   efs          - To fetch the files from the FTP site or mirrors.
   xemacs-base  - Needed by efs.

and optionally:

   mailcrypt    - For PGP verification of the package-index file.

After installing these by hand, fire up XEmacs and follow these steps.

1. Choose a download site.
   • via menu: Tools -> Packages -> Set Download Site
   • via keyb: M-x customize-variable RET package-get-remote RET (put in the details of remote host and directory)

   If the package tarballs _AND_ the package-index file are in a local directory, you can: M-x pui-set-local-package-get-directory RET

2. Obtain a list of packages and display the list in a buffer named "*Packages*".
   • menu: Tools -> Packages -> List & Install
   • keyb: M-x pui-list-packages RET

   XEmacs will now connect to the remote site and download the latest package-index file.

   The resulting buffer, "*Packages*" has brief instructions at the end of the buffer.

3. Choose the packages you wish to install.
   • mouse: Click button 2 on the package name.
   • keyb: RET on the package name
4. Make sure you have everything you need.
   • menu: Packages -> Add Required
   • keyb: r

   XEmacs will now search for packages that are required by the ones that you have chosen to install and offer to select those packages also.

   For novices and gurus alike, this step can save your bacon. It’s easy to forget to install a critical package.

5. Download and install the packages.
   • menu: Packages -> Install/Remove Selected
   • keyb: x

Q2.1.4: Can I upgrade or remove packages?

As the exact files and their locations contained in a package may change it is recommended to remove a package first before installing a new version. In order to facilitate removal each package contains a pkginfo/MANIFEST.pkgname file which lists all the files belonging to the package. M-x package-admin-delete-binary-package RET can be used to remove a package using this file.

Note that the interactive package tools included with XEmacs already do this for you.

Q2.1.5: Which packages to install?

Unless you are an advanced user, just install everything.

If you really want to install only what’s absolutely needed, a good minimal set of packages for XEmacs-latin1 would be

xemacs-base, xemacs-devel, c-support, cc-mode, debug, dired, efs,
edit-utils, fsf-compat, mail-lib, net-utils, os-utils, prog-modes,
text-modes, time, mailcrypt

If you are using the XEmacs package tools, don’t forget to do:

	Packages -> Add Required

To make sure you have everything that the packages you have chosen to install need.

See section Q1.7.2: Which external packages are there?, for a description of the various packages.

Q2.1.6: Can you describe the package location process in more detail?

On startup XEmacs looks for packages in so-called package hierarchies. Normally, there are three system wide hierarchies, like this:

$prefix/sahre/xemacs/xemacs-packages/
     Normal packages go here.

$prefix/share/xemacs/mule-packages/
     Mule packages go here and are only searched by MULE-enabled XEmacsen.

$prefix/share/xemacs/site-packages/
     Local and 3rd party packages go here.

This is what you get when you untar the SUMO tarballs under ‘$prefix/share/xemacs’.

‘$prefix’ is specified using the ‘--prefix’ parameter to ‘configure’, and defaults to ‘usr/local’.

If the package path is not explicitly specified, XEmacs looks for the package directory ‘xemacs-packages’ (and ‘mule-packages’ and ‘site-packages’) first under ‘~/.xemacs’, then for a sister directory ‘lib/xemacs-VERSION’ of the directory in which the XEmacs executable is located, then for a sister directory ‘lib/xemacs’. The XEmacs executable (under Unix at least) is installed by default in ‘/usr/local/bin’; this explains why XEmacs in its default installation will find packages that you put under ‘/usr/local/share/xemacs’.

You can specify where exactly XEmacs looks for packages by using the ‘--with-user-packages’ (an alias for ‘--with-early-packages’) or ‘--with-system-packages’ (an alias for ‘--with-late-packages’) or ‘--with-legacy-packages’ (an alias for ‘--with-last-packages’) parameters to ‘configure’ (or the equivalent settings in ‘config.inc’, under Windows), or setting the ‘EMACSEARLYPACKAGES’, ‘EMACSLATEPACKAGES’, and ‘EMACSLASTPACKAGES’ environment variables (which have the same format as the configure options). See section Q2.1.1: How do I install the packages?.

See ‘configure.usage’ for more info about the format of these ‘configure’ parameters.

In addition to the system wide packages, each user can have his own packages installed under ‘~/.xemacs/’. If you want to install packages there using the interactive tools, you need to set package-get-install-to-user-init-directory to t.

The site-packages hierarchy replaces the old ‘site-lisp’ directory. XEmacs no longer looks into a ‘site-lisp’ directly by default. A good place to put ‘site-start.el’ would be in ‘$prefix/share/xemacs/site-packages/lisp/’.

Q2.1.7: EFS fails with "500 AUTH not understood" (NEW)

A typical error: FTP Error: USER request failed; 500 AUTH not understood.

Thanks to Giacomo Boffi giacomo.boffi@polimi.it who recommends on comp.emacs.xemacs:

tell your ftp client to not attempt AUTH authentication (or do not use FTP servers that don’t understand AUTH)

and notes that you need to add an element (often "-u") to ‘efs-ftp-program-args’. Use M-x customize-variable, and verify the needed flag with ‘man ftp’ or other local documentation.

2.2: Unix/Mac OS X Installation (Also Relevant to Cygwin, MinGW)

Q2.2.1: Libraries in non-standard locations

If your libraries are in a non-standard location, you can specify the location using the following flags to ‘configure’. Under 21.4 or earlier:

--site-libraries=WHATEVER
--site-includes=WHATEVER

Under 21.5 or later:

--with-site-libraries=WHATEVER
--with-site-includes=WHATEVER

If you have multiple paths to specify, use the following syntax:

--site-libraries='/path/one /path/two /path/etc'

If the libraries and headers reside in the directories ‘lib’ and ‘include’ of a common root (say ‘/sw’) then both can be specified with a single option:

--site-prefixes=WHATEVER

or for 21.5:

--with-site-prefixes=WHATEVER

Q2.2.2: Why can’t I strip XEmacs?

Richard Cognot writes:

Because of the way XEmacs (and every other Emacsen, AFAIK) is built. The link gives you a bare-boned emacs (called temacs). temacs is then run, preloading some of the lisp files. The result is then dumped into a new executable, named xemacs, which will contain all of the preloaded lisp functions and data.

Now, during the dump itself, the executable (code+data+symbols) is written on disk using a special unexec() function. This function is obviously heavily system dependent. And on some systems, it leads to an executable which, although valid, cannot be stripped without damage. If memory serves, this is especially the case for AIX binaries. On other architectures it might work OK.

The Right Way to strip the emacs binary is to strip temacs prior to dumping xemacs. This will always work, although you can do that only if you install from sources (as temacs is ‘not’ part of the binary kits).

Nat Makarevitch writes:

Here is the trick:

1. [ ./configure; make ]
2. rm src/xemacs
3. strip src/temacs
4. make
5. cp src/xemacs /usr/local/bin/xemacs
6. cp lib-src/DOC-19.16-XEmacs /usr/local/lib/xemacs-19.16/i586-unknown-linuxaout

Q2.2.3: X11/bitmaps/gray (or other X11-related file) not found.

The X11R6 distribution was monolithic, but the X11R7 distribution is much more modular. Many OS distributions omit these bitmaps (assuming nobody uses them, evidently). Your OS distribution should have a developer’s package containing these files, probably with a name containing the string "bitmap". Known package names (you may need to add an extension such as .deb or .rpm) include x11/xbitmaps (Ubuntu) and xorg-x11-xbitmaps (Fedora Core 5).

2.3: Windows Installation (Windows, Cygwin, MinGW)

Q2.3.1: What exactly are all the different ways to build XEmacs under Windows?

XEmacs can be built in several ways in the MS Windows environment.

The standard way is what we call the "native" port. It uses the Win32 API and has no connection with X whatsoever – it does not require X libraries to build, nor does it require an X server to run. The native port is the most reliable version and provides the best graphical support. Almost all development is geared towards this version, and there is little reason not to use it.

The second way to build is the Cygwin port. It takes advantage of Cygnus emulation library under Win32. See section and do I need them to run XEmacs?, for more information.

A third way is the MinGW port. It uses the Cygwin environment to build but does not require it at runtime. See section and do I need them to run XEmacs?, for more information.

Finally, you might also be able to build the non-Cygwin, non-MinGW "X" port. This was actually the first version of XEmacs that ran under MS Windows, and although the code is still in XEmacs, it’s essentially orphaned and it’s unlikely it will compile without a lot of work. If you want an MS Windows versin of XEmacs that supports X, use the Cygwin version. (The X support there is actively maintained, so that Windows developers can test the X support in XEmacs.)

Q2.3.2: What compiler/libraries do I need to compile XEmacs?

You need Visual C++ 4.2, 5.0, or 6.0 for the native version. (We have some beta testers currently trying to compile with VC.NET, aka version 7.0, but we can’t yet report complete success.) For the Cygwin and MinGW versions, you need the Cygwin environment, which comes with GCC, the compiler used for those versions. See section and do I need them to run XEmacs?, for more information on Cygwin and MinGW.

Q2.3.3: How do I compile the native port?

Please read the file ‘nt/README’ in the XEmacs distribution, which contains the full description.

Q2.3.4: What do I need for Cygwin?

You can find the Cygwin tools and compiler at:

http://www.cygwin.com/

Click on the ‘Install or update now!’ link, which will download a file ‘setup.exe’, which you can use to download everything else. (You will need to pick a mirror site; ‘mirrors.rcn.net’ is probably the best.) You should go ahead and install everything – you’ll get various ancillary libraries that XEmacs needs or likes, e.g. XPM, PNG, JPEG, TIFF, etc. You can also get X Windows here, if you want to compile under X.

If you want to compile without X, you will need the ‘xpm-nox’ library, which must be specifically selected in the Cygwin netinstaller; it is not selected by default. The package has had various names. Currently it is called ‘cygXpm-noX4.dll’.

Q2.3.5: How do I compile under Cygwin?

Similar as on Unix; use the usual ‘configure’ and ‘make’ process. Some problems to watch out for:

• make sure HOME is set. This controls where you ‘init.el’ file comes from;
• ‘CYGWIN’ needs to be set to ‘tty’ for process support to work;
• picking up some other grep or other UNIX-like tools can kill configure;
• static heap too small, adjust ‘src/sheap-adjust.h’ to a more positive number;
• (Unconfirmed) The Cygwin version doesn’t understand ‘//machine/path’ type paths so you will need to manually mount a directory of this form under a unix style directory for a build to work on the directory;
• If you’re building WITHOUT X11, don’t forget to change symlinks ‘/usr/lib/libXpm.a’ and ‘/usr/lib/libXpm.dll.a’ to point to the non-X versions of these libraries. By default they point to the X versions. So:

  /usr/lib/libXpm.a -> /usr/lib/libXpm-noX.a /usr/lib/libXpm.dll.a -> /usr/lib/libXpm-noX.dll.a

  (This advice may now be obsolete because of the availability of the cygXpm-noX4.dll package from Cygwin. Send confirmation to faq@xemacs.org.)

• Other problems are listed in the ‘PROBLEMS’ file, in the top-level directory of the XEmacs sources.

Q2.3.6: How do I compile using MinGW (aka ‘the -mno-cygwin flag to gcc’)?

Similar to the method for Unix. Things to remember:

• Specify the target host on the command line for ‘./configure’, e.g. ‘./configure i586-pc-mingw32’.
• Be sure that your build directory is mounted such that it has the same path either as a cygwin path (‘/build/xemacs’) or as a Windows path (‘c:\build\xemacs’).
• Build ‘gcc -mno-cygwin’ versions of the extra libs, i.e. ‘libpng’, ‘compface’, etc.
• Specify the target location of the extra libs on the command line to ‘configure’, e.g.for 21.4 or earlier ‘./configure --site-prefixes=/build/libs i586-pc-mingw32’ and for 21.5 or later ‘./configure --with-site-prefixes=/build/libs i586-pc-mingw32’.

Q2.3.7: How do I compile with X support?

To compile under Cygwin, all you need to do is install XFree86, which is available as part of the standard Cygwin installation. http://www.cygwin.com/. Once installed, ‘configure’ should automatically find the X libraries and compile with X support.

As noted above, the non-Cygwin X support is basically orphaned, and probably won’t work. But if it want to try, it’s described in ‘nt/README’ in some detail. Basically, you need to get X11 libraries from http://ftp.x.org, and compile them. If the precompiled versions are available somewhere, we don’t know of it.

Q2.3.8: Cygwin XEmacs won’t start – cygXpm-noX4.dll was not found (NEW)

The Cygwin binary distributed with the netinstaller uses an external DLL to handle XPM images (such as toolbar buttons). You may get an error like

This application has failed to start because cygXpm-noX4.dll was not found.
Re-installing the application may fix this problem.

Andy Piper <andy@xemacs.org> sez:

cygXpm-noX4 is part of the cygwin distribution under libraries or
graphics, but is not installed by default. You need to run the
cygwin setup again and select this package.

Ie, reinstalling XEmacs won’t help because it is not part of the XEmacs distribution.

2.4: General Troubleshooting

Q2.4.1: How do I deal with bugs or with problems building, installing, or running?

The file ‘PROBLEMS’ contains information on many common problems that occur in building, installing and running XEmacs.

Reports of bugs in XEmacs should be sent to xemacs-beta@xemacs.org. You can also post to the newsgroup comp.emacs.xemacs (or equivalentlt, send to the mailing list xemacs@xemacs.org), but it is less likely that the developers will see it in a timely fashion. See (xemacs)Bugs section ‘Bugs’ in the XEmacs User’s Manual, for more information on how to report bugs. See section Q1.4.2: Which mailing lists are there?, for more information on mailing lists relating to XEmacs.

There are three ways to read the Bugs section.

1. In a printed copy of the XEmacs manual.
2. With Info. First, start XEmacs. From the menu, select ‘Help->Info (Online Docs)->Info Contents’ to enter Info, then click on ‘XEmacs’, then on ‘Bugs’. Or, use the keyboard: do C-h i to enter Info, then m XEmacs RET to get to the Emacs manual, then m Bugs RET to get to the section on bugs. Or use standalone Info in a like manner. (Standalone Info is part of the Texinfo distribution, not part of the XEmacs distribution.)
3. By hand. Do

   cat info/xemacs* | more "+/^File: xemacs.info, Node: Bugs,"

Q2.4.2: Help! XEmacs just crashed on me!

First of all, don’t panic. Whenever XEmacs crashes, it tries extremely hard to auto-save all of your files before dying. (The main time that this will not happen is if the machine physically lost power or if you killed the XEmacs process using kill -9). The next time you try to edit those files, you will be informed that a more recent auto-save file exists. You can use M-x recover-file to retrieve the auto-saved version of the file.

You can use the command M-x recover-session after a crash to pick up where you left off.

Now, XEmacs is not perfect, and there may occasionally be times, or particular sequences of actions, that cause it to crash. If you can come up with a reproducible way of doing this (or even if you have a pretty good memory of exactly what you were doing at the time), the maintainers would be very interested in knowing about it. The best way to report a bug is using M-x report-emacs-bug (or by selecting ‘Send Bug Report...’ from the Help menu). If that won’t work (e.g. you can’t get XEmacs working at all), send ordinary mail to xemacs-beta@xemacs.org. MAKE SURE to include the output from the crash, especially including the Lisp backtrace, as well as the XEmacs configuration from M-x describe-installation (or equivalently, the file ‘Installation’ in the top of the build tree). Note that the developers do not usually follow ‘comp.emacs.xemacs’ on a regular basis; thus, this is better for general questions about XEmacs than bug reports.

If at all possible, include a C stack backtrace of the core dump that was produced. This shows where exactly things went wrong, and makes it much easier to diagnose problems. To do this under Unix and Mac OS X, you need to locate the core file (it’s called ‘core’, and is usually sitting in the directory that you started XEmacs from, or your home directory if that other directory was not writable). Then, go to that directory and execute a command like:

gdb `which xemacs` core

and then issue the command ‘where’ to get the stack backtrace. You might have to use dbx or some similar debugger in place of gdb. If you don’t have any such debugger available, complain to your system administrator.

It’s possible that a core file didn’t get produced or the stack trace from gdb is garbage, in which case you’re out of luck unless you can reproduce the bug. A nonexistent core file can happen in some circumstances on some operating systems, depending on what exactly triggered the crash. It’s also possible, however, that your limits are set to turn them off. You may be able to reenable them using a command like ‘unlimit coredumpsize’ or ‘ulimit -c’. (To find out how your limits are set, use the command ‘limit’.) However, if you didn’t explicitly set your limits this way, go complain to your system administrator and tell him not to disable core files by default.

A garbaged stack trace can happen for various reasons. Some versions of gdb are broken on certain operating systems and aren’t able to read the core file. It’s also possible that the stack got overwritten during the crash. A very simple reason, however, is that your version of XEmacs was compiled without debugging information or had the debugging information stripped. A compilation with optimization can also result in partly or completely garbaged stack trace. In such cases, you will need to recompile XEmacs with debugging information and without optimization; See section How to debug an XEmacs problem with a debugger. Note also that core files currently don’t work at all under Cygwin, and the only way to get a backtrace is to run XEmacs from gdb.

If you cannot get a backtrace from the core dump, but can reproduce the problem, try running XEmacs under gdb. The goal is to get clean C and Lisp backtraces and submit a bug report including full configuration information as described above, as this will greatly assist in the process of tracking down the bug. However, even partial information is better than none. The process of getting backtraces from gdb is described in detail in How to debug an XEmacs problem with a debugger.

If you’re under Microsoft Windows, you’re out of luck unless you happen to have a debugging aid installed on your system, for example Visual C++. In this case, the crash will result in a message giving you the option to enter a debugger (for example, by pressing ‘Cancel’). Do this and locate the stack-trace window. (If your XEmacs was built without debugging information, the stack trace may not be very useful.)

When making a problem report make sure that:

1. Report all of the information output by XEmacs during the crash.
2. You mention what O/S and Hardware you are running XEmacs on.
3. What version of XEmacs you are running.
4. What build options you are using.
5. If the problem is related to graphics and you are running Unix or Mac OS X, we will also need to know what version of the X Window System you are running, and what window manager you are using.
6. If the problem happened on a TTY, please include the terminal type.
7. Try very hard to get both C and Lisp backtraces, as described above.

Much of the information above is automatically generated by M-x report-emacs-bug. Even more, and often useful, information can be generated by redirecting the output of make and make check to a file (‘beta.err’ is the default used by build-report), and executing M-x build-report.

Q2.4.3: XEmacs crashes and I compiled it myself.

There have been a variety of reports of crashes due to compilers with buggy optimizers. If you are compiling with optimization, consider turning it off (see section How to debug an XEmacs problem with a debugger) and recompiling.

Please see the ‘PROBLEMS’ file that comes with XEmacs (it’s in the top-level source directory) to read what it says about your platform.

If you compiled XEmacs 21.4 or earlier using ‘--use-union-type’, or 21.5 or later using ‘--enable-union-type’ (or in either case used the option ‘USE_UNION_TYPE’ in ‘config.inc’ under Windows), try recompiling again without it. The union type has been known to trigger compiler errors in a number of cases.

Q2.4.4: How to debug an XEmacs problem with a debugger

If XEmacs does crash on you, one of the most productive things you can do to help get the bug fixed is to poke around a bit with the debugger. Here are some hints:

• First of all, if the crash is at all reproducible, consider very strongly recompiling your XEmacs with debugging symbols and with no optimization (e.g. with GCC use the compiler flags ‘-g -O0’ – that’s an "oh" followed by a zero), and with the configure options ‘--debug=yes’ and ‘--error-checking=all’ (‘--enable-debug=yes’ and ‘--enable-error-checking=all’ on XEmacs 21.5 or later). This will make your XEmacs run somewhat slower, but you are a lot more likely to catch the problem earlier (closer to its source). It makes it a lot easier to determine what’s going on with a debugger. The way to control the compiler flags is with the configuration option ‘--cflags’ (‘--with-cflags’ in 21.5). If you have a recent version of 21.5, you should use ‘--without-optimization’ in preference to directly setting ‘--cflags’.
• If it’s not a true crash (i.e., XEmacs is hung, or a zombie process), or it’s inconvenient to run XEmacs again because XEmacs is already running or is running in batch mode as part of a bunch of scripts, you may be able to attach to the existing process with your debugger. Under Unix and Mac OS X, the typical way to do this is to first use some variant of the ‘ps’ command to figure out the process ID of XEmacs, for example ‘ps -auxww | grep xemacs’ under a BSD variant, ‘ps -elf | grep xemacs’ under Linux or System V, or ‘ps -aW | grep xemacs’ under Cygwin. Then run

  gdb /path/to/xemacs/xemacs ####

  Where #### is the process id of your XEmacs. (If you’re not sure, try using ‘which xemacs’.) When gdb attaches, the xemacs will stop and you can type ‘where’ in gdb to get a stack trace as usual. To get things moving again, you can just type ‘quit’ in gdb. It’ll tell you the program is running and ask if you want to quit anyways. Say ‘y’ and it’ll quit and have your emacs continue from where it was at.

  If you’re running another debugger, a similar method may work, or you may have to run the debugger first and then use the attach command or something similar.

  Under Microsoft Windows, use the menu item ‘Build->Start Debug->Attach to Process...’ and select the XEmacs process from the list given.

• If you’re able to run XEmacs under a debugger and reproduce the crash, here are some things you can do:
• If XEmacs is hitting an assertion failure, put a breakpoint on assert_failed().
• If XEmacs is hitting some weird Lisp error that’s causing it to crash (e.g. during startup), put a breakpoint on signal_1()—this is declared static in ‘eval.c’.
• If XEmacs is outputting lots of X errors, put a breakpoint on x_error_handler(); that will tell you which call is causing them. Note that the result may not be very useful by default because X Windows normally operates asynchronously: A bunch of commands are buffered up and then sent to the server all at once. This greatly improves performance over a network but means that an error may not be reported until the server receives the commands, which can be long after XEmacs made the erroneous calls. For best results, you need to make the X server synchronous before getting the backtrace. This can be done by starting XEmacs with the ‘-sync’ option or executing the Lisp code (x-debug-mode t).
• Internally, you will probably see lots of variables that hold objects of type Lisp_Object. These are references to Lisp objects. Printing them out with the debugger probably won’t be too useful—you’ll likely just see a number. To decode them, do this:

  call debug_print (OBJECT)

  where OBJECT is whatever you want to decode (it can be a variable, a function call, etc.). This uses the Lisp printing routines to out a readable representation on the TTY from which the xemacs process was invoked.

  Under 21.5 and later, dp is defined as an easier-to-type equivalent of debug_print. You can also try dpa if you can’t see the output from debug_print (this will return a string containing the output), or use debug_p3 if debug_print itself triggers a crash (this is a less comprehensive but super-safe way to print out a Lisp object).

• If you want to get a Lisp backtrace showing the Lisp call stack, do this:

  call debug_backtrace ()

  Under 21.5 and later, db is defined as an easier-to-type equivalent of debug_backtrace.

• Using debug_print and debug_backtrace has two disadvantages - they can only be used with a running (including hung or zombie) xemacs process, and they do not display the internal C structure of a Lisp Object. Even if all you’ve got is a core dump, all is not lost.

  If you’re using GDB, there are some macros in the file ‘src/.gdbinit’ in the XEmacs source distribution that should make it easier for you to decode Lisp objects. This file is automatically read by gdb if gdb is run in the directory where xemacs was built, and contains these useful macros to inspect the state of xemacs:

  pobj

  Usage: pobj lisp_object
  Print the internal C representation of a lisp object.

  xtype

  Usage: xtype lisp_object
  Print the Lisp type of a lisp object.

  lbt

  Usage: lbt
  Print the current Lisp stack trace. Requires a running xemacs process. (It works by calling the db routine described above.)

  ldp

  Usage: ldp lisp_object
  Print a Lisp Object value using the Lisp printer. Requires a running xemacs process. (It works by calling the dp routine described above.)

  run-temacs

  Usage: run-temacs
  Run temacs interactively, like xemacs. Use this with debugging tools (like purify) that cannot deal with dumping, or when temacs builds successfully, but xemacs does not.

  dump-temacs

  Usage: dump-temacs
  Run the dumping part of the build procedure. Use when debugging temacs, not xemacs! Use this when temacs builds successfully, but xemacs does not.

  check-xemacs

  Usage: check-xemacs
  Run the test suite. Equivalent to ’make check’.

  check-temacs

  Usage: check-temacs
  Run the test suite on temacs. Equivalent to ’make check-temacs’. Use this with debugging tools (like purify) that cannot deal with dumping, or when temacs builds successfully, but xemacs does not.

  If you are using Sun’s ‘dbx’ debugger, there is an equivalent file ‘src/.dbxrc’, which defines the same commands for dbx.

• If you’re using a debugger to get a C stack backtrace and you’re seeing stack traces with some of the innermost frames mangled, it may be due to dynamic linking. (This happens especially under Linux.) Consider reconfiguring with ‘--dynamic=no’ (‘--with-dynamic=no’ in 21.5 or later). Also, sometimes (again under Linux), stack backtraces of core dumps will have the frame where the fatal signal occurred mangled; if you can obtain a stack trace while running the XEmacs process under a debugger, the stack trace should be clean.

  Curtiss suggests upgrading to ld.so version 1.8 if dynamic linking and debugging is a problem on Linux.

• If you’re using a debugger to get a C stack backtrace and you’re getting a completely mangled and bogus stack trace, it’s probably due to one of the following:
  1. Your executable has been stripped. Bad news. Tell your sysadmin not to do this—it doesn’t accomplish anything except to save a bit of disk space, and makes debugging much much harder.
  2. Your stack is getting trashed. Debugging this is hard; you have to do a binary-search type of narrowing down where the crash occurs, until you figure out exactly which line is causing the problem. Of course, this only works if the bug is highly reproducible. Also, in many cases if you run XEmacs from the debugger, the debugger can protect the stack somewhat. However, if the stack is being smashed, it is typically the case that there is a wild pointer somewhere in the program, often quite far from where the crash occurs.
  3. If your stack trace has exactly one frame in it, with address 0x0, this could simply mean that XEmacs attempted to execute code at that address, e.g. through jumping to a null function pointer. Unfortunately, under those circumstances, GDB under Linux doesn’t know how to get a stack trace. (Yes, this is the fourth Linux-related problem I’ve mentioned. I have no idea why GDB under Linux is so bogus. Complain to the GDB authors, or to comp.os.linux.development.system.) Again, you’ll have to use the narrowing-down process described above.
  4. You will get a Lisp backtrace output when XEmacs crashes, so you’ll have something useful.
• If you compile with the newer gcc variants gcc-2.8 or egcs, you will also need gdb 4.17 or above. Earlier releases of gdb can’t handle the debug information generated by the newer compilers.
• In versions of XEmacs before 21.2.27, ‘src/.gdbinit’ was named ‘src/gdbinit’. This had the disadvantage of not being sourced automatically by gdb, so you had to set that up yourself.
• If you are running Microsoft Windows, the the file ‘nt/README’ for further information about debugging XEmacs.

Q2.4.5: I get a cryptic error message when trying to do something.

When I try to use some particular option of some particular package, I get a cryptic error message in the minibuffer.

If the message went by too quickly, use ‘Help->Recent Messages’ from the menubar (or type C-h l) to see recent messages.

If you can’t figure out what’s going on, select ‘Options->Troubleshooting->Debug on Error’ from the menubar (or type M-: then (setq debug-on-error t)) then try and make the error happen again. This will put in the debugger (you can get out of this and continue what you were doing before by typing c) and give you a backtrace that may be enlightening. If not, try reading through this FAQ; if that fails, you could try posting to ‘comp.emacs.xemacs’ (making sure to include the backtrace) and someone may be able to help. If you can identify which XEmacs Lisp source file the error is coming from you can get a more detailed stack backtrace by doing the following:

1. Visit the .el file in an XEmacs buffer.
2. Issue the command M-x eval-current-buffer.
3. Reproduce the error.

For more information on debugging Lisp code, See (lispref)Debugging section ‘Debugging’ in XEmacs Lisp Reference Manual.

Q2.4.6: XEmacs hangs when I try to do something.

XEmacs might just be slow; some operations take a long time. XEmacs may also be waiting on a response from the network, for example when you are trying to send mail.

You can usually interrupt XEmacs by typing C-g. If not (for example, Lisp code explicitly disabled this by setting inhibit-quit), you can use the "critical quit" mechanism by typing Control-Shift-G. This should also pop you into the debugger and give you a backtrace, which can tell you where the problem is (see section How to debug an XEmacs problem with a debugger). (Note that setting debug-on-quit or selecting ‘Options->Troubleshooting->Debug on Quit’ will also cause regular C-g to enter the debugger and give you a backtrace.)

If you can’t interrupt XEmacs this way, or for some reason XEmacs is not talking to the keyboard, you can try sending the ‘SIGINT’ signal using the ‘kill’ command.

If the Lisp backtrace isn’t enlightening, or if XEmacs is so hung that you can’t interrupt it at all, you could try attaching to the process and getting a C stack backtrace. See section How to debug an XEmacs problem with a debugger.

Q2.4.7: I get an error message when XEmacs is running in batch mode.

Typically this happens when you are trying to compile some Elisp code. If you are doing this as part of XEmacs or the XEmacs packages, you should automatically get a backtrace, which can help you determine the source of the problem. In other cases, you can get equivalent results by setting the environment variable ‘XEMACSDEBUG’ to ‘(setq stack-trace-on-error t load-always-display-messages t load-ignore-out-of-date-elc-files t load-show-full-path-in-messages t)’ (this needs to be all on one line; to set an environment variable, use ‘export XEMACSDEBUG='FOO'’ under ‘bash’, ‘zsh’, etc. or ‘setenv XEMACSDEBUG 'FOO'’ under ‘csh’ and ‘tcsh’). ‘XEMACSDEBUG’ specifies Lisp code that will be executed at startup time.

If the backtrace is not sufficiently useful in helping you diagnose the problem, you should consider using a debugger such as GDB. See section How to debug an XEmacs problem with a debugger. You probably want to set a breakpoint on signal_1. Since such errors often occur during compiling, which is often triggered by a complex command run from a make suite, it may be easier to attach to the process once it’s running.

Under Microsoft Windows (and perhaps other operating systems), there is another useful trick you can do if you have configured with debugging support (configure option ‘--debug’ (‘--with-debug’ in 21.5) or setting ‘DEBUG_XEMACS’ in ‘nt/config.inc’). Set the environment variable ‘XEMACSDEBUG’ (as described above) to ‘(setq debug-on-error t)’. Then, when an error occurs noninteractively, instead of trying to invoke the Lisp debugger (which obviously won’t work), XEmacs will break out to a C debugger using (force-debugging-signal t). NOTE: This runs abort()!!! (As well as and after executing INT 3 under MS Windows, which should invoke a debugger if it’s active.) This is guaranteed to kill XEmacs! (But in this situation, XEmacs is about to die anyway, and if no debugger is present, this will usefully dump core.)

Q2.4.8: The keyboard or mouse is not working properly, or I have some other event-related problem.

XEmacs has various facilities for debugging event handling.

First, try setting the variable debug-emacs-events to non-zero. This will output various information showing which events are being received and how they are being translated. This may show you, for example, that a key command is getting intercepted using key-translation-map; this problem can otherwise be very tricky to debug.

Under X, you can see exactly which events are being received from the window system by setting x-debug-events to non-zero. (The value ‘1’ gives you regular output, and ‘2’ gives you verbose output, including all parameters.)

A similar facility exists under MS Windows: Set debug-mswindows-events to non-zero. (The value ‘1’ gives you regular output. The value ‘2’ gives you verbose output, including all parameters. The value ‘3’ gives you super-gorily-detailed output.)

Q2.4.9: C-g doesn’t work for me. Is it broken?

C-g does work for most people in most circumstances. If it doesn’t, there are two possible explanations:

1. XEmacs is hung in a way that prevents C-g from working. This can happen when code is wrapped with a binding of inhibit-quit to t; you should still be able interrupt XEmacs using "critical quit". On the other hand, XEmacs may be seriously wedged. (If you’re lucky, sending ‘SIGINT’ to the XEmacs process will interrupt it.) See section XEmacs hangs when I try to do something..
2. C-g is indeed broken on your system. To test, try executing (while t) from the ‘*scratch*’ buffer. If C-g doesn’t interrupt, then it’s broken. This used to happen with systems where ‘SIGIO’ was broken, but ‘BROKEN_SIGIO’ wasn’t defined. However, there may not be very many such systems nowadays.

Q2.4.10: How do I debug process-related problems?

Under MS Windows, you can set the variable debug-mswindows-process-command-lines to non-‘nil’ to get information on exactly what is getting passed to a process. This can be useful in determining problems with quoting. (Under Unix, a process receives each argument separately, but under MS Windows a single command line is received, and arguments with spaces or other special characters in them must be quoted. Unfortunately this means that each process, potentially at least, has its own quoting conventions, and the code to process quoting conventions in ‘cmd.exe’, the Visual C++ startup code and the like is baroque and poorly documented. XEmacs uses the variable mswindows-construct-process-command-line-alist to construct a command line from a list of arguments based on the command to be run, but it is (and cannot be) a perfect solution.)

Q2.4.11: XEmacs is outputting lots of X errors.

If this is happening, we would very much like to know what’s causing them. To find this out, see How to debug an XEmacs problem with a debugger. Try to get both a C and Lisp backtrace, and send them along with the full error output to xemacs-beta@xemacs.org.

Q2.4.12: After upgrading, XEmacs won’t do ‘foo’ any more!

You have been used to doing ‘foo’, but now when you invoke it (or click the toolbar button or select the menu item), nothing (or an error) happens. The simplest explanation is that you are missing a package that is essential to you. You can either track it down and install it (there is a list of packages and brief descriptions of their contents in ‘etc/PACKAGES’), or install the ‘Sumo Tarball’ (see section How do I figure out which packages to install?).

2.5: Startup-Related Problems

Q2.5.1: XEmacs cannot connect to my X Terminal!

Help! I can not get XEmacs to display on my Envizex X-terminal!

Try setting the DISPLAY variable using the numeric IP address of the host you are running XEmacs from.

Q2.5.2 Startup problems related to paths or package locations.

First of all, if XEmacs can’t find the packages, check to make sure that you put the packages in the right place, or that you told XEmacs where to look for the packages when you compiled it. See section Q2.1.1: How do I install the packages?.

If something is still going wrong, or you get a startup warning about not being able to deduce some paths, you can get detailed information on the path-searching process at startup by setting the environment variable ‘EMACSDEBUGPATHS’ to a non-null value. One thing to look for if you’re having package problems is the value of ‘configure-package-path’. This corresponds to what was compiled into XEmacs using the ‘--package-prefix’ or ‘--package-path’ parameter (see section Q2.1.1: How do I install the packages?). If this has the value of ‘nil’, this means that no value was compiled into XEmacs using these parameters.

Q2.5.3: XEmacs won’t start without network, or starts slowly.

If XEmacs starts when you’re on the network, but fails when you’re not on the network, you may be missing a "localhost" entry in your ‘/etc/hosts’ file. The file should contain an entry like:

127.0.0.1        localhost

Add that line, and XEmacs will be happy. If your network is unreliable, such as a Wifi network, you may experience delays but eventually XEmacs starts up. This may be due to having the lookup order give precedence to DNS over the hosts file (often lookup order is defined in one of the files ‘/etc/host.conf’, ‘/etc/nsswitch.conf’, or ‘/etc/resolv.conf’, depending on OS). See your system documentation for this configuration. Note that changing the lookup order is a workaround; there are good reasons to have DNS come earlier by default. Make sure those reasons are less important to you than a quick XEmacs startup.

Q2.5.4: Startup warnings about deducing proper fonts?

How can I avoid the startup warnings about deducing proper fonts?

This is highly dependent on your installation, but try with the following font as your base font for XEmacs and see what it does:

-adobe-courier-medium-r-*-*-*-120-*-*-*-*-iso8859-1

More precisely, do the following in your resource file:

Emacs.default.attributeFont: \
-adobe-courier-medium-r-*-*-*-120-*-*-*-*-iso8859-1

If you just don’t want to see the ‘*Warnings*’ buffer at startup time, you can set this:

(setq display-warning-minimum-level 'error)

The buffer still exists; it just isn’t in your face.

Q2.5.5: Warnings from incorrect key modifiers.

The following information comes from the ‘PROBLEMS’ file that comes with XEmacs.

If you’re having troubles with HP/UX it is because HP/UX defines the modifiers wrong in X. Here is a shell script to fix the problem; be sure that it is run after VUE configures the X server.

#! /bin/sh
xmodmap 2> /dev/null - << EOF
keysym Alt_L = Meta_L
keysym Alt_R = Meta_R
EOF

xmodmap - << EOF
clear mod1
keysym Mode_switch = NoSymbol
add mod1 = Meta_L
keysym Meta_R = Mode_switch
add mod2 = Mode_switch
EOF

Q2.5.6: XEmacs 21.1 on Windows used to spawn an ugly console window on every startup. Has that been fixed?

Yes.

The console was there because ‘temacs’ (and in turn, ‘xemacs’) was a console application, and Windows typically creates a new console for a console process unless the creating process requests that one isn’t created. This used to be fixed with ‘runemacs’, a small Windows application that existed merely to start ‘xemacs’, stating that it didn’t want a console.

XEmacs 21.4 fixes this cleanly by the virtue of being a true "GUI" application. The explanation of what that means is included for educational value.

When building an application to be run in a Win32 environment, you must state which sub-system it is to run in. Valid subsystems include "console" and "gui". The subsystem you use affects the run time libraries linked into your application, the start up function that is run before control is handed over to your application, the entry point to your program, and how Windows normally invokes your program. (Console programs automatically get a console created for them at startup if their stdin/stdout don’t point anywhere useful, which is the case when run from the GUI. This is a stupid design, of course – instead, the console should get created only when the first I/O actually occurs! GUI programs have an equally stupid design: When called from ‘CMD.EXE’/‘COMMAND.COM’, their stdin/stdout will be set to point nowhere useful, even though the command shell has its own stdin/stdout. It’s as if someone who had learned a bit about stdio but had no actual knowledge of interprocess communication designed the scheme; unfortunately, the whole process-communication aspect of the Win32 API is equally badly designed.) For example, the entry point for a console app is "main" (which is what you’d expect for a C/C++ program), but the entry point for a "gui" app is "WinMain". This confuses and annoys a lot of programmers who’ve grown up on Unix systems, where the kernel doesn’t really care whether your application is a gui program or not.

For reasons not altogether clear, and are lost in the mists of time and tradition, XEmacs on Win32 started out as a console application, and therefore a console was automatically created for it. (It may have been made a console application partly because a console is needed in some circumstances, especially under Win95, to interrupt, terminate, or send signals to a child process, and because of the bogosity mentioned above with GUI programs and the standard command shell. Currently, XEmacs just creates and immediately hides a console when necessary, and works around the "no useful stdio" problem by creating its own console window as necessary to display messages in.)

Q2.5.7: XEmacs issues messages about “auto-autoloads already loaded.”

On Sat, 05 Mar 2011 11:54:47 -0500, in Message-ID: <4D726AD7.7020303@gmail.com> on xemacs-beta, Raymond Toy reported:

[N]ow every time I start xemacs, I get 100+ error messages stating that the auto-autoload for every package has already been loaded.

This occurs if you have duplicate packages installed on your load-path. To detect exactly which paths are duplicated, use M-x list-load-path-shadows. If you have a small number of duplicated libraries, it is probably one or more packages available both in the XEmacs distribution and in third-party distributions. If you prefer the third-party version, use M-x list-packages to get the package management UI, and uninstall the particular packages. Removal of third party packages must be done manually, if you wish to keep the version distributed by XEmacs.

When you have many duplicate packages, a common cause is that XEmacs finds package root directories that are duplicates of each other. This can occur in some automounter configurations, or when the roots share some subtrees via symlinks. In this case, you will get a warning for all of the packages you have installed. Although this is basically a site configuration problem, please report these cases. XEmacs is already aware of many automounter artifacts, and automatically adjusts for them. Code is being added to try to detect symlinks. We may not be able to handle every case, but we’d like to know about them, and where possible incorporate workarounds.

Package root directories are specified at configuration time via the --prefix, --exec-prefix, and the ‘--with-*-packages’ options; at runtime relative to the XEmacs binary (‘../share’ and ‘..’ (for run-in-place)); and at runtime via the ‘EMACS*PACKAGES’ environment variables. Unless you have special needs, it is best to install XEmacs and the packages (configuring with --with-prefix=$prefix for XEmacs and by untarring the SUMOs in ‘$prefix/share/xemacs/’.

Note that older versions of XEmacs (21.1, 21.4, and early releases of 21.5) by default expect the packages to be installed under ‘$prefix/lib’ rather than ‘$prefix/share’. See the documentation for ‘configure’ for how to point XEmacs at ‘$prefix/share/xemacs/’ if that is preferred, or older XEmacsen need to share packages with recent versions.

This document was generated by Aidan Kehoe on December 27, 2016 using texi2html 1.82.