-*- mode:outline; minor-mode:outl-mouse -*-

* Introduction
==============

This file presents some general information about XEmacs.  It is primarily
about the evolution of XEmacs and its release history.

There are five sections.

    Introduction................(this section) provides an introduction

    Using Outline Mode..........briefly explains how to use outline mode

    The History of XEmacs.......some historical notes

    What's Different?...........new or changed capabilities

    XEmacs Release Notes........details of the changes between releases

New users should look at the next section on "Using Outline Mode".  You will
be more efficient when you can navigate quickly through this file.  Users
interested in some of the details of how XEmacs differs from FSF GNU Emacs
should read the section "What's Different?".  Users who would to know which
capabilities have been introduced in each release should look at the
appropriate subsection of the "XEmacs Release Notes."

    N.B.  The term "FSF GNU Emacs" refers to any release of Emacs Version 19
    from the Free Software Foundation's GNU Project.  The term "XEmacs"
    refers to this program or to its predecessors "Era" and "Lucid Emacs".
    The predecessor of all these program is called "Emacs 18".  When no
    particular version is implied, "Emacs" will be used.


* Using Outline Mode
====================

This file is in outline mode, a major mode for viewing (or editing)
outlines.  It allows you to make parts of the text temporarily invisible so
that you can see just the overall structure of the outline.

There are two ways of using outline mode:  with keys or with menus.  Using
outline mode with menus is the simplest and is just as effective as using
keystrokes.  There are menus for outline mode on the menubar as well as in
popup menus activated by pressing mouse button 3.

Experiment with the menu commands.  Menu items under "Headings" allow
you to navigate from heading to heading.  Menu items under "Show" make
visible portions of the outline while menu items under "Hide" do the
opposite.

A special minor mode called "outl-mouse" has been automatically enabled.  In
this minor mode, gylphs appear which, when clicked on, will alternately hide
or show sections of the outline.

You may at any time press `C-h m' to get a listing of the outline mode key
bindings.  They are reproduced here:

Commands:
C-c C-n   outline-next-visible-heading      move by visible headings
C-c C-p   outline-previous-visible-heading
C-c C-f   outline-forward-same-level        similar but skip subheadings
C-c C-b   outline-backward-same-level
C-c C-u   outline-up-heading		    move from subheading to heading

C-c C-t	make all text invisible (not headings).
M-x show-all	make everything in buffer visible.

The remaining commands are used when point is on a heading line.
They apply to some of the body or subheadings of that heading.
C-c C-d   hide-subtree	make body and subheadings invisible.
C-c C-s   show-subtree	make body and subheadings visible.
C-c tab   show-children	make direct subheadings visible.
		 No effect on body, or subheadings 2 or more levels down.
		 With arg N, affects subheadings N levels down.
C-c C-c	   make immediately following body invisible.
C-c C-e	   make it visible.
C-c C-l	   make body under heading and under its subheadings invisible.
		     The subheadings remain visible.
C-c C-k  make all subheadings at all levels visible.x1


* The History of XEmacs
=======================

This product is an extension of GNU Emacs, previously known to some as
"Lucid Emacs", "Xemacs", or "Era".  It is based on an early version of Emacs
Version 19 from the Free Software Foundation, and stems from a collaboration
of Lucid, Inc. with SunPro (a division of Sun Microsystems, Inc.) and the
University of Illinois.

** Why Another Version of Emacs?  (The Lucid, Inc. Point of View)
=================================================================

Lucid's latest product, Energize, is a C/C++ development environment.
Rather than invent (and force our users to learn) a new user-interface, we
chose to build part of our environment on top of the world's best editor,
FSF GNU Emacs.  (Though our product is commercial, the work we did on is
free software, and is useful without having to purchase our product.)

We needed a version of Emacs with mouse-sensitive regions, multiple fonts,
the ability to mark sections of a buffer as read-only, the ability to detect
which parts of a buffer has been modified, and many other features.

*** Why Not Epoch or FSF GNU Emacs?
-----------------------------------

For our purposes, the existing version of Epoch was not sufficient; it did
not allow us to put arbitrary pixmaps/icons in buffers, `undo' did not
restore changes to regions, regions did not overlap and merge their
attributes in the way we needed, and several other things.

We could have devoted our time to making Epoch do what we needed (and, in
fact, we spent some time doing that in 1990) but, since the Free Software
Foundation planned to include Epoch-like features in their Version 19, we
decided that our efforts would be better spent improving FSF GNU Emacs
instead of Epoch.

Our original hope was that our changes to FSF GNU Emacs would be
incorporated into the "official" v19.  However, scheduling conflicts arose,
and we found that, given the amount of work still remaining to be done, we
didn't have the time or manpower to do the level of coordination that would
be necessary to get our changes accepted by the Free Software Foundation.
Consequently, we released our work as a forked branch of Emacs, instead of
delaying any longer.

Roughly a year after Lucid Emacs 19.0 was released, a beta version of the
Free Software Foundation branch of Emacs 19 was released.  This version
was better in some areas, and worse in others, as reflects the differing
focus of our development efforts.

We planned to continue developing and supporting Lucid Emacs, and merging in
bug fixes and new features from the Free Software Foundation branch as
appropriate; we did not plan to discard any of the functionality that we
implemented which Richard Stallman of the Free Software Foundation has
chosen not to include in his version.

However, events have overtaken us, and Lucid, Inc. has effectively ceased
doing business and is (September 1994) in the process of being sold.  Our
efforts on Lucid Emacs have also ceased and we've turned over the continued
enhancement of Lucid Emacs to the University of Illinois under Chuck
Thompson, a member of the Lucid Emacs team and a maintainer of Epoch.
At the same time, Lucid Emacs has been renamed XEmacs to reflect the
substantial contribution of the University of Illinois with the support of
Sun Microsystems.

Certain elements of Lucid Emacs, or derivatives of them, have been ported to
the FSF GNU Emacs.  We have not been doing work in this direction, because
we feel that Lucid Emacs has a cleaner and more extensible substrate, and
that any kind of merger between the two branches would be far easier by
merging the Free Software Foundation changes into our version than the other
way around.

We were working closely with the Epoch developers to merge in the
remaining Epoch functionality which Lucid Emacs does not yet have.  Epoch
and Lucid Emacs will soon be one and the same thing.  Work is being done on
a compatibility package which will allow Epoch 4 code to run in XEmacs with
little or no change.  (As of 19.8, Lucid Emacs is running a descendant of
the Epoch redisplay engine.)

** Why Another Version of Emacs?  (The SunPro Point of View)
============================================================

Emacs 18 has been around for a long, long time.  Version 19 was supposed to
be the successor to Emacs 18 with X support.  It was going to be available
"real soon" for a long time (some people remember hearing about v19 as early
as 1984!), but it never came out.  v19 development was going very, very
slowly, and from the outside it seemed that it was not moving at all.  In
the meantime other people gave up waiting for v19 and decided to build their
own X-aware Emacsen.  The most important of these was probably Epoch, which
came from the University of Illinois and was based on v18.

Around two years ago we decided that we wanted an integrated editor.  We
contracted with the University of Illinois to provide a number of basic
enhancements to the functionality in Epoch.  The University of Illinois
initially was planning to deliver this on top of Epoch code.

In the meantime (actually some time before we talked with the University of
Illinois) Lucid had decided that it also wanted to provide an integrated
environment with an integrated editor.  Lucid decided that the Version 19
basis was a better one than Version 18 and thus decided not to use Epoch but
instead work with Richard Stallman, the head of the Free Software Foundation
and principle author of Emacs, on getting Version 19 out.  At some point
Stallman and Lucid parted ways.  Lucid kept working and got a Version 19 out
that they called Lucid Emacs 19.

