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?

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 pronounciation is `Eks eemax'.

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 Zawinksi, 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 Skytta, 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, SunOS, HP/UX, FreeBSD, OpenBSD, BSD/OS aka BSDI, Tru64 aka DEC/OSF, SCO5, 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