After Lucid's v19 came out it became clear to us (the University of Illinois
and SunPro) that the right thing to do was to push for an integration of
both Lucid Emacs and Epoch, and to get the deliverables that we were asking
from the University of Illinois on top of this integrated platform.  Through
the last two years, SunPro has been actively supporting this product and has
been investing a comparable amount of effort into it as Lucid has.
Substantial portions of the current code have originated under the support
of SunPro, either directly in SunPro, or in the University of Illinois but
paid for by us.  This code was kept away from Lucid for a while, but later
was made available to them.  Initially Lucid didn't know that we were
supporting UofI, but later we were open about it.

Currently, there is basically no difference in the source trees between what
is at the University of Illinois, SunPro, or Lucid.  All the development
sites are in sync.

SunPro originally called the integrated product ERA, for "Emacs Rewritten
Again".  SunPro and Lucid recently came to an agreement to find a name for
the product that was not specific to either company.  An additional
constraint that Lucid placed on the name was that it must contain the word
"Emacs" in it -- thus "ERA" is not acceptable.  The agreed-upon name is
"XEmacs", and this is what the product will be called starting with the
19.11 release.


* What's Different?
===================

Unless otherwise noted, this section describes differences between XEmacs
version 19.* and GNU Emacs version 18.57.

XEmacs *currently* requires an X Window System environment to run.  TTY
support is currently being worked on.  It will be included in the 19.12
release.

Auto-configure support has been added, so it should be fairly easy to compile
XEmacs on different systems.  If you have any problems or feedback about
compiling on your system, please let us know.

We have reimplemented the basic input model in a more general way; instead of
X input being a special-case of the normal ASCII input stream, Emacs has a
concept of "input events", and ASCII characters are a subset of that.  The
events that Emacs knows about are not X events, but are a generalization of
them, so that Emacs can eventually be ported to different window systems.

We have reimplemented keymaps so that sequences of events can be stored into
them instead of just ASCII codes; it is possible to, for example, bind
different commands to each of the chords Control-h, Control-H, Backspace,
Control-Backspace, and Super-Shift-Backspace.  Key bindings, function key
bindings, and mouse bindings live in the same keymaps.

Input and display of all ISO-8859-1 characters is supported.

You can have multiple X windows ("screens" in xemacs terminology).

Our Emacs has objects called "extents" and "faces", which are roughly
analogous to Epoch's "buttons," "zones," and "styles."  An extent is a region
of text (a start position and an end position) and a face is a collection of
textual attributes like fonts and colors.  Every extent is displayed in some
"face", so changing the properties of a face immediately updates the display 
of all associated extents.  Faces can be screen-local: you can have a region
of text which displays with completely different attributes when its buffer
is viewed from a different X window.

The display attributes of faces may be specified either in lisp or through
the X resource manager.

Pixmaps of arbitrary size can be embedded in a buffer.

Variable width fonts work.

The height of a line is the height of the tallest font on that line, instead
of all lines having the same height.

Emacs use 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 Emacs
window.  Also, Emacs understands the standard Xt command-line arguments.

Emacs understands the X11 "Selection" mechanism; it's possible to define
and customize selection converter functions and new selection types from 
Emacs Lisp, without having to recompile Emacs.

Emacs provides support for ToolTalk on systems that have it.

Emacs now supports the Zmacs/Lispm style of region highlighting, where the
region between the point and mark is highlighted when in its "active" state.

Emacs has a menubar, whose contents are customizable from emacs-lisp.
This menubar looks Motif-ish, but does not require Motif.  If you already
own Motif, however, you can configure Emacs to use a *real* Motif menubar
instead.  If you have OLIT ("OpenLook Intrinsics"), you can use an
OpenWindows-like menubar.

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

Emacs has vertical scrollbars.

The initial load-path is computed at run-time, instead of at compile-time.
This means that if you move the Emacs executable and associated directories
to somewhere else, you don't have to recompile anything.

You can specify what the title of the Emacs windows and icons should be
with the variables `screen-title-format' and `screen-icon-title-format',
which have the same syntax as `mode-line-format'.

Emacs now supports floating-point numbers.

Emacs now knows about timers directly, instead of them being simulated by
a subprocess.

Emacs understands truenames, and can be configured to notice when you are
visiting two names of the same file.  See the variables find-file-use-truenames
and find-file-compare-truenames.

If you're running on a machine with audio hardware, you can specify sound 
files for Emacs to play instead of the default X beep.  See the documentation
of the function load-sound-file and the variable sound-alist.

An Emacs screen can be placed within an "external client widget" managed by
another application.  This allows an application to use an Emacs screen as its
text pane rather than the standard Text widget that is provided with Motif or
Athena.  Emacs supports Motif applications, generic Xt (e.g. Athena)
applications, and raw Xlib applications.

Random changes to the emacs-lisp library: (some of this was not written by
us, but is included because it's free software and we think it's good stuff)

  - there is a new optimizing byte-compiler
  - there is a new abbrev-based mail-alias mechanism
  - the -*- line can contain local-variable settings
  - there is a new TAGS package
  - there is a new VI-emulation mode (evi)
  - there is a new implementation of Dired
  - there is a new implementation of Isearch
  - the VM package for reading mail is provided
  - the W3 package for browsing the World Wide Web hypertext information
    system is provided

There are many more specifics in the "Miscellaneous Changes" section, below.

The online Emacs Manual and Emacs-Lisp Manual are now both relatively
up-to-date.

** Differences between XEmacs 19 and FSF Emacs 19
=================================================

In XEmacs, events are first-class objects.  FSF19 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.  FSF19 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, Emacs 18, and and FSF Emacs 19; if your code depends on
the underlying implementation of keymaps, it will not.

XEmacs calls a top-level emacs X window a "screen," which is the terminology
that Epoch used.  FSF 19 calls these "frames."  We may adopt the term "frame"
as well, but we have not done so yet.

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

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

Here are some more specifics about the XEmacs implementation:

*** The Input Model
-------------------

The fundamental unit of input is an "event" instead of a character.  An
event is a new data type that contains several pieces of information.
There are several kinds of event, and corresponding accessor and utility
functions.  We tried to abstract them so that they would apply equally
well to a number of window systems.

 key_press_event        
    event_channel       A token representing which keyboard generated it.
                        For this kind of event, this is a screen object.
                        (This is for eventual support of multiple displays.)
    timestamp           When it happened
    key                 What keysym this is; an integer or a symbol.
                        If this is an integer, it will be in the printing
                        ASCII range: >32 and <127.
    modifiers           Bucky-bits on that key: control, meta, etc.
                        For most keys, Shift is not a bit; that is implicit
                        in the keyboard layout.
 button_press_event
 button_release_event
    event_channel       A token representing which mouse generated it.
                        For this kind of event, this is a screen object.
    timestamp           When it happened
    button              What button went down or up.
    modifiers           Bucky-bits on that button: shift, control, meta, etc.
    x, y                Where it was at the button-state-change (in pixels).

 pointer_motion_event
    event_channel       A token representing which mouse generated it.
                        For this kind of event, this is a screen object.
    timestamp           When it happened
    x, y                Where it was after it moved (in pixels).

 process_event
    timestamp           When it happened
    process             the emacs "process" object in question

 timeout_event
    timestamp           Now (really, when the timeout was signalled)
    function            The Emacs Lisp function to call for this timeout.
    	    	        It is called with one argument, the event.
    object              Some lisp object associated with this timeout, to
                        make it easier to tell them apart.

 eval_event
    timestamp           When it happened.
    function            An Emacs Lisp function to call with this event object.
    object              Anything.
                        This kind of event is used internally; sometimes the
                        window system interface would like to inform Emacs of
                        some user action (such as focusing on another screen)
                        but needs that to happen synchronously with the other
                        user input, like key presses.

 menu_event
    timestamp           When it happened.
    function            An Emacs Lisp function to call with this event object.
    object              Anything.
                        This is similar to an eval_event, except that it is
                        generated by selections in the menubar.  It is a
                        "command" event, like key and mouse presses (and 
                        unlike mouse motion, process output, and enter and
                        leave window hooks.)  In many ways, eval_events are
                        not the same as key- or menu-events.

 magic_event
                        No user-serviceable parts within.  This is for things
                        like KeymapNotify and ExposeRegion events and so on
                        that Emacs itself doesn't care about, but which it
                        must do something with for proper interaction with
                        the window system.

                        Magic_events are handled somewhat asynchronously, just
                        like subprocess filters.  However, occasionally a 
                        magic_event needs to be handled synchronously; in that
                        case, the asynchronous handling of the magic_event will
                        push an eval_event back onto the queue, which will be 
                        handled synchronously later.  This is why eval_events
                        exist.

The function `next-event' blocks and returns one of the above-described 
event objects.  The function `dispatch-event' takes an event and processes
it in the appropriate way.

For a process-event, dispatch-event calls the process's handler; for a
mouse-motion event, the mouse-motion-handler hook is called, and so on.
For magic-events, dispatch-event does window-system-dependent things,
including calling some non-window-system-dependent hooks: map-screen-hook,
unmap-screen-hook, mouse-enter-screen-hook, and mouse-leave-screen-hook.

The function `next-command-event' calls `next-event' until it gets a key or
button from the user (that is, not a process, motion, timeout, or magic
event).  If it gets an event that is not a key or button, it calls
`dispatch-event' on it immediately and reads another one.  The
next-command-event function could be implemented in Emacs Lisp, though it
isn't.  Generally one should call `next-command-event' instead of
`next-event'.

read-char calls next-command-event; if it doesn't get an event that can be
converted to an ASCII character, it signals an error.  Otherwise it returns
an integer.

The variable `last-command-char' always contains an integer, or nil (if the
last read event has no ASCII equivalent, as when it is a mouse-click or a
non-ASCII character chord.)

The new variable `last-command-event' holds an event object, that could be
a non-ASCII character, a button click, a menu selection, etc.

The variable `unread-command-char' no longer exists, and has been replaced
by `unread-command-event'.  With the new event model, it is incorrect for
code to do (setq unread-command-char (read-char)), because all user-input
can't be represented as ASCII characters.  *** This is an incompatible 
change.  Code which sets `unread-command-char' must be updated to use the
combination of `next-command-event' and `unread-command-event' instead.

The functions `this-command-keys' and `recent-keys' return a vector of
event objects, instead of a string of ASCII characters.  *** This also
is an incompatible change.

Almost nothing happens at interrupt level; the SIGIO handler simply sets a
flag, and later, the X event queue is scanned for KeyPress events which map
to ^G.  All redisplay happens in the main thread of the process.

We envision the dumb-tty handler functions doing function-key handling at
the lowest level.  So the terminal-specific code would set up some data
structure that would cause the key sequences that some ttys generate for
function keys to be converted to 'f1 and so on before next-event saw them.
We haven't implemented dumb-tty handling yet, but we will soon.


*** Keymaps
-----------

Instead of keymaps being alists or obarrays, they are a new primary data
type.  The only user access to the contents of a keymap is through the
existing keymap-manipulation functions, and a new function, map-keymap.
This means that existing code that manipulates keymaps may need to 
be changed.

One of our goals with the new input and keymap code was to make more
character combinations available for binding, besides just ASCII and
function keys.  We want to be able bind different commands to Control-a 
and Control-Shift-a; we also want it to be possible for the keys Control-h
and Backspace (and Control-M and Return, and Control-I and Tab, etc) to
be distinct.

One of the most common complaints that new Emacs users have is that backspace
is help.  The answer is to play around with the keyboard-translate-table, or
be lucky enough to have a system administrator who has done this for you
already; but if it were possible to bind backspace and C-h to different
things, then (under a window manager at least) both backspace and delete
would delete a character, and ^H would be help.  There's no need to deal 
with xmodmap, kbd-translate-table, etc.

Here are some more examples: suppose you want to bind one function to Tab, 
and another to Control-Tab.  This can't be done if Tab and Control-I are the
same thing.  What about control keys that have no ASCII equivalent, like
Control-< ?  One might want that to be bound to set-mark-at-point-min.  We
want M-C-Backspace to be kill-backward-sexp.  But we want M-Backspace to be
kill-backward-word.  Again, this can't be done if Backspace and C-h are
indistinguishable.

The user represents keys as a string of ASCII characters (when possible and
convenient), or as a vector of event objects, or as a vector of "key 
description lists", that looks like (control a), or (control meta delete) 
or (shift f1).  The order of the modifier-names is not significant, so
(meta control x) and (control meta x) are the same.

Define-key knows how to take any of the above representations and store them
into a keymap.  When Emacs wants to return a key sequence (this-command-keys,
recent-keys, keyboard-macros, and read-key-sequence, for example) it returns
a vector of event objects.  Keyboard macros can also be represented as ASCII
strings or as vectors of key description lists.  

This is an incompatible change: code which calls this-command-keys,
recent-keys, read-key-sequence, or manipulates keyboard-macros probably
needs to be changed so that it no longer assumes that the returned value
is a string.

Control-Shift-a is specified as (control A), not (control shift a), since A
is a two-case character.  But for keys that don't have an upper case
version, like F1, Backspace, and Escape, you use the (shift backspace) syntax.

See the doc string for our version of define-key, reproduced below in the
`Changed Functions' section.  Note that when the KEYS argument is a string,
it has the same semantics as the v18 define-key.


*** Xt Integration
------------------

The heart of the event loop is implemented in terms of the XtNextEvent,
and uses Xt's concept of timeouts and file-descriptor callbacks,
eliminating a large amount of system-dependent code (Xt does it for you.)

If Emacs is compiled with support for X, we plan to have it use the Xt
event loop even when Emacs is not running on an X display (the Xt event
loop supports this.)  This will make it possible to run Emacs on a dumb
tty, and later connect it to one or more X servers.  We hope also to make
it possible to later connect an existing Emacs process to additional ttys.
(Our intent at this point is not to have an Emacs that is being used by
multiple people at the same time: it is to make it possible for someone to
go home, log in on a dialup line, and connect to the same Emacs process
that is running under X in their office without having to recreate their
buffer state and so on.)

If Emacs is not compiled with support for X, then it will instead use
more general code, something like what v18 does; but this way of doing
things is a lot more modular.

(Linking Emacs with Xt seems to only add about 300k to the executable size,
compared with an Emacs linked with Xlib only.)


*** X Selections
----------------

We have reimplemented X Selection handling to be more general than before.
Almost all of it is implemented in emacs-lisp now, so it's possible to 
define new selection data types without having to recompile Emacs.  See
the documentation of the variables `selection-converter-alist', 
`x-lost-selection-hooks', `x-sent-selection-hooks', and the file
.../lisp/x11/xselect.el for more specifics.


*** Region Highlighting
-----------------------

If the variable `zmacs-regions' is true, then the region between point and
mark will be highlighted when "active".  Those commands which push a mark
(such as C-SPC, and ^X^X) make the region become "active" and thus
highlighted.  Most commands (all non-motion commands, basically) cause it to
become non-highlighted (non-"active").  Commands that operate on the region
(such as ^W, ^X^L, etc) only work if the region is in the highlighted state.

zmacs-activate-region-hook and zmacs-deactivate-region-hook are run at the
appropriate times; under X, zmacs-activate-region-hook makes the X selection
be the region between point and mark, thus doing two things at once: making
the region and the X selection be the same; and making the region highlight
in the same way as the X selection.

mark-marker: subr
Return this buffer's mark, as a marker object.
If `zmacs-regions' is true, then this returns nil unless the region is
currently in the active (highlighted) state.  With an argument of t, this
returns the mark (if there is one) regardless of the active-region state.
You should *generally* not use the mark unless the region is active, if
the user has expressed a preference for the active-region model.
Watch out!  Moving this marker changes the mark position.
If you set the marker not to point anywhere, the buffer will have no mark.

In this way, the primary selection is a fairly transitory entity; but
when something is copied to the kill ring, it is made the Clipboard
selection.  It is also stored into CUT_BUFFER0, for compatibility with
X applications that don't understand selections (like Emacs18).

Compatibility note: if you have code which uses (mark) or (mark-marker),
then you need to either: change those calls to (mark t) or (mark-marker t);
or simply bind `zmacs-regions' to nil around the call to mark or mark-marker.
This is probably the best solution, since it will work in Emacs 18 as well.


*** Menubars and Dialog Boxes
-----------------------------

Here is an example of a menubar definition:

(defvar default-menubar
  '(("File"     ["Open File..."         find-file               t]
                ["Save Buffer"          save-buffer             t]
                ["Save Buffer As..."    write-file              t]
                ["Revert Buffer"        revert-buffer           t]
                "-----"
                ["Print Buffer"         lpr-buffer              t]
                "-----"
                ["Delete Screen"        delete-screen           t]
                ["Kill Buffer..."       kill-buffer             t]
                ["Exit Emacs"           save-buffers-kill-emacs t]
                )
    ("Edit"     ["Undo"                 advertised-undo         t]
                ["Cut"                  kill-primary-selection  t]
                ["Copy"                 copy-primary-selection  t]
                ["Paste"                yank-clipboard-selection t]
                ["Clear"                delete-primary-selection t]
                )
    ...))

The first element of each menu item is the string to print on the menu.

The second element is the callback function; if it is a symbol, it is
invoked with `call-interactively.'  If it is a list, it is invoked with
`eval'.  

If the second element is a symbol, then the menu also displays the key that
is bound to that command (if any).

The third element of the menu items determines whether the item is selectable.
It may be t, nil, or a form to evaluate.  Also, a hook is run just before a
menu is exposed, which can be used to change the value of these slots. 
For example, there is a hook that makes the "undo" menu item be selectable
only in the cases when `advertised-undo' would not signal an error.  

Menus may have other menus nested within them; they will cascade.

There are utility functions for adding items to menus, deleting items,
disabling them, etc.

The function `popup-menu' takes a menu description and pops it up.  

The function `popup-dialog-box' takes a dialog-box description and pops 
it up.  Dialog box descriptions look a lot like menu descriptions.

The menubar, menu, and dialog-box code is implemented as a library, 
with an interface which hides the toolkit that implements it.  


*** Isearch Changes
-------------------

Isearch has been reimplemented in a different way, adding some new features,
and causing a few incompatible changes.

 -  the old isearch-*-char variables are no longer supported.  In the old
    system, one could make ^A mean "repeat the search" by doing something
    like (setq search-repeat-char ?C-a).  In the new system, this is 
    accomplished with 

       (define-key isearch-mode-map "\C-a" 'isearch-repeat-forward)

 -  The advantage of using the normal keymap mechanism for this is that you
    can bind more than one key to an isearch command: for example, both C-a
    and C-s could do the same thing inside isearch mode.  You can also bind
    multi-key sequences inside of isearch mode, and bind non-ASCII keys.
    For example, to use the F1 key to terminate a search:

       (define-key isearch-mode-map 'f1 'isearch-exit)

    or to make ``C-c C-c'' terminate a search:

       (define-key isearch-mode-map "\C-c\C-c" 'isearch-exit)

 -  If isearch is behaving case-insensitively (the default) and you type an
    upper case character, then the search will become case-sensitive.  This
    can be disabled by setting `search-caps-disable-folding' to nil.

 -  There is a history ring of the strings previously searched for; typing
    M-p or M-n while searching will cycle through this ring.  Typing M-TAB
    will do completion across the set of items in the history ring.

 -  The ESC key is no longer used to terminate an incremental search.  The
    RET key should be used instead.  This change is necessary for it to be
    possible to bind "meta" characters to isearch commands.


*** Startup Code Changes
------------------------

The initial X screen is mapped before the user's .emacs file is executed.
Without this, there is no way for the user to see any error messages
generated by their .emacs file, any windows created by the .emacs file
don't show up, and the copyleft notice isn't shown.

The default values for load-path, exec-path, lock-directory, and
Info-directory-list are not (necessarily) built into Emacs, but are
computed at startup time.  

First, Emacs looks at the directory in which its executable file resides:

  o  If that directory contains subdirectories named "lisp" and "lib-src",
     then those directories are used as the lisp library and exec directory.

  o  If the parent of the directory in which the emacs executable is located
     contains "lisp" and "lib-src" subdirectories, then those are used.

  o  If ../lib/xemacs-<version> (starting from the directory in which the
     emacs executable is located) contains a "lisp" subdirectory and either
     a "lib-src" subdirectory or a <configuration-name> subdirectory, then
     those are used.

  o  If the emacs executable that was run is a symbolic link, then the link
     is chased, and the resultant directory is checked as above.

(Actually, it doesn't just look for "lisp/", it looks for "lisp/prim/",
which reduces the chances of a false positive.)

If the lisp directory contains subdirectories, they are added to the default
load-path as well.  If the site-lisp directory exists and contains
subdirectories, they are then added.  Subdirectories whose names begin with
a dot or a hyphen are not added to the load-path.

These heuristics fail if the Emacs binary was copied from the main Emacs
tree to some other directory, and links for the lisp directory were not put
in.  This isn't much of a restriction: either make there be subdirectories
(or symbolic links) of the directory of the emacs executable, or make the
"installed" emacs executable be a symbolic link to an executable in a more
appropriate directory structure.  For example, this setup works:

    /usr/local/xemacs/xemacs*           ; The executable.
    /usr/local/xemacs/lisp/             ; The associated directories.
    /usr/local/xemacs/etc/              ; Any of the files in this list
    /usr/local/xemacs/lock/             ; could be symbolic links as well.
    /usr/local/xemacs/info/

As does this:

    /usr/local/bin/xemacs -> ../xemacs/src/xemacs-19.8  ; A link...
    /usr/local/xemacs/src/xemacs-19.8*                  ; The executable,
    /usr/local/xemacs/lisp/                             ; and the rest of
    /usr/local/xemacs/etc/                              ; the the source
    /usr/local/xemacs/lock/                             ; tree.
    /usr/local/xemacs/info/

This configuration might be used for a multi-architecture installation; assume
that $LOCAL refers to a directory which contains only files specific to a 
particular architecture (i.e., executables) and $SHARED refers to those files 
which are not machine specific (i.e., lisp code and documentation.)

    $LOCAL/bin/xemacs@ -> $LOCAL/lemacs-19.8/xemacs*
    $LOCAL/xemacs-19.8/lisp@ -> $SHARED/xemacs-19.8/lisp/
    $LOCAL/xemacs-19.8/etc@  -> $SHARED/xemacs-19.8/etc/
    $LOCAL/xemacs-19.8/info@ -> $SHARED/xemacs-19.8/info/

The following would also work, but the above is probably more attractive:

    $LOCAL/bin/xemacs*
    $LOCAL/bin/lisp@ -> $SHARED/xemacs-19.8/lisp/
    $LOCAL/bin/etc@  -> $SHARED/xemacs-19.8/etc/
    $LOCAL/bin/info@ -> $SHARED/xemacs-19.8/info/

If Emacs can't find the requisite directories, it writes a message like this
(or some appropriate subset of it) to stderr:

  WARNING:
  couldn't find an obvious default for load-path, exec-directory, and
  lock-directory, and there were no defaults specified in paths.h when
  Emacs was built.  Perhaps some directories don't exist, or the Emacs
  executable, /cadillac-th/jwz/somewhere/xemacs is in a strange place?

  Without both exec-directory and load-path, Emacs will be very broken.
  Consider making a symbolic link from /cadillac-th/jwz/somewhere/etc
  to wherever the appropriate Emacs etc/ directory is, and from
  /cadillac-th/jwz/somewhere/lisp/ to wherever the appropriate Emacs
  lisp library is.

  Without lock-directory set, file locking won't work.  Consider
  creating /cadillac-th/jwz/somewhere/lock as a directory or symbolic
  link for use as the lock directory.

The default installation tree is the following:

    /usr/local/bin/b2m                          ;
                   ctags                        ; executables that
                   emacsclient                  ; should be in
                   etags                        ; user's path
                   xemacs -> xemacs-<version>   ;
                   xemacs                       ;
    /usr/local/lib/xemacs/site-lisp
    /usr/local/lib/xemacs/lock
    /usr/local/lib/xemacs-<version>/etc         ; architecture ind. files
    /usr/local/lib/xemacs-<version>/info
    /usr/local/lib/xemacs-<version>/lisp
    /usr/local/lib/xemacs-<version>/<configuration>  ; binaries emacs may run


*** X Resources
---------------

The Emacs resources are generally per-screen.  Each Emacs screen can have its
own name, or the same name as another, depending on the name passed to the
x-create-screen function.  

You can specify resources for all screens with the syntax

        Emacs*parameter: value
or
        Emacs*EmacsScreen.parameter: value

You can specify resources for a particular screen with the syntax

        Emacs*SCREEN-NAME.parameter: value


To make the default size of all emacs be 80 columns by 55 lines, do this:

        Emacs*EmacsScreen.geometry: 80x55

To set the geometry of a particular screen named, "foo", do this:

        Emacs*foo.geometry: 80x55

In particular, do --NOT-- use this syntax:

        Emacs*geometry: 80x55

One should never use "*geometry" with any X application.  It does not say
"make the geometry of emacs be 80 columns by 55 lines."  It really says,
"make emacs and all subwindows thereof be 80x55 in whatever units they care
to measure in."  In particular, that is both telling the emacs text pane
to be 80x55 in characters, and telling the menubar pane to be 80x55 pixels,
which is surely not what you want.


Generally, all of the interesting resources are on the EmacsScreen widget.
However, the `geometry' and `iconic' resources on the unmapped ApplicationShell
(the topmost widget, the parent of the WM shell widgets, named `Emacs') are a
special case.  

The simple explanation is, -geometry overrides the resources of only the first 
screen created, otherwise "Emacs*SCREEN-NAME.geometry" is used.

The complicated explanation is:

  - The -geometry command line option sets the "Emacs.geometry" resource, that
    is, the geometry of the ApplicationShell.

  - For the first screen created, the size of the screen is taken from the 
    AppShell if it is specified, otherwise from the geometry of the screen.  

  - For subsequent screens, the order is reversed: first the screen, and then
    the AppShell.

  - For the first screen created, the position of the screen is taken from the
    AppShell ("Emacs.geometry") if it is specified, otherwise from the geometry
    of the screen.  

  - For subsequent screens, the position is taken only from the screen, and 
    never from the AppShell.

  This is rather complicated, but it does seem to provide the most intuitive
  behavior with respect to the default sizes and positions of screens created
  in various ways.

Analogous to -geometry, the -iconic command line option sets the iconic flag
of the AppShell ("Emacs.iconic") and always applies to the first screen created
regardless of its name.  However, it is possible to set the iconic flag on 
particular screens (by name) by using the "Emacs*SCREEN-NAME.iconic" resource.


Emacs screens accept the following resources:

  iconic (class Iconic): boolean

        Whether this screen should appear in the iconified state.

  internalBorderWidth (class InternalBorderWidth): int

        How many blank pixels to leave between the text and the edge of the
        window.

  interline (class Interline): int

        How many pixels to leave between each line.

  cursorColor (class CursorColor): color

        The color of the text cursor.

  textPointer (class Cursor): cursor-name

        The cursor to use when the mouse is over text.  This resource is
        used to initialize the variable `x-pointer-shape'.

  spacePointer (class Cursor): cursor-name

        The cursor to use when the mouse is over a blank space in a buffer
        (that is, after the end of a line or after the end-of-file).  This
        resource is used to initialize the variable `x-nontext-pointer-shape'.

  modePointer (class Cursor): cursor-name

        The cursor to use when the mouse is over a modeline.  This resource
        is used to initialize the variable `x-mode-pointer-shape'.

  gcPointer (class Cursor): cursor-name

        The cursor to display when a garbage-collection is in progress.  This
        resource is used to initialize the variable `x-gc-pointer-shape'.

  pointerColor (class Foreground): color-name

        The foreground and background colors of the mouse cursors.  
        These resources are used to initialize the variables 
        `x-pointer-foreground-color' and `x-pointer-background-color'.

  scrollBarWidth (class ScrollBarWidth): pixels
        How wide the scrollbars should be; 0 means no scrollbars.
        You can also use the usual toolkit scrollbar resources for this:
        "*XmScrollBar.width" (Motif) or "*Scrollbar.thickness" (Athena).

The attributes of faces are also per-screen.  They may be specified as

        Emacs*FACE-NAME.parameter: value
or
        Emacs*SCREEN-NAME.FACE-NAME.parameter: value

Faces accept the following resources:

  attributeFont (class AttributeFont): font-name

        The font of this face.

  attributeForeground (class AttributeForeground): color-name
  attributeBackground (class AttributeBackground): color-name

        The foreground and background colors of this face.

  attributeBackgroundPixmap (class attributeBackgroundPixmap): file-name

        The name of an XBM file, to use as a background stipple.

  attributeUnderline (class AttributeUnderline): boolean

        Whether text in this face should be underlined.

All text is displayed in some face, defaulting to the face named "default".
So to set the font of normal text, use "Emacs*default.attributeFont".
To set it in the screen named "foo", use "Emacs*foo.default.attributeFont".

These are the names of the predefined faces:

        default                 Everything inherits from this.

        highlight               This is used to highlight certain extents 
                                when the mouse passes over them.

        bold                    If this is not specified in the resource
                                database, Emacs tries to find a "bold" 
                                version of the font of the "default" face.

        italic                  ditto.

        bold-italic             ditto.

        primary-selection       This is the face that mouse-selections are
                                displayed in.

        isearch                 This is the face that the matched text being
                                searched for is displayed in.

        info-node               This is the face of info menu items.  If
                                unspecified, it is copied from "bold-italic".

        info-xref               This is the face of info cross-references.
                                If unspecified, it is copied from "bold".

Other packages might define their own faces; to see a list of all faces, use
any of the interactive face-manipulation commands such as `set-face-font') and
type `?' when you are prompted for the name of a face.

If the bold, italic, and bold-italic faces are not specified in the resource
database, then emacs attempts to derive them from the font of the default face.
It can only succeed at this if you have specified the default font using the
XLFD (X Logical Font Description) format, which looks like

        *-courier-medium-r-*-*-*-120-*-*-*-*-*-*

if you use any of the other, less strict font name formats, some of which
look like
                lucidasanstypewriter-12
and             fixed
and             9x13

then emacs won't be able to guess the names of the bold and italic versions.
All X fonts can be referred to via XLFD-style names, so you should use those
forms.  See the man pages for X(1), xlsfonts(1), and xfontsel(1).


There are several structural widgets between the terminal EmacsScreen widget
and the top level ApplicationShell; the exact names and types of these widgets
are subject to change in the future, so you should avoid mentioning them in
your resource database.  The above-mentioned syntaxes should be forward-
compatible.  As of 19.9, the exact widget hierarchy is as follows:

For Motif:
---------
   invocation-name            "shell"          "pane"          screen-name
   x-emacs-application-class  "TopLevelShell"  "XmMainWindow"  "EmacsScreen"

For Athena:
-----------
   invocation-name            "shell"          "pane"   "pane"   screen-name
   x-emacs-application-class  "TopLevelShell"  "Paned"  "Paned"  "EmacsScreen"

where `invocation-name' is the terminal component of the name of the emacs
executable, and `x-emacs-application-class' is generally "Emacs".

Since, as you see, the exact widget hierarchy depends on the toolkit in use,
and is subject to change in the future, it is best to use wildcards instead of
fully specifying the path of the resource you want to st.

Here is the hierarchy including the other widgets:

        Widget Name:            Athena Class:       Motif Class:
        ------------            -------------       ------------
        xemacs                  Emacs               Emacs
          shell                 TopLevelShell       TopLevelShell
            pane                Paned               XmMainWindow
              menubar           XlwMenu             XmMenuBar
              lower_pane        Paned               *
                screen-name     EmacsScreen         EmacsScreen
                sb_container    Paned               XmPanedWindow
                  scrollbar     Scrollbar           XmScrollBar
            dialog              XtPopupShell        XmDialogShell
              label             Label               XmLabel
              button1 ...       Command             XmPushbutton

  * Note that the "lower_pane" widget exists only in Athena versions;
    in Motif versions, both the "menubar" and `screen-name' widgets
    are children of the "pane".

As the menubar is implemented as a widget which is not a part of emacs proper,
it does not use the "face" mechanism for specifying fonts and colors: it uses
whatever resources are appropriate to the type of widget which is used to
implement it.

If Emacs was compiled to use only the Motif-lookalike menu widgets, then one
way to specify the font of the menubar would be

        Emacs*menubar*font: *-courier-medium-r-*-*-*-120-*-*-*-*-*-*

If the Motif library is being used, then one would have to use 

        Emacs*menubar*fontList: *-courier-medium-r-*-*-*-120-*-*-*-*-*-*

because the Motif library uses the "fontList" resource name instead of "font",
which has subtly different semantics.

The same is true of the scrollbars: they accept whichever resources are 
appropriate to the toolkit in use.


*** Source Code Highlighting
----------------------------

It's possible to have your buffers "decorated" with fonts or colors
indicating syntactic structures (such as strings, comments, function names,
"reserved words", etc.)  In XEmacs, the preferred way to do this is with
font-lock-mode; activate it by adding the following code to your .emacs file:

        (add-hook 'emacs-lisp-mode-hook 'turn-on-font-lock)
        (add-hook 'c-mode-hook          'turn-on-font-lock)
        (add-hook 'c++-mode-hook        'turn-on-font-lock)
        (add-hook 'dired-mode-hook      'turn-on-font-lock)
        ...etc...

To customize it, see the descriptions of the function `font-lock-mode' and
the variables `font-lock-keywords', `c-font-lock-keywords', etc.

There exist several other source code highlighting packages, but font-lock
does does one thing that most others don't do: highlights as you type new
text; and one thing that no others do: bases part of its decoration on the
syntax table of the major mode.  Font-lock has C-level support to do this
efficiently, so it should also be significantly faster than the others.

If there's something that another highlighting package does that you can't
make font-lock do, let us know.  We would prefer to consolidate all of the
desired functionality into one package rather than ship several different
packages which do essentially the same thing in different ways.



* XEmacs Release Notes
======================

** Major Differences Between 19.10 and 19.11
============================================
  
The name has changed from "Lucid Emacs" to "XEmacs".  Along with this is a
new canonical ftp site: cs.uiuc.edu:/pub/xemacs.

XEmacs now has its very own World Wide Web page!  It contains a
complete list of the FTP distribution sites, the most recent FAQ,
pointers to Emacs Lisp packages not included with the distribution, and
other useful stuff.  Check it out at http://xemacs.cs.uiuc.edu/.

A preliminary New Users Guide.

cc-mode.el now provides the default C and C++ modes.

The primary goal of this release is stability.  Very few new features have
been introduced but lots of bugs have been fixed.  Many of the Emacs Lisp
packages have been updated.

Some of the new Emacs Lisp packages ---

tcl-mode.el:  major mode for editing TCL code

fast-lock.el: saves and restores font-lock highlighting, greatly
            reducing the time necessary for loading a font-lock'ed
            file

ps-print.el: prints buffers to Postscript printers preserving the
           buffer's bold and italic text attributes

toolbar.el: provides a "fake" toolbar for use with XEmacs (an
          integrated one will be included with 19.12)


** Major Differences Between 19.9 and 19.10
===========================================

The GNU `configure' system is now used to build xemacs.

The Emacs Manual and Emacs Lisp Reference Manual now document version 19.10.
If you notice any errors, please let us know.

When pixmaps are displayed in a buffer, they contribute to the line height -
that is, if the glyph is taller than the rest of the text on the line, the
line will be as tall as necessary to display the glyph.

In addition to using arbitrary sound files as emacs beeps, one can control
the pitch and duration of the standard X beep, on X servers which allow that
(Note: most don't.)

There is support for playing sounds on systems with NetAudio servers.

Minor modes may have mode-specific key bindings; keymaps may have an arbitrary
number of parent maps.

Menus can have toggle and radio buttons in them.

There is a font selection menu.

Some default key bindings have changed to match FSF19; the new bindings are

  Screen-related commands:
        C-x 5 2                 make-screen
        C-x 5 0                 delete-screen
        C-x 5 b                 switch-to-buffer-other-screen
        C-x 5 f                 find-file-other-screen
        C-x 5 C-f               find-file-other-screen
        C-x 5 m                 mail-other-screen
        C-x 5 o                 other-screen
        C-x 5 r                 find-file-read-only-other-screen
  Abbrev-related commands:
        C-x a l                 add-mode-abbrev
        C-x a C-a               add-mode-abbrev
        C-x a g                 add-global-abbrev
        C-x a +                 add-mode-abbrev
        C-x a i g               inverse-add-global-abbrev
        C-x a i l               inverse-add-mode-abbrev
        C-x a -                 inverse-add-global-abbrev
        C-x a e                 expand-abbrev
        C-x a '                 expand-abbrev
  Register-related commands:
        C-x r C-SPC             point-to-register
        C-x r SPC               point-to-register
        C-x r j                 jump-to-register
        C-x r s                 copy-to-register
        C-x r x                 copy-to-register
        C-x r i                 insert-register
        C-x r g                 insert-register
        C-x r r                 copy-rectangle-to-register
        C-x r c                 clear-rectangle
        C-x r k                 kill-rectangle
        C-x r y                 yank-rectangle
        C-x r o                 open-rectangle
        C-x r t                 string-rectangle
        C-x r w                 window-configuration-to-register
  Narrowing-related commands:
        C-x n n                 narrow-to-region
        C-x n w                 widen
  Other changes:
        C-x 3                   split-window-horizontally (was undefined)
        C-x -                   shrink-window-if-larger-than-buffer
        C-x +                   balance-windows

The variable allow-deletion-of-last-visible-screen has been removed, since 
it was widely hated.  You can now always delete the last visible screen if
there are other iconified screens in existence.

ToolTalk support is provided.

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

Additional compatibility with Epoch is provided (though this is not yet
complete.)


** Major Differences Between 19.8 and 19.9
==========================================

Scrollbars!  If you have Motif, these are real Motif scrollbars; otherwise,
Athena scrollbars are used.  They obey all the usual resources of their
respective toolkits.

There is now an implementation of dialog boxes based based on the Athena
widgets, as well as the existing Motif implementation.

This release works with Motif 1.2 as well as 1.1.  If you link with Motif, 
you do not also need to link with Athena.

If you compile lwlib with both USE_MOTIF and USE_LUCID defined (which is the
recommended configuration) then the Lucid menus will draw text using the Motif
string-drawing library, instead of the Xlib one.  The reason for this is that
one can take advantage of the XmString facilities for including non-Latin1
characters in resource specifications.  However, this is a user-visible change
in that, in this configuration, the menubar will use the "*fontList" resource 
in preference to the "*font" resource, if it is set.

It's possible to make extents which are copied/pasted by kill and undo.
There is an implementation of FSF19-style text properties based on this.

There is a new variable, minibuffer-max-depth, which is intended to circumvent
a common source of confusion among new Emacs users.  Since, under a window
system, it's easy to jump out of the minibuffer (by doing M-x, then getting
distracted, and clicking elsewhere) many, many novice users have had the
problem of having multiple minibuffers build up, even to the point of
exhausting the lisp stack.  So the default behavior is to disallow the
minibuffer to ever be reinvoked while active; if you attempt to do so, you
will be prompted about it.

There is a new variable, teach-extended-commands-p, which if set, will cause
`M-x' to remind you of any key bindings of the command you just invoked the
"long way."

There are menus in Dired, Tar, Comint, Compile, and Grep modes.

There is a menu of window management commands on the right mouse button over
the modelines.

Popup menus now have titles at the top; this is controlled by the new 
variable `popup-menu-titles'.

The `Find' key on Sun keyboards will search for the next (or previous)
occurrence of the selected text, as in OpenWindows programs.

The `timer' package has been renamed to `itimer' to avoid a conflict with
a different package called `timer'.

VM 5.40 is included.

W3, the emacs interface to the World Wide Web, is included.

Felix Lee's GNUS speedups have been installed, including his new version of
nntp.el which makes GNUS efficiently utilize the NNTP XOVER command if
available (which is much faster.)  

GNUS should also be much friendlier to new users: it starts up much faster,
and doesn't (necessarily) subscribe you to every single newsgroup.

The byte-compiler issues a new class of warnings: variables which are
bound but not used.  This is merely an advisory, and does not mean the
code is incorrect; you can disable these warnings in the usual way with
the `byte-compiler-options' macro.

the `start-open' and `end-open' extent properties, for specifying whether
characters inserted exactly at a boundary of an extent should go into the
extent or out of it, now work correctly.

The `extent-data' slot has been generalized/replaced with a property list,
so it's easier to attach arbitrary data to extent objects.

The `event-modifiers' and `event-modifier-bits' functions work on motion
events as well as other mouse and keyboard events.

Forms-mode uses fonts and read-only regions.

The behavior of the -geometry command line option should be correct now.

The `iconic' screen parameter works when passed to x-create-screen.

The user's manual now documents Lucid Emacs 19.9.

The relocating buffer allocator is turned on by default; this means that when
buffers are killed, their storage will be returned to the operating system, 
and the size of the emacs process will shrink.

CAVEAT: code which contains calls to certain `face' accessor functions will
need to be recompiled by version 19.9 before it will work.  The functions
whose callers must be recompiled are: face-font, face-foreground,
face-background, face-background-pixmap, and face-underline-p.  The symptom
of this problem is the error "Wrong type argument, arrayp, #<face ... >".
The .elc files generated by version 19.9 will work in 19.6 and 19.8, but
older .elc files which contain calls to these functions will not work in 19.9.

Work In Progress:

 - We have been in the process of internationalizing XEmacs.  This code is
   ***not*** ready for general use yet.  However, the code is included (and
   turned off by default) in this release.

   - If you define I18N2 at compile-time, then sorting/collation will be done
     according to the locale returned by setlocale().

   - If you define I18N3 at compile-time, then all messages printed by xemacs
     will be filtered through the gettext() library routine, to enable the use
     of locale-specific translation catalogues.  The current implementation of
     this is quite dependent on Solaris 2, and has a very large impact on 
     existing code, therefore we are going to be making major changes soon.
     (You'll notice calls to `gettext' and `GETTEXT' scattered around much of
     the lisp and C code; ignore it, this will be going away.)

   - If you define I18N4 at compile-time, then xemacs will internally use a
     wide representation of characters, enabling the use of large character
     sets such as Kanji.  This code is very OS dependent: it requires X11R5, 
     and several OS-supplied library routines for reading and writing wide
     characters (getwc(), putwc(), and a few others.)  Performance is also a
     problem.  This code is also scheduled for a major overhaul, with the
     intent of improving performance and portability.  

     Our eventual goal is to merge with MULE, or at least provide the same base
     level of functionality.  If you would like to help out with this, let us 
     know.

 - Other work-in-progress includes Motif drag-and-drop support, ToolTalk 
   support, and support for embedding an Emacs widget inside another 
   application (where it can function as that other application's text-entry
   area).  This code has not been extensively tested, and may (or may not)
   have portability problems, but it's there for the adventurous.  Comments, 
   suggestions, bug reports, and especially fixes are welcome.  But have no
   expectations that this experimental code will work at all.


** Major Differences Between 19.6 and 19.8
==========================================

There were almost no differences between versions 19.6 and 19.7; version 19.7
was a bug-fix release that was distributed with Energize 2.1.

Lucid Emacs 19.8 represents the first stage of the Lucid Emacs/Epoch merger.
The redisplay engine now in xemacs is an improved descendant of the Epoch
redisplay.  As a result, many bugs have been eliminated, and several disabled
features have been re-enabled.  Notably:

Selective display (and outline-mode) work.

Horizontally split windows work.

The height of a line is the height of the tallest font displayed on that line;
it is possible for a screen to display lines of differing heights. (Previously,
the height of all lines was the height of the tallest font loaded.)

There is lisp code to scale fonts up and down, for example, to load the next-
taller version of a font.

There is a new internal representation for lisp objects, giving emacs-lisp 28
bit integers and a 28 bit address space, up from the previous maximum of 26.
We expect eventually to increase this to 30 bit integers and a 32 bit address
space, eliminating the need for DATA_SEG_BITS on some architectures.  (On 64
bit machines, add 32 to all of these numbers.)

GC performance is improved.

Various X objects (fonts, colors, cursors, pixmaps) are accessible as first-
class lisp objects, with finalization.

An alternate interface to embedding images in the text is provided, called
"annotations."  You may create an "annotation margin" which is whitespace at
the left side of the screen that contains only annotations, not buffer text.

When using XPM files, one can specify the values of logical color names to be
used when loading the files.

It is possible to resize windows by dragging their modelines up and down.  More
generally, it is possible to add bindings for mouse gestures on the modelines.

There is support for playing sound files on HP machines.

ILISP version 5.5 is included.

The Common Lisp #' read syntax is supported (#' is to "function" as ' is to
"quote".)

The `active-p' slot of menu items is now evaluated, so one can put arbitrary
lisp code in a menu to decide whether that item should be selectable, rather
than doing this with an `activate-menubar-hook'.

The X resource hierarchy has changed slightly, to be more consistent.  It used
to be
        argv[0]                 SCREEN-NAME     pane    screen
        ApplicationShell        EmacsShell      Paned   EmacsScreen

   now it is

        argv[0]                 shell           pane    SCREEN-NAME
        ApplicationShell        EmacsShell      Paned   EmacsScreen

The Lucid Emacs sources have been largely merged with FSF version 19; this
means that the lisp library contains the most recent releases of various
packages, and many new features of FSF 19 have been incorporated.

Because of this, the xemacs sources should also be substantially more portable.


** Major Differences Between 19.4 and 19.6
==========================================

There were almost no differences between versions 19.4 and 19.5; we fixed
a few minor bugs and repacked 19.4 as 19.5 for a CD-ROM that we gave away
as a trade show promotion.

The primary goal of the 19.6 release is stability, rather than improved
functionality, so there aren't many user-visible changes.  The most notable
changes are:

 - The -geometry command-line option now correctly overrides geometry
   specifications in the resource database.
 - The `width' and `height' screen-parameters work.
 - Font-lock-mode considers the comment start and end characters to be
   a part of the comment.
 - The lhilit package has been removed.  Use font-lock-mode instead.
 - vm-isearch has been fixed to work with isearch-mode.
 - new versions of ispell and calendar.
 - sccs.el has menus.

Lots of bugs were fixed, including the problem that xemacs occasionally
grabbed the keyboard focus.

Also, as of Lucid Emacs 19.6 and Energize 2.0 (shipping now) it is possible
to compile the public release of Lucid Emacs with support for Energize; so
now Energize users will be able to build their own Energize-aware versions
of xemacs, and will be able to use newer versions of xemacs as they are
released to the net.  (Of course, this is not behavior covered by your
Energize support contract; you do it at your own risk.)

I have not incorporated all portability patches that I have been sent since
19.4; I will try to get to them soon.  However, if you need to make any
changes to xemacs to get it to compile on your system, it would be quite
helpful if you would send me context diffs (diff -c) against version 19.6.


** Major Differences Between 19.3 and 19.4
==========================================

Prototypes have been added for all functions.  Emacs compiles in the strict
ANSI modes of lcc and gcc, so portability should be vastly improved.

Many many many many core leaks have been plugged, especially in screen 
creation and deletion.

The float support reworked to be more portable and ANSI conformant.  This
resulted in these new configuration parameters: HAVE_INVERSE_HYPERBOLIC, 
HAVE_CBRT, HAVE_RINT, FLOAT_CHECK_ERRNO, FLOAT_CATCH_SIGILL, 
FLOAT_CHECK_DOMAIN.  Let us know if you had to change the defaults on your
architecture.

The SunOS unexec has been rewritten, and now works with either static or 
dynamic libraries, depending on whether -Bstatic or -Bdynamic were specified
at link-time.

Small (character-sized) bitmaps can be mixed in with buffer text via the new
functions set-extent-begin-glyph and set-extent-end-glyph.  (This is actually
a piece of functionality that Energize has been using for a while, but we've
just gotten around to making it possible to use it without Energize.  See how
nice we are?  Go buy our product.)

If compiled with Motif support, one can pop up dialog boxes from emacs lisp.
We encourage someone to contribute Athena an version of this code; it
shouldn't be much work.  

If dialog boxes are available, then y-or-n-p and yes-or-no-p use dialog boxes
instead of the minibuffer if invoked as a result of a command that was 
executed from a menu instead of from the keyboard.

Multiple screen support works better; check out doc of get-screen-for-buffer.

The default binding of backspace is the same as delete.  (C-h is still help.)

A middle click while the minibuffer is active does completion if you click on 
a highlighted completion, otherwise it executes the global binding of button2.

New versions of Barry Warsaw's c++-mode and syntax.c.  Font-lock-mode works
with C++ mode now.

The semantics of activate-menubar-hook has changed; the functions are called
with no arguments now.

`truename' no longer hacks the automounter; use directory-abbrev-alist instead.

Most minibuffer handling has been reimplemented in emacs-lisp.

There is now a builtin minibuffer history mechanism which replaces gmhist.


** Major Differences Between 19.2 and 19.3
==========================================

The ISO characters have correct case and syntax tables now, so the word-motion
and case-converting commands work sensibly on them.

If you set ctl-arrow to an integer, you can control exactly which characters
are printable.  (There will be a less crufty way to do this eventually.)

Menubars can now be buffer local; the function set-screen-menubar no longer
exists.  Look at GNUS and VM for examples of how to do this, or read 
menubar.el.

When emacs is reading from the minibuffer with completions, any completions
which are visible on the screen will highlight when the mouse moves over them;
clicking middle on a completion is the same as typing it at the minibuffer.
Some implications of this:  The *Completions* buffer is always mousable.  If
you're using the completion feature of find-tag, your source code will be
mousable when you type M-.  Dired buffers will be mousable as soon as you 
type ^X^F.  And so on.

The old isearch code has been replaced with a descendant of Dan LaLiberte's
excellent isearch-mode; it is more customizable, and generally less bogus.
You can search for "composed" characters.  There are new commands, too; see
the doc for ^S, or the NEWS file.

A patched GNUS 3.14 is included.

The user's manual now documents Lucid Emacs 19.3.

A few more modes have mouse and menu support.

The startup code should be a little more robust, and give you more reasonable
error messages when things aren't installed quite right (instead of the
ubiquitous "cannot open DISPLAY"...)

Subdirectories of the lisp directory whose names begin with a hyphen or dot
are not automatically added to the load-path, so you can use this to avoid
accidentally inflicting experimental software on your users.

I've tried to incorporate all of the portability patches that were sent to
me; I tried to solve some of the problems in different ways than the 
patches did, so let me know if I missed something.

Some systems will need to define NEED_STRDUP, NEED_REALPATH, HAVE_DREM, or
HAVE_REMAINDER in config.h.  Really this should be done in the appropriate
s- or m- files, but I don't know which systems need these and which don't.
If yours does, let me know which file it should be in.

Check out these new packages:

blink-paren.el: causes the matching parenthesis to flash on and off whenever
                the cursor is sitting on a paren-syntax character.

pending-del.el: Certain commands implicitly delete the highlighted region:
                Typing a character when there is a highlighted region replaces
                that region with the typed character.

font-lock.el:   A code-highlighting package, driven off of syntax tables, so
                that it understands block comments, strings, etc.  The 
                insertion hook is used to fontify text as you type it in.

shell-font.el:  Displays your shell-buffer prompt in boldface.
