xemacs-beta: etc/NEWS comparison

comparison etc/NEWS @ 0:376386a54a3c r19-14

Import from CVS: tag r19-14

author	cvs
date	Mon, 13 Aug 2007 08:45:50 +0200
parents
children	ac2d302a0011

comparison

equal deleted inserted replaced

--1:000000000000
+:376386a54a3c
+-*- 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. (We do not say just
+"GNU Emacs" because Richard M. Stallman ["RMS"] thinks that this term
+is too generic; although we sometimes say e.g. "GNU Emacs 19.30" to refer
+to a specific version of FSF GNU Emacs.  We do not say merely "Emacs", as
+RMS prefers, because that is clearly an even more generic term.) 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, glyphs 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" or "ERA".  It was initially based on an early version of Emacs
+Version 19 from the Free Software Foundation and has since been kept
+up-to-date with recent versions of that product.  It stems from a
+collaboration of Lucid, Inc. with SunSoft DevPro (a division of Sun
+Microsystems, Inc.; formerly called SunPro) and the University of Illinois.
+NOTE: Lucid, Inc. is currently out of business but development on XEmacs
+continues strong.  Recently, Amdahl Corporation and INS Engineering have
+both contributed significantly to the development of XEmacs.
+** Why Haven't XEmacs and FSF GNU Emacs Merged?
+===============================================
+This question comes up again and again on comp.emacs.xemacs and other
+newsgroups and mailing lists.  Recently in fact there was a long, heated
+thread about this issue.
+Here is what one XEmacs developer said about this issue.
+DISCLAIMER: This is provided for informational purposes only and does
+_NOT_ necessarily represent the opinions of any of the other XEmacs
+developers or of any of the organizations involved.  Keep in mind
+that this is a highly charged issue with differing and strongly-held
+opinions held by the various parties involved.
+Subject: Re: elisp code in GNU Emacs/XEmacs
+From: wing@666.com (Ben Wing)
+Message-ID: <wingDqGwLH.K6w@netcom.com>
+Date: Fri, 26 Apr 1996 11:44:05 GMT
+In article <9xo91fmordx.fsf@bcarsf26.nortel.ca>, Stephane Boucher
+<sbo@bcarsf26.nortel.ca> wrote:
+Well, I don't think the number of volunteers is greater by having 2
+Emacsen. I think your affirmation holds true because of the
+inhability of the various parties involved to work together and
+compromise. If people could all work together, I don't think there
+would be any benifit in having 2 Emacsen. It may seem profitable
+right now, but in the long run, I think everyone looses. The time
+everyone spends porting back and forth, and imitating what the other
+has done is not spent to do new features. I've presonnally
+experienced a project split in the past, and in the end everyone
+lost.
+I don't want to try to blame anybody for the current fiasco. But we do
+have a fiasco. That is unfortunate. There are so many contributors
+out there that if everyone worked together we might be looking
+forward to having, say, threads in Emacs. But instead, as someone
+told me not that long ago, maybe we'll soon see a new editor come out
+based on Java. Threads will be part of it at no extra cost, and those
+people still using Emacs will continue to curse at the fact that they
+can't start GNUS while typing an E-mail, and the various Emacs
+contributors will continue to argue among themselves, nitpicking
+about how to get the perfect solution, rather than try to move
+forward. Meanwhile, people will enjoy using a new state of the art
+editor.
+Don't think we're just being needlessly perverse by continuing to have
+XEmacs. I'm well aware of the problems in having a project split, and
+don't think for a minute that we haven't tried (extremely hard, in
+fact) to come up with a merge.
+Unfortunately, as I have said before, the odds of this happening are
+quite low due to severe conflicts (both technical, procedural, and
+philosophical) between RMS and the XEmacs developers. If we were to
+assent to even half of what RMS wants in a merged Emacs, it would take
+years of work to produce the merged Emacs, and the result would be
+less powerful than the existing XEmacs.
+Since so many people seem so misinformed about this problem, I'll go
+ahead and state the fundamental dividing issues:
+1. RMS does not believe in data abstraction, and cannot be convinced
+of the folly of this. This by itself is such a huge division that
+it makes a merge basically unthinkable. Because of this, FSF Emacs
+is basically unmaintainable by anyone other than RMS. RMS has
+consented to all the data abstraction I want provided that I take
+sole responsibility for writing this code (which basically means
+I'd have to write almost all of the code or rewrite most of his
+code), and provided that he can use this issue as a bargaining
+chip to get concessions of his own.
+2. RMS sees the merge process as a series of mutual concessions
+traded back and forth. IMHO this is reasonable for a peace treaty
+but absurd for a piece of software -- we have to have technical
+agreement on the major issues involved, and the chance of that
+happening is basically nil.
+3. RMS has insisted in full backwards compatibility with all aspects
+of FSF Emacs, no matter how ugly; and furthermore, this backwards
+compatibility must work fast enough to make existing code run
+without problem. This basically means that there would have to be
+parallel C implementations of events, keymaps, and many other data
+structures. This not only will take months or years of extra work
+to implement, but poses some fundamental technical problems due to
+the non-abstractedness of FSF Emacs (e.g. in FSF Emacs keymaps are
+conses or vectors and a lot of code depends on this, and
+reconciling this with XEmacs's primitive keymap type is difficult
+to impossible).
+4. RMS will not even consent to neutral names for the two editors. He
+objects to call his editor FSF Emacs because for some unfathomable
+reason he finds it insulting. He suggests just Emacs, which I find
+not only insulting (XEmacs is just as much Emacs as is FSF Emacs)
+but also quite confusing. He will not even consent to calling his
+editor GNU Emacs without also referring to XEmacs as GNU XEmacs --
+basically a Borg-like assimilation attempt at making XEmacs a GNU
+product, which it is not. (None of the developers of Lucid Emacs
+and XEmacs were or are sanctioned by GNU, and none of us got the
+least bit of assistance or cooperation in doing our work. In fact,
+RMS actively made it harder by choosing to ignore all work
+previously done in XEmacs and adding his own incompatible
+interfaces for functionality already in XEmacs. This makes it
+quite difficult to track FSF Emacs and keep a sane API.) He has
+stated many times, and continues to assert, that most or all of
+the work done on Lucid Emacs and XEmacs was done primarily as a
+testing ground for potential features to be added to FSF Emacs.
+All of the developers of Lucid Emacs and XEmacs assert that this
+is patently false -- so why does RMS continue to insist that this
+is the case?
+ben
+--
+"... then the day came when the risk to remain tight in a bud was
+more painful than the risk it took to blossom." -- Anais Nin
+** 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,
+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 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 GNU Emacs
+instead of Epoch.
+Our original hope was that our changes to 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 three 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.
+Eventually, all development source trees were synched up.  Currently, there
+is basically no difference in the source trees between what is at the
+University of Illinois and SunPro.
+SunPro originally called the integrated product ERA, for "Emacs Rewritten
+Again".  At some point, SunPro and Lucid 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" was not acceptable.  The agreed-upon name was
+"XEmacs", and this is what the product has been called starting with the
+19.11 release.
+* What's Different?
+===================
+** Differences between XEmacs and FSF GNU Emacs 19
+==================================================
+In XEmacs, events are first-class objects.  FSF 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.  FSF 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, Emacs 18, and and FSF 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;
+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.  The full 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.
+Many more packages are provided standard with XEmacs than with FSF 19.
+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.
+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 provides support for ToolTalk on systems that have 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 has a built-in toolbar.  Four toolbars can actually be configured:
+top, bottom, left, and right toolbars.
+XEmacs has vertical and horizontal scrollbars.  Unlike in FSF 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.)
+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.
+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.  XEmacs supports Motif applications, generic Xt (e.g. Athena)
+applications, and raw Xlib applications.
+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.
+NOTE: All timestamps are measured as milliseconds since Emacs started.
+key_press_event
+event_channel	A token representing which keyboard generated it.
+			For this kind of event, this is a frame 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 frame 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 frame object.
+timestamp		When it happened
+x, y		Where it was after it moved (in pixels).
+modifiers		Bucky-bits down when the motion was detected.
+			(Possibly not all window systems will provide this?)
+process_event
+timestamp		When it happened
+process		the emacs "process" object in question
+timeout_event
+timestamp		Now (really, when the timeout was signaled)
+interval_id		The ID returned when the associated call to
+			add_timeout_cb() was made
+	------ the rest of the fields are filled in by Emacs -----
+id_number		The Emacs timeout ID for this timeout (more
+			than one timeout event can have the same value
+			here, since Emacs timeouts, as opposed to
+			add_timeout_cb() timeouts, can resignal
+			themselves)
+function		An elisp function to call when this timeout is
+			processed.
+object		The object passed to that function.
+eval_event
+timestamp		When it happened
+function		An elisp 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 frame)
+			but needs that to happen synchronously with the other
+			user input, like keypresses.  This is useful when
+			events are reported through callbacks rather
+			than in the standard event stream.
+misc_user_event
+timestamp		When it happened
+function		An elisp function to call with this event object.
+object		Anything.
+			This is similar to an eval_event, except that it is
+			generated by user actions: selections in the
+			menubar or scrollbar actions.  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 keypresses or misc_user_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 one of the
+			reasons why eval_events exist; I'm not entirely happy
+			with this aspect of this event model.
+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-frame-hook,
+unmap-frame-hook, mouse-enter-frame-hook, and mouse-leave-frame-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-events'.  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-events' 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.
+*** 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 Xt event functions
+(specifically XtAppProcessEvent), 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, it uses the Xt event loop even when
+Emacs is not running on an X display (the Xt event loop supports this).  This
+makes it possible to run Emacs on a dumb TTY, and later connect it to one or
+more X servers.  It should also be possible to later connect an existing Emacs
+process to additional TTY's, although this code is still experimental.  (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 instead uses 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.)
+*** 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 C-x C-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 C-w, C-x C-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.
+If `zmacs-regions' is true, then the `mark-marker' command 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 Frame"         delete-frame            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 frame 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.14 ; A link...
+/usr/local/xemacs/src/xemacs-19.14*                 ; 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/xemacs-19.14/xemacs*
+$LOCAL/xemacs-19.14/lisp@ -> $SHARED/xemacs-19.14/lisp/
+$LOCAL/xemacs-19.14/etc@  -> $SHARED/xemacs-19.14/etc/
+$LOCAL/xemacs-19.14/info@ -> $SHARED/xemacs-19.14/info/
+The following would also work, but the above is probably more attractive:
+$LOCAL/bin/xemacs*
+$LOCAL/bin/lisp@ -> $SHARED/xemacs-19.14/lisp/
+$LOCAL/bin/etc@  -> $SHARED/xemacs-19.14/etc/
+$LOCAL/bin/info@ -> $SHARED/xemacs-19.14/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
+---------------
+(Note: This section is copied verbatim from the XEmacs Reference Manual.)
+The Emacs resources are generally set per-frame. Each Emacs frame
+can have its own name or the same name as another, depending on the
+name passed to the `make-frame' function.
+You can specify resources for all frames with the syntax:
+Emacs*parameter: value
+or
+Emacs*EmacsFrame.parameter:value
+You can specify resources for a particular frame with the syntax:
+Emacs*FRAME-NAME.parameter: value
+**** Geometry Resources
+-----------------------
+To make the default size of all Emacs frames be 80 columns by 55
+lines, do this:
+Emacs*EmacsFrame.geometry: 80x55
+To set the geometry of a particular frame named `fred', do this:
+Emacs*fred.geometry: 80x55
+Important! Do not use the following syntax:
+Emacs*geometry: 80x55
+You 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.
+As a special case, this geometry specification also works (and sets
+the default size of all Emacs frames to 80 columns by 55 lines):
+Emacs.geometry: 80x55
+since that is the syntax used with most other applications (since most
+other applications have only one top-level window, unlike Emacs).  In
+general, however, the top-level shell (the unmapped ApplicationShell
+widget named `Emacs' that is the parent of the shell widgets that
+actually manage the individual frames) does not have any interesting
+resources on it, and you should set the resources on the frames instead.
+The `-geometry' command-line argument sets only the geometry of the
+initial frame created by Emacs.
+A more complete explanation of geometry-handling is
+* The `-geometry' command-line option sets the `Emacs.geometry'
+resource, that is, the geometry of the ApplicationShell.
+* For the first frame created, the size of the frame is taken from
+the ApplicationShell if it is specified, otherwise from the
+geometry of the frame.
+* For subsequent frames, the order is reversed: First the frame, and
+then the ApplicationShell.
+* For the first frame created, the position of the frame is taken
+from the ApplicationShell (`Emacs.geometry') if it is specified,
+otherwise from the geometry of the frame.
+* For subsequent frames, the position is taken only from the frame,
+and never from the ApplicationShell.
+This is rather complicated, but it does seem to provide the most
+intuitive behavior with respect to the default sizes and positions of
+frames created in various ways.
+**** Iconic Resources
+---------------------
+Analogous to `-geometry', the `-iconic' command-line option sets the
+iconic flag of the ApplicationShell (`Emacs.iconic') and always applies
+to the first frame created regardless of its name.  However, it is
+possible to set the iconic flag on particular frames (by name) by using
+the `Emacs*FRAME-NAME.iconic' resource.
+**** Resource List
+------------------
+Emacs frames accept the following resources:
+`geometry' (class `Geometry'): string
+Initial geometry for the frame.  *Note Geometry Resources:: for a
+complete discussion of how this works.
+`iconic' (class `Iconic'): boolean
+Whether this frame 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 (may not be
+implemented).
+`menubar' (class `Menubar'): boolean
+Whether newly-created frames should initially have a menubar.  Set
+to true by default.
+`initiallyUnmapped' (class `InitiallyUnmapped'): boolean
+Whether XEmacs should leave the initial frame unmapped when it
+starts up.  This is useful if you are starting XEmacs as a server
+(e.g. in conjunction with gnuserv or the external client widget).
+You can also control this with the `-unmapped' command-line option.
+`barCursor' (class `BarColor'): boolean
+Whether the cursor should be displayed as a bar, or the
+traditional box.
+`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'.
+`selectionPointer' (class `Cursor'): cursor-name
+The cursor to use when the mouse is over a selectable text region
+(an extent with the `highlight' property; for example, an Info
+cross-reference).  This resource is used to initialize the variable
+`x-selection-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'.
+`modeLinePointer' (class `Cursor'): cursor-name
+The cursor to use when the mouse is over a mode line.  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'.
+`scrollbarPointer' (class `Cursor'): cursor-name
+The cursor to use when the mouse is over the scrollbar.  This
+resource is used to initialize the variable
+`x-scrollbar-pointer-shape'.
+`pointerColor' (class `Foreground'): color-name
+`pointerBackground' (class `Background'): color-name
+The foreground and background colors of the mouse cursor.  These
+resources are used to initialize the variables
+`x-pointer-foreground-color' and `x-pointer-background-color'.
+`scrollBarWidth' (class `ScrollBarWidth'): integer
+How wide the vertical scrollbars should be, in pixels; 0 means no
+vertical scrollbars.  You can also use a resource specification of
+the form `*scrollbar.width', or the usual toolkit scrollbar
+resources: `*XmScrollBar.width' (Motif), `*XlwScrollBar.width'
+(Lucid), or `*Scrollbar.thickness' (Athena).  We don't recommend
+that you use the toolkit resources, though, because they're
+dependent on how exactly your particular build of XEmacs was
+configured.
+`scrollBarHeight' (class `ScrollBarHeight'): integer
+How high the horizontal scrollbars should be, in pixels; 0 means no
+horizontal scrollbars.  You can also use a resource specification
+of the form `*scrollbar.height', or the usual toolkit scrollbar
+resources: `*XmScrollBar.height' (Motif), `*XlwScrollBar.height'
+(Lucid), or `*Scrollbar.thickness' (Athena).  We don't recommend
+that you use the toolkit resources, though, because they're
+dependent on how exactly your particular build of XEmacs was
+configured.
+`scrollBarPlacement' (class `ScrollBarPlacement'): string
+Where the horizontal and vertical scrollbars should be positioned.
+This should be one of the four strings `bottom-left',
+`bottom-right', `top-left', and `top-right'.  Default is
+`bottom-right' for the Motif and Lucid scrollbars and
+`bottom-left' for the Athena scrollbars.
+`topToolBarHeight' (class `TopToolBarHeight'): integer
+`bottomToolBarHeight' (class `BottomToolBarHeight'): integer
+`leftToolBarWidth' (class `LeftToolBarWidth'): integer
+`rightToolBarWidth' (class `RightToolBarWidth'): integer
+Height and width of the four possible toolbars.
+`topToolBarShadowColor' (class `TopToolBarShadowColor'): color-name
+`bottomToolBarShadowColor' (class `BottomToolBarShadowColor'): color-name
+Color of the top and bottom shadows for the toolbars.  NOTE: These
+resources do *not* have anything to do with the top and bottom
+toolbars (i.e. the toolbars at the top and bottom of the frame)!
+Rather, they affect the top and bottom shadows around the edges of
+all four kinds of toolbars.
+`topToolBarShadowPixmap' (class `TopToolBarShadowPixmap'): pixmap-name
+`bottomToolBarShadowPixmap' (class `BottomToolBarShadowPixmap'): pixmap-name
+Pixmap of the top and bottom shadows for the toolbars.  If set,
+these resources override the corresponding color resources. NOTE:
+These resources do *not* have anything to do with the top and
+bottom toolbars (i.e. the toolbars at the top and bottom of the
+frame)!  Rather, they affect the top and bottom shadows around the
+edges of all four kinds of toolbars.
+`toolBarShadowThickness' (class `ToolBarShadowThickness'): integer
+Thickness of the shadows around the toolbars, in pixels.
+`visualBell' (class `VisualBell'): boolean
+Whether XEmacs should flash the screen rather than making an
+audible beep.
+`bellVolume' (class `BellVolume'): integer
+Volume of the audible beep.
+`useBackingStore' (class `UseBackingStore'): boolean
+Whether XEmacs should set the backing-store attribute of the X
+windows it creates.  This increases the memory usage of the X
+server but decreases the amount of X traffic necessary to update
+the screen, and is useful when the connection to the X server goes
+over a low-bandwidth line such as a modem connection.
+**** Face Resources
+-------------------
+The attributes of faces are also per-frame. They can be specified as:
+Emacs.FACE_NAME.parameter: value
+(*do not* use `Emacs*FACE_NAME...')
+or
+Emacs*FRAME_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 (or XPM file, if your version of Emacs
+supports XPM), 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'.  To set the font of normal text, use
+`Emacs*default.attributeFont'. To set it in the frame named `fred', use
+`Emacs*fred.default.attributeFont'.
+These are the names of the predefined faces:
+`default'
+Everything inherits from this.
+`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'
+If this is not specified in the resource database, Emacs tries to
+find an italic version of the font of the default face.
+`bold-italic'
+If this is not specified in the resource database, Emacs tries to
+find a bold-italic version of the font of the default face.
+`modeline'
+This is the face that the modeline is displayed in.  If not
+specified in the resource database, it is determined from the
+default face by reversing the foreground and background colors.
+`highlight'
+This is the face that highlighted extents (for example, Info
+cross-references and possible completions, when the mouse passes
+over them) are displayed in.
+`left-margin'
+`right-margin'
+These are the faces that the left and right annotation margins are
+displayed in.
+`primary-selection'
+This is the face that mouse selections are displayed in.
+`text-cursor'
+This is the face that the cursor is 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'. (Note that, when the mouse passes over a
+cross-reference, the cross-reference's face is determined from a
+combination of the `info-xref' and `highlight' faces.)
+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 XEmacs 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
+fixed
+9x13
+then XEmacs 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)'.
+**** Widgets
+------------
+There are several structural widgets between the terminal EmacsFrame
+widget and the top level ApplicationShell; the exact names and types of
+these widgets change from release to release (for example, they changed
+in 19.9, 19.10, 19.12, and 19.13) and are subject to further 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.14,
+the exact widget hierarchy is as follows:
+INVOCATION-NAME           "shell"              "container"     FRAME-NAME
+x-emacs-application-class "TopLevelEmacsShell" "EmacsManager" "EmacsFrame"
+(for normal frames)
+or
+INVOCATION-NAME           "shell"               "container"     FRAME-NAME
+x-emacs-application-class "TransientEmacsShell" "EmacsManager" "EmacsFrame"
+(for popup/dialog-box frames)
+where INVOCATION-NAME is the terminal component of the name of the
+XEmacs executable (usually `xemacs'), and `x-emacs-application-class'
+is generally `Emacs'.
+**** Menubar Resources
+----------------------
+As the menubar is implemented as a widget which is not a part of
+XEmacs 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 for 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.
+** Differences Between XEmacs and Emacs 18
+==========================================
+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, XEmacs has a
+concept of "input events", and ASCII characters are a subset of that.  The
+events that XEmacs knows about are not X events, but are a generalization of
+them, so that XEmacs 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 ("frames" in XEmacs terminology).
+XEmacs 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 frame-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.
+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 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 XEmacs.
+XEmacs provides support for ToolTalk on systems that have it.
+XEmacs supports the Zmacs/Lispm style of region highlighting, where the
+region between the point and mark is highlighted when in its "active" state.
+XEmacs 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 XEmacs to use a *real* Motif menubar
+instead.
+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 has vertical and horizontal scrollbars.
+The initial load-path is computed at run-time, instead of at compile-time.
+This means that if you move the XEmacs executable and associated directories
+to somewhere else, you don't have to recompile anything.
+You can specify what the title of the XEmacs windows and icons should be
+with the variables `frame-title-format' and `frame-icon-title-format',
+which have the same syntax as `mode-line-format'.
+XEmacs now supports floating-point numbers.
+XEmacs now knows about timers directly, instead of them being simulated by
+a subprocess.
+XEmacs 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 XEmacs to play instead of the default X beep.  See the documentation
+of the function load-sound-file and the variable sound-alist.
+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.  XEmacs 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 (viper)
+- 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
+- the Hyperbole package, a programmable information management and
+hypertext system
+- the OO-Browser package, a multi-language object-oriented browser
+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.
+* XEmacs Release Notes
+======================
+** Future Plans for XEmacs
+==========================
+For the curious, the biggest changes in 19.15 will include integration
+of TM (a MIME package for VM and GNUS), EFS (the next generation of
+ange-ftp), and Auc-TeX, and a "lite" distribution that includes a
+minimal base and a set of optional packages (which will include TM,
+EFS, and Auc-TeX, as well as all of the large packages currently
+distributed with XEmacs).  There will also still be a full distribution
+that includes all the optional packages.
+In the longer term, we are also working on a separate branch of XEmacs that
+includes full Asian-language ("MULE") support.  This work is currently in
+beta and is being supported by Sun Microsystems.
+** Major Differences Between 19.13 and 19.14
+============================================
+XEmacs has a new address!  The canonical ftp site is now
+ftp.xemacs.org:/pub/xemacs and the Web page is now at
+http://www.xemacs.org/.  All mailing lists now have @xemacs.org
+addresses.  For the time being the @cs.uiuc.edu addresses will
+continue to function.
+This is a major new release.  Many features have been added, as well
+as many bugs fixed.  The Motif menubar has still _NOT_ been fixed for
+19.14.  You should use the Lucid menubar instead.
+Major user-visible changes:
+---------------------------
+-- Color support in TTY mode is provided.  You have to have a TTY capable
+of displaying them, such as color xterm or the console under Linux.
+If your terminal type supports colors (e.g. `xterm-color'), XEmacs
+will automatically notice this and start using color.
+-- blink-cursor-mode enables a blinking text cursor.  There is a
+menubar option for this also.
+-- auto-show-mode is turned on by default; this means that XEmacs
+will automatically scroll a window horizontally as necessary to
+keep point in view.
+-- a file dialog box is provided and will be used whenever you
+are prompted for a filename as a result of a menubar selection.
+-- XEmacs can be compiled with built-in GIF, JPEG, and PNG support.
+The GIF libraries are supplied with XEmacs; for JPEG and PNG,
+you have to obtain the appropriate libraries (this is well-
+documented).  This makes image display much easier and faster under
+W3 (the web browser) and TM (adds MIME support to VM and GNUS;
+not yet included with XEmacs but will be in 19.15).
+-- XEmacs provides a really nice mode (PSGML with "Wing improvements")
+for editing HTML and other SGML documents.  It parses the document,
+and as a result it does proper indentation, can show you the context
+you're in, the allowed tags at a particular position, etc.
+-- XEmacs comes standard with modes for editing Java and VRML code,
+including font-lock support.
+-- GNUS 5.2 comes standard with XEmacs.
+-- You can now embed colors in the modeline, with different sections
+of the modeline responding appropriately to various mouse gestures:
+For example, clicking on the "read-only" indicator toggles the
+read-only status of a buffer, and clicking on the buffer name
+cycles to the next buffer.  Pressing button3 on these areas brings
+up a popup menu of appropriate commands.
+-- There is a much nicer mode for completion lists and such.
+At the minibuffer prompt, if you hit page-up or Meta-V, the completion
+buffer will be displayed (if it wasn't already), you're moved into
+it, and can move around and select filenames using the arrow keys
+and the return key.  Rather than a cursor, a filename is highlighted,
+and the arrow keys change which filename is highlighted.
+-- The edit-faces subsystem has also been much improved, in somewhat
+similar ways to the completion list improvements.
+-- Many improvements were made to the multi-device support.
+We now provide an auxiliary utility called "gnuattach" that
+lets you connect to an existing XEmacs process and display
+a TTY frame on the current TTY connection, and commands
+`make-frame-on-display' (with a corresponding menubar entry)
+and `make-frame-on-tty' for more easily creating frames on
+new TTY or X connections.
+-- We have incorporated nearly all of the functionality of GNU Emacs
+19.30 into XEmacs.  This includes support for lazy-loaded
+byte code and documentation strings, improved paragraph filling,
+better support for margins within documents, v19 regular expression
+routines (including caching of compiled regexps), etc.
+-- In accordance with GNU Emacs 19.30, the following key binding
+changes have been made:
+C-x ESC -> C-x ESC ESC
+ESC ESC -> ESC :
+ESC ESC ESC is "abort anything" (keyboard-escape-quit).
+-- All major packages have been updated to their latest-released
+versions.
+-- XEmacs now gracefully handles a full colormap (such as typically
+results when running Netscape).  The nearest available color
+is automatically substituted.
+-- Many bug fixes to the subprocess/PTY code, ps-print, menubar
+functions, `set-text-properties', DEC Alpha support, toolbar
+resizing (the "phantom VM toolbar" bug), and lots and lots
+of other things were made.
+-- The ncurses library (a replacement for curses, found especially
+under Linux) is supported, and will be automatically used
+if it can be found.
+-- You can now undo in the minibuffer.
+-- Surrogate minibuffers now work.  These are also sometimes referred
+to as "global" minibuffers.
+-- font-lock has been merged with GNU Emacs 19.30, improved defaults
+have been added, and changes have been made to the way it is
+configured.
+-- Many, many modes have menubar entries for them.
+-- `recover-session' lets you recover whatever files can be recovered
+after your XEmacs process has died unexpectedly.
+-- C-h k followed by a toolbar button press correctly reports
+the binding of the toolbar button.
+-- `function-key-map', `key-translation-map', and `keyboard-translate-table'
+are now correctly implemented.
+-- `show-message-log' (and its menubar entry under Edit) have been
+removed; instead use `view-lossage' (and its menubar entry under
+Help).
+-- There is a standard menubar entry for specifying which browser
+(Netscape, W3, Mosaic, etc.) to use when dispatching URL's
+in mail, Usenet news, etc.
+-- Improved native sound support under Linux.
+-- Lots of other things we forgot to mention.
+Significant Lisp-level changes:
+-------------------------------
+-- Many improvements to the E-Lisp documentation have been made;
+it should now be up-to-date and complete in nearly all cases.
+-- XEmacs has extensive documentation on its internals, for
+would-be C hackers.
+-- Common-Lisp support (the CL package) is now dumped standard
+into XEmacs.  No more need for (require 'cl) or anything
+like that.
+-- Full support for extents and text properties over strings is
+provided.
+-- The extent properties `start-open', `end-open', `start-closed',
+and `end-closed' now work correctly w.r.t. text properties.
+-- The `face' property of extents and text properties can now
+be a list.
+-- The `mouse-face' property from FSF GNU Emacs is now supported.
+It supersedes the `highlight' property.
+-- `enriched' and `facemenu' packages from FSF GNU Emacs have been ported.
+-- New functions for easier creation of dialog boxes:
+`get-dialog-box-response', `message-box', and `message-or-box'.
+-- `function-min-args' and `function-max-args' allow you to determine
+the minimum and maximum allowed arguments for any type of
+function (i.e. subr, lambda expression, byte-compiled function, etc.).
+-- Some C-level support for doing E-Lisp profiling is provided.
+See `start-profiling', `stop-profiling', and
+`pretty-print-profiling-info'.
+-- `current-process-time' reports the user, system, and real times
+for the currently running XEmacs process.
+-- `next-window', `previous-window', `next-frame', `previous-frame',
+`other-window', `get-lru-window', etc. have an extra device
+argument that allows you to restrict which devices it includes
+(normally all devices).  Some functions that incorrectly ignored
+frames on different devices (e.g. C-x 0) are fixed.
+-- new functions `run-hook-with-args-until-success',
+`run-hook-with-args-until-failure'.
+-- generalized facility for local vs. global hooks.  See `make-local-hook',
+`add-hook'.
+-- New functions for querying the window tree: `frame-leftmost-window',
+`frame-rightmost-window', `window-first-hchild', `window-first-vchild',
+`window-next-child', `window-previous-child', and `window-parent'.
+-- Epoch support works.  This gets you direct access to some X events
+and objects (e.g. properties and property-notify events).
+-- The multi-device support has been majorly revamped.  There is now
+a new concept of "consoles" (devices grouped together under a
+common keyboard/mouse), console-local variables, and a generalized
+concept of device/console connection.
+-- `display-buffer' synched with GNU Emacs 19.30, giving you lots of
+wondrous cruft such as
+-- unsplittable frames
+-- pop-up-frames, pop-up-frame-function
+-- special-display-buffer-names, special-display-regexps,
+special-display-function
+-- same-window-buffer-names, same-window-regexps
+-- XEmacs has support for accessing DBM- and/or DB-format databases,
+provided that you have the appropriate libraries on your system.
+-- There is a new font style: "strikethru" fonts.
+-- New data type "weak list", which is a list with special
+garbage-collection properties, similar to weak hash tables.
+-- `set-face-parent' makes one face inherit all properties from another.
+-- The junky frame parameters mechanism has been revamped as
+frame properties, which a standard property-list interface.
+-- Lots and lots of functions for working with property lists have
+been added.
+-- New functions `push-window-configuration', `pop-window-configuration',
+`unpop-window-configuration' for maintain a stack of window
+configurations.
+-- Many fixups to the glyph code; icons and mouse pointers are now
+properly merged into the glyph mechanism.
+-- `set-specifier' works more sensibly, like `set-face-property'.
+-- Many new specifiers for individually controlling toolbar height/width
+and visibility and text cursor visibility.
+-- New face `text-cursor' controls the colors of the text cursor.
+-- Many new variables for turning on debug information about the
+inner workings of XEmacs.
+-- Hash tables can now compare their keys using `equal' or `eql'
+as well as `eq'.
+-- Other things too numerous to mention.
+Significant configuration/build changes:
+----------------------------------------
+-- You can disable TTY support, toolbar support, scrollbar support,
+menubar support, and/or dialog box support at configure time
+to save memory.
+-- New configure option `--extra-verbose' shows the diagnostic
+output from feature testing; this should help track down
+problems with incorrect feature detection.
+-- `dont-have-xmu' is now `with-xmu', with the reversed sense.
+(It defaults to `yes'.)
+-- `with-mocklisp' lets you add Mocklisp support if you really
+need this.
+-- `with-term' for adding TERM support for Linux users.
+** Major Differences Between 19.12 and 19.13
+============================================
+This is primarily a bug-fix release.  Lots of bugs have been fixed.
+Hopefully only a few have been introduced.  The most noteworthy bug
+fixes are:
+-- There should be no more problems connecting XEmacs to an X
+server over SLIP or other slow connections.
+-- Periodic crashes when using the Buffers menu should be gone.
+-- etags would sometimes erase the current buffer; it doesn't
+any more.
+-- XEmacs will correctly exit if the X server dies.
+-- uniconified frames are displayed properly under TVTWM.
+-- Breakage in `add-menu-item' / `add-menu-button' is fixed.
+The Motif menubar has _NOT_ been fixed for 19.13.  You should use the
+Lucid menubar instead.
+Multi-device support should now be working properly.  You can now open
+an X device after having started out on a TTY device.
+Background pixmaps now work.  See `set-face-background-pixmap'.
+Echo area messages are now saved to a buffer, " *Message Log*".  To
+see this buffer, use the command `show-message-log'.  It is possible
+to filter the message which are actually included by modifying the
+variables `log-message-ignore-regexps' and `log-message-ignore-labels'.
+You can now control which warnings you want to see.  See
+`display-warning-suppressed-classes' and friends.
+You can now set the default location of an "other window" from the
+Options menu.
+"Save Options" now saves the state of all faces.
+You can choose which file "Save Options" writes into; see
+`save-options-file'.
+XPM support is no longer required for the toolbar.
+The relocating allocator is now enabled by default whenever possible.
+This allows buffer memory to be returned to the system when no longer
+in use which helps keep XEmacs process size down.
+The ability to have captioned toolbars has been added.  Currently only
+the default toolbar actually has a captioned version provided.  A new
+specifier variable, `toolbar-buttons-captioned-p' controls whether the
+toolbar is captioned.
+A copy of the XEmacs FAQ is now included and is available through info.
+The on-line E-Lisp reference manual has been significantly updated.
+There is now audio support under Linux.
+Modifier keys can now be sticky.  This is controlled by the variable
+`modifier-keys-are-sticky'.
+manual-entry should now work correctly under Irix with the penalty of
+a longer startup time the first time it is invoked.  If you are having
+problems with this on another system try setting
+`Manual-use-subdirectory-list' to t.
+make-tty-device no longer automatically creates the first frame.
+Rectangular regions now work correctly.
+ediff no longer sets synchronize-minibuffers to t unless you first set
+ediff-synchronize-minibuffers
+keyboard-translate-table has been implemented.  This means that the
+`enable-flow-control' command for dealing with TTY connections that
+filter out ^S and ^Q now works.
+You can now create frames that are initially unmapped and frames that
+are "transient for another frame", meaning that they behave more like
+dialog-box frames.
+Other E-Lisp changes:
+-- Specifier `menubar-visible-p' for controlling menubar visibility
+-- Local command hooks should be set using `local-pre-command-hook'
+and `local-post-command-hook' instead of making the global
+equivalents be buffer-local.
+-- `quit-char', `help-char', `meta-prefix-char' can be any key specifier
+instead of just an integer.
+-- new functions `add-async-timeout' and `disable-async-timeout'.
+These let you create asynchronous timeouts, which are like
+normal timeouts except that they're executed even during
+running Lisp code.  Use this with care!
+-- `debug-on-error' and `stack-trace-on-error' now enter the debugger
+only when an *unhandled* error occurs.  If you want the old
+behavior, use `debug-on-signal' and `stack-trace-on-signal'.
+-- \U, \L, \u, \l, \E recognized specially in `replace-match'.
+These are standard ex/perl commands for changing the case of
+replaced text.
+-- New function event-matches-key-specifier-p.  This provides
+a clean way of comparing keypress events with key specifiers
+such as 65, (shift home), etc. without having to resort
+to ugly `character-to-event' / `event-to-character' hacks.
+-- New function `add-to-list'
+-- New Common-Lisp functions `some', `every', `notevery', `notany',
+`adjoin', `union', `intersection', `set-difference',
+`set-exclusive-or', `subsetp'
+-- `remove-face-property' provides a clean way of removing a
+face property.
+Many of the Emacs Lisp packages have been updated.  Some of the new
+Emacs Lisp packages ---
+ada-mode:  major mode for editing Ada source
+arc-mode:  simple editing of archives
+auto-show-mode:  automatically scrolls horizontally to keep point on-screen
+completion:  dynamic word completion mode
+dabbrev:  the dynamic abbrev package has been rewritten and is much
+more powerful -- e.g. it searches in other buffers as well
+as the current one
+easymenu:  menu support package
+live-icon:  makes frame icons represent the current frame contents
+mailcrypt 3.2:  mail encryption with PGP; included but v2.4 is still
+		the default
+two-column:  for editing two-column text
+** Major Differences Between 19.11 and 19.12
+============================================
+This is a huge new release.  Almost every aspect of XEmacs has been changed
+at least somewhat.  The highlights are:
+-- TTY support (includes face support)
+-- new redisplay engine; should be faster, less buggy, and more powerful
+-- terminology change from "screen" to "frame"
+-- built-in toolbar
+-- toolbar support added to many packages
+-- multiple device support (still in beta; improvements to come in
+19.13)
+-- Purify used to ensure that there are no memory leaks or memory corruption
+problems
+-- horizontal and vertical scrollbars in all windows
+-- new Lucid (i.e. look-alike Motif) scrollbar widget
+-- stay-up menus in the Lucid (look-alike Motif) menubar widget
+-- 3-d modeline
+-- new extents engine; should be faster, less buggy, and more powerful
+-- much more powerful control over faces
+-- expanded menubar
+-- more work on synching with GNU Emacs 19.28
+-- new packages: Hyperbole, OOBR (object browser), hm--html-menus, viper,
+lazy-lock.el, ksh-mode.el, rsz-minibuf.el
+-- package updates for all major packages
+-- dynodump package for Solaris: provides proper undumping and portable
+binaries across different OS versions and machine types
+-- Greatly expanded concept of "glyphs" (pixmaps etc. in a buffer)
+-- built-in support for displaying X-Faces, if the X-Face library is
+available
+-- built-in support for SOCKS if the SOCKS library is available
+-- graceful behavior when the colormap is full (e.g. Netscape ate
+all the colors)
+-- built-in MD5 (secure hashing function) support
+More specific information:
+*** TTY Support
+---------------
+The long-awaited TTY support is now available.  XEmacs will start up
+in TTY mode (using the tty you started XEmacs from) if the DISPLAY
+environment variable is not set or if you use the `-nw' option.
+Faces are available on TTY's.  For a demonstration, try editing a C
+file and turning on font-lock-mode.
+You can also connect to additional TTY's using `make-tty-device',
+whether your first frame was a TTY or an X window.  This ability is
+not yet completely finished.
+The full event-loop capabilities (processes, timeouts, etc.) are
+available on TTY's.
+*** New Redisplay Engine
+------------------------
+The redisplay engine has been rewritten to improve its efficiency and
+to increase its functionality.  It should also be significantly more
+bug-free than the previous redisplay engine.
+A line that is not big enough to display at the bottom of the window
+will normally be clipped (so that it is partially visible) rather than
+not displayed at all.  The variable `pixel-vertical-clip-threshold'
+can be used to control the minimum space that must be available for a
+line to be clipped rather than not displayed at all.
+Tabs are displayed in such a way that things line up fairly well even
+in the presence of variable-width fonts and/or lines with
+multiply-sized fonts.
+Display tables are implemented, through the specifier variable
+`current-display-table'.  They can be buffer-local, window-local,
+frame-local, or device-local.  See below for info about specifiers.
+*** Toolbar
+-----------
+There is now built-in support for a toolbar.  A sample toolbar is
+visible by default at the top of the frame.  Four separate toolbars
+can be configured (at the top, bottom, left, and right of the frame).
+The toolbar specification is similar to the menubar specification.
+The up, down, and disabled glyphs of a toolbar button can be
+separately controlled.  Explanatory text can be echoed in the echo
+area when the mouse passes over a toolbar button.  The size, contents,
+and visibility of the various toolbars can be controlled on a
+per-buffer, per-window, per-frame, and per-device basis through the
+use of specifiers.  See the chapter on toolbars in the Lisp Reference
+Manual (included with XEmacs) for more information.
+The toolbar color and shadow thicknesses are currently controlled only
+through `modify-frame-parameters' and through X resources.  We are
+planning on making these controllable through specifiers as well. (Our
+hope is to make `modify-frame-parameters' obsolete, as it is a clunky
+and not very powerful mechanism.)
+Info, GNUS, VM, W3, and various other packages include custom toolbars
+with them.
+*** Menubar
+-----------
+Stay-up menus are implemented in the look-alike Motif menubar.
+The default menubar has been expanded to include most commonly-used
+functions in XEmacs.
+The options menu has been greatly expanded to include many more
+options.
+The menubar specification format has been greatly expanded.  Per-menu
+activation hooks can be specified through the :filter keyword (thus
+obsoleting `activate-menubar-hook'); this allows for fast response
+time when you have a large and complex menu.  You can dynamically
+control whether menu items are present through the :included and
+:config keywords. (The latter keyword implements a simple menubar
+configuration scheme, in conjunction with the variable
+`menubar-configuration'.) Many different menu-item separators (single
+or double line; solid or dashed; flat, etched-in, or etched-out) are
+available.  See the chapter on menus in the Lisp Reference Manual for
+more information about all of this.
+New functions `add-submenu' and `add-menu-button' are available.
+These supersede the older `add-menu' and `add-menu-item' functions,
+and provide a more powerful and consistent interface.
+New convenience functions for popping up the part or all of the
+menubar in a pop-up menu are available: `popup-menubar-menu' and
+`popup-buffer-menu'.
+Menus are now incrementally constructed greatly improving menubar
+response time.
+*** Scrollbars
+--------------
+A look-alike Motif scrollbar is now included with XEmacs.  No longer
+will you have to suffer with ugly Athena scrollbars.
+Windows can now have horizontal scrollbars.  Normally they are visible
+when the window's buffer is set to truncate lines rather than wrap
+them (e.g. `(setq truncate-lines t)').
+All windows, not only the right-most ones, can have vertical
+scrollbars.
+The functions to change a scrollbar's width have been superseded by
+the specifier variables `scrollbar-width' and `scrollbar-height'.
+This allows their values to be controlled on a buffer-local,
+window-local, frame-local, and device-local basis.  See below.
+The scrollbars interact better with the event loop (for example, you
+can type `C-h k', do a scrollbar action, and see a description of this
+scrollbar action printed as if you had pressed a key sequence or
+selected a menu item).
+The scrollbar behavior can be reprogrammed, by advising the
+`scrollbar-*' functions.
+*** Key Bindings
+----------------
+The oft-used function `goto-line' now has its own binding: M-g.
+New bindings are available for scrolling the "other" window: M-next,
+M-prior, M-home, M-end. (On many keyboards, `next' and `prior'
+labelled `PgUp' and `PgDn'.)
+You can reactivate a deactivated Zmacs region, without having any
+other effects, with the binding M-C-z.
+The bindings `M-u', `M-l', and `M-c' now work on the region (if a
+region is active) or work on a word, as before.
+Shift-Control-G forces a "critical quit", which drops immediately into
+the debugger; see below.
+*** Modeline
+------------
+The modeline can now have a 3-d look; this is enabled by default.  The
+specifier variable `modeline-shadow-thickness' controls the size.
+The modeline can now be turned off on a per-buffer, per-window,
+per-frame, or per-device basis.  The specifier variable
+`has-modeline-p' controls whether the modeline is visible.  See below
+for details about the vastly powerful specifier mechanism.
+The modeline functions and variables have been renamed to be
+`*-modeline-*' rather than `*-mode-line-*'.  Aliases are provided for
+all the old names.
+Variable width fonts now work correctly when used in the modeline.
+*** Minibuffer, Echo Area
+-------------------------
+The minibuffer is no longer constrained to be one line high.  The
+package rsz-minibuf.el is included to automatically resize the
+minibuffer when its contents are too big; enable this with
+`resize-minibuffer-mode'.
+The echo area is now a true buffer, called " *Echo Area*".  This
+allows you to customize the echo area behavior through
+before-change-functions and after-change-functions.
+*** Specifiers
+--------------
+XEmacs has a new concept called "specifiers", used to configure most
+display options (toolbar size and contents, scrollbar size, face
+properties, modeline visibility and shadow-thickness, glyphs, display
+tables, etc.).  We are planning on converting all display
+characteristics to use specifiers, and obsoleting the clunky functions
+`frame-parameters' and `modify-frame-parameters'.  Specifically:
+-- You can specify values (called "instantiators") for particular
+"locales" (i.e. buffers, windows, frames, devices, or a global value).
+When determining what the actual value (or "instance") of a specifier
+is, the specifications that are provided are searched from most
+specific (i.e. buffer-local) to most general (i.e. global), looking
+for a matching one.
+-- You can specify multiple instantiators for a particular locale.
+For example, when specifying what the foreground color of a face
+is in a particular buffer, you could specify two instantiators:
+"dark sea green" and "green".  The color would then be dark sea
+green on devices that recognize that color, and green on other
+devices.  You have effectively provided a fallback value to make
+sure you get reasonable behavior on all devices.
+-- You can add one or more tags to an instantiator, where a tag
+is a symbol that has been previously registered with XEmacs.
+This allows you to identify your instantiators for later
+removal in a way that won't interfere with other applications
+using the same specifier.  Furthermore, particular tags can
+be restricted to match only particular sorts of devices.
+Any tagged instantiator will be ignored if the device over which
+it is being instanced does not match any of its tags.  This
+allows you, for example, to restrict an instantiator to a
+particular device type (X or TTY) and/or class (color, grayscale,
+or mono). (You might want to specify, for example, that a
+particular face is displayed in green on color devices and is
+underlined on mono devices.)
+-- A full API is provided for manipulating specifiers, and full
+documentation is provided in the Lisp Reference Manual.
+*** Basic Lisp Stuff
+--------------------
+Common-Lisp backquote syntax is recognized.  For example, the old
+expression
+(` (a b (, c)))
+can now be written
+`(a b ,c)
+The old backquote syntax is still accepted.
+The new function `type-of' returns a symbol describing the type of a
+Lisp object (`integer', `string', `symbol', etc.)
+Symbols beginning with a colon (called "keywords") are treated
+specially in that they are automatically made self-evaluating when
+they are interned into `obarray'.  The new function `keywordp' returns
+whether a symbol begins with a colon.
+`get', `put', and `remprop' have been generalized to allow you to set
+and retrieve properties on many different kinds of objects: symbols,
+strings, faces, glyphs, and extents (for extents, however, this is not
+yet implemented).  They are joined by a new function `object-props'
+that returns all of the properties that have been set on an object.
+New functions `plists-eq' and `plists-equal' are provided for
+comparing property lists (a property list is an alternating list
+of keys and values).
+The Common-Lisp functions `caar', `cadr', `cdar', `cddr', `caaar', etc.
+(up to four a's and/or d's), `first', `second', `third', etc. (up to
+`tenth'), `last', `rest', and `endp' have been added, for more
+convenient manipulation of lists.
+New function `mapvector' maps over a sequence and returns a vector
+of the results, analogous to `mapcar'.
+New functions `rassoc', `remassoc', `remassq', `remrassoc', and
+`remrassq' are provided for working with alists.
+New functions `defvaralias', `variable-alias' and `indirect-variable'
+are provided for creating variable aliases.
+Strings have a modified-tick that is bumped every time a string
+is modified in-place with `aset' or `fillarray'.  This is retrieved
+with the new function `string-modified-tick'.
+New macro `push' destructively adds an element to the beginning of a
+list.  New macro `pop' destructively removes and returns the first
+element of a list.
+*** Buffers
+-----------
+Most functions that operate on buffer text now take an optional BUFFER
+argument, specifying which buffer they operate on.  (Previously, they
+always operated on the current buffer.)
+The new function `transpose-regions' is provided, ported from GNU
+Emacs.
+The new function `save-current-buffer' works like `save-excursion'
+but only saves the current buffer, not the location of point in
+that buffer.
+*** Devices
+-----------
+XEmacs has a new concept of "device", which is represents a particular
+X display or TTY connection.  `make-frame' has a new, optional device
+parameter that allows you to specify which device the frame is to be
+created on.
+Multiple simultaneous TTY and/or X connections may be made.  The
+specifier mechanism provides reasonable behavior of glyphs, faces,
+etc. over heterogeneous device types and over devices whose individual
+capabilities may vary.
+There is also a device type called "stream" that represents a STDIO
+device that has no redisplay or cursor-motion capabilities, such as
+the "glass terminal" that XEmacs uses when it is run noninteractively.
+There is not all that much you can do with stream devices currently;
+please let us know if there are good uses you can think of for this
+capability. (For example, log files?)
+A new device API is provided.  Functions are provided such as
+`device-name' (the name of the device, which generally is based on the
+X display or TTY file name), `device-type' (X, TTY, or stream),
+`device-class' (color, grayscale, or mono), etc.  See the Lisp
+Reference Manual.
+Many functions have been extended to contain an additional, optional
+device argument, where such an extension makes sense.  In general, if
+the argument is omitted, it is equivalent to specifying
+`(selected-device)'.
+Many previous functions and variables are obsoleted in favor of the
+device API.  For example, `window-system' is obsoleted by
+`device-type', and `x-color-display-p' and friends are obsoleted by
+`device-class'.
+** NOTE **: The obsolete variable `window-system' is going
+to be deleted soon, probably in 19.14.  Please correct all
+your code to use `device-type'.
+** INCOMPATIBLE CHANGE **: The function `x-display-visual-class'
+returns different values from previous versions of XEmacs.
+*** Errors, Warnings, C-g
+-------------------------
+There is a new warnings system implemented.  Many warnings that were
+formerly displayed in various ad-hoc ways (e.g. warnings about screwy
+modifier mappings, messages about failures handling the mouse cursor
+and errors in a gc-hook) have been regularized through this system.
+The new function `warn' displays a warning before the next redisplay
+(the actually display of the warning messages is accomplished through
+`display-warning-buffer').  Both `warn' and `display-warning-buffer'
+are Lisp functions (the C code calls out to them as necessary), and
+thus you can customize the warning system.
+Under an X display, you can press Shift-Control-G to force a "critical
+quit".  This will immediately display a backtrace and pop you into the
+debugger, regardless of the settings of `inhibit-quit' and
+`debug-on-quit'.
+C-g now works properly even on systems that don't implement SIGIO or
+for which SIGIO is broken (e.g. IRIX 5.3 and older versions of Linux).
+In addition, the SIGIO support has been fixed for many systems on
+which it didn't always work properly before (e.g. HPUX and Solaris).
+*** Events
+----------
+** INCOMPATIBLE CHANGE **: Many event functions have been changed to
+accept and return windows instead of frames.
+New function: `event-live-p', specifying whether `deallocate-event'
+has been called on an event.
+The "menu event" type has been renamed to "misc-user event", and
+encompasses scrollbar events as well as menu events.  We are planning
+on making it also encompass toolbar events in a future release.
+New functions are provided for determining whether an particular
+sections of a frame: `event-over-border-p', `event-over-glyph-p',
+`event-over-modeline-p', `event-over-text-area-p', and
+`event-over-toolbar-p'.  The old, kludgey methods of checking the
+window-height, the internal-border-width, etc. are unreliable and
+should not be used.
+New functions `event-window-x-pixel' and `event-window-y-pixel' are
+provided for determining where in a particular window an event
+happened.
+New functions `event-glyph-x-pixel' and `event-glyph-y-pixel' are
+provided for determining where in a particular glyph an event
+happened.
+New function `event-closest-point', which returns the closest buffer
+position to the event even if the event did not occur over any text.
+New variable `unread-command-events', superseding the older
+`unread-command-event'.
+Many event-loop bugs have been fixed.
+*** Extents
+-----------
+The extent code has been largely rewritten.  It should be faster and
+more reliable.
+The text-property implementation has been greatly improved.
+Some new extent primitives are provided to return the position of the
+next or previous property change in a buffer.
+Extents can now have a parent specified; then all of its properties
+(except for the buffer it's in and its position in that buffer) come
+from that extent.  Hierarchies of such extents can be created.
+Extents now have a `detachable' property that controls what happens
+(they either get detached or shrink down to zero-length) when their
+text is deleted.  Previously, such extents would always be detached.
+The `invisible' property on extents now works.
+`map-extents' has three additional parameters that provide more
+control over which extents are mapped.
+`map-extents' deals better with changes made to extents in the
+buffer being mapped over.
+A new function `mapcar-extents' (an alternative to `map-extents') has
+been provided and should be easier to use than `map-extents'.
+*** Faces
+---------
+Faces can now be buffer-local, window-local, and device-local as well
+as frame-local, and can be further restricted to a particular device
+type or class.  The way in which faces can be controlled is now based
+on the general and powerful specifier mechanism; see above.
+The new function `set-face-property' generalizes `set-face-font',
+`set-face-foreground', etc. and takes many new optional arguments, in
+accordance with the new specifier mechanism.
+The new functions `face-property' and `face-property-instance'
+generalize `face-font', `face-foreground', etc. and take many new
+optional arguments, in accordance with the new specifier mechanism.
+(`face-property' returns the value, if any, that was specified for a
+particular locale, and `face-property-instance' returns the actual
+value that will be used for display.  See the section on specifiers.)
+The functions `face-font', `face-foreground', `face-background',
+`set-face-font', `set-face-foreground', `set-face-background',
+etc. are now convenience functions, trivially implemented using
+`face-property' and `set-face-property' and take new optioanl
+arguments in accordance with those functions.  New convenience
+functions `face-font-instance', `face-foreground-instance',
+`face-background-instance', etc. are provided and are trivially
+implemented using `face-property-instance'.
+Inheritance of face properties can now be specified.  Each individual
+face property can inherit differently from other properties, or not
+inherit at all.
+You can set user-defined properties on faces using
+`set-face-property'.
+You can create "temporary" faces, which are faces that disappear
+when they are no longer in use.  This is as opposed to normal
+faces, which stay around forever.
+The function `make-face' takes a new optional argument specifying
+whether a face should be permanent or temporary, and returns the
+actual face object rather than the face symbol, as in previous
+versions of XEmacs.
+The function `face-list' takes a new optional argument specifying
+whether permanent, temporary, or both kinds of faces should be
+returned.
+Faces have new TTY-specific properties: `highlight', `reverse',
+`alternate', `blinking', and `dim'.
+Redisplay is smarter about dealing with face changes: changes to a
+particular face no longer cause all frames to be cleared and
+redisplayed.
+The Edit-Faces package is provided for interactively changing faces.
+A menu item on the options menu is provided for this.
+New functions are provided for retrieving the ascent, descent, height,
+and width of a character in a particular face.
+*** Fonts, Colors
+-----------------
+** INCOMPATIBLE CHANGE **: The old "font" and "pixel" objects are gone.
+In place are new objects "font specifier", "font instance", "color
+specifier", and "color instance".  Functions `font-name', `pixel-name'
+(an obsolete alias for `color-name'), etc. are now convenience
+functions for working with font and color specifiers.  Old code that
+is not too sophisticated about working with font and pixel objects may
+still work, though.  (For example, the idiom `(font-name (face-font
+'default))' still works.)
+You can now extract the RGB components of a color-instance object
+(similar to the old pixel object) with the function
+`color-instance-rgb-components'.  There is also a convenience function
+`color-rgb-components' for working with color specifiers.
+If there are no more colors available in the colormap, the nearest
+existing color will be used when allocating a new color.
+*** Frames
+----------
+What used to be called "screens" are now called "frames", for clarity
+and consistency with GNU Emacs.  Aliases are provided for all the old
+screen functions and variables, to avoid introducing a huge E-Lisp
+incompatibility.
+The frame code has been merged with GNU Emacs 19.28, providing
+improved functionality for many functions.
+*** Glyphs, Images, and Pixmaps
+-------------------------------
+Glyphs (used in various places, i.e. as begin-glyphs and end-glyphs
+attached to extents and appearing in a buffer or in marginal
+annotations; as the truncator and continuor glyphs marking line wrap
+or truncation; as an overlay at the beginning of a line; as the
+displayable element in a toolbar button; etc.) can now be
+buffer-local, window-local, frame-local, and device-local, and can be
+further restricted to a particular device type or class.  The way in
+which faces can be controlled is now based on the general and powerful
+specifier mechanism; see above.
+** INCOMPATIBLE CHANGE **: The glyph and pixmap API has been completely
+overhauled.  A new Lisp object "glyph" is provided and should be used
+where the old "pixmap" object would have been used.  The pixmap object
+exists no longer.  There are also new Lisp objects "image specifier"
+and "image instance" (an image-instance is the closest equivalent to
+what a pixmap object was).  More work on glyphs and images is slated
+for 19.13.  The glyph and image docs in the Lisp Reference Manual are
+incomplete and will be finished in 19.13.
+The new function `set-glyph-property' allows setting of all the
+glyph properties (`baseline', `contrib-p', etc.).  Convenience
+functions for particular properties are also provided, just like
+for faces.
+You can set user-defined properties on glyphs using the new function
+`set-glyph-property'.
+When displaying pixmaps, existing, closest-matching colors will be
+used if the colormap is full.
+If the compface library is compiled into XEmacs, there is built-in
+support for displaying X-Face bitmaps. (These are typically small
+pictures of people's faces, included in a mail message through the
+X-Face: header.) VM and highlight-headers will automatically use the
+built-in X-Face support if it is available.
+Annotations in the right margin (as well as the left margin) are now
+implemented.  The left and right margin width functions have been
+superseded by the specifier variables `left-margin-width' and
+`right-margin-width', allowing much more flexible control through the
+specifier mechanism.
+** INCOMPATIBLE CHANGE **: The variable `use-left-overflow',
+for controlling annotations in the left margin, is now a specifier
+variable instead of a buffer-local variable.  (There is also a new
+variable `use-right-overflow', that is complementary.)
+*** Hashing
+-----------
+Two new types of weak hashtables can be created: key-weak and
+value-weak.  In a key-weak hashtable, an entry remains around
+if its key is referenced elsewhere, regardless of whether this
+is also the case for the value.  Value-weak hashtables are
+complementary. (This is as opposed to the traditional weak
+hashtables, where an entry remains around only if both the
+key and value are referenced elsewhere.) New functions
+`make-key-weak-hashtable' and `make-value-weak-hashtable'
+are provided for creating these hashtables.
+The new function `md5' is provided for performing an MD5
+hash of an object.  MD5 is a secure message digest algorithm
+developed by RSA, inc.
+*** Keymaps
+-----------
+The FSF GNU Emacs concept of `function-key-map' is now partially
+implemented.  This allows conversion of function-key escape sequences
+such as `ESC [ 1 1 ~' into an equivalent human-readable keysym such as
+`F1'.  This work will be completed in 19.14.  The function-key map is
+device-local and controllable through the functions
+`device-function-key-map' and `set-device-function-key-map'.
+`where-is-internal' now correctly searches minor-mode keymaps,
+extent-local keymaps, etc.  As a side effect of this, menu items will
+now correctly show the keyboard equivalent for commands that are
+available through a minor-mode keymap, extent-local keymap, etc.
+** INCOMPATIBLE CHANGE **: The modifier key "Symbol" has
+been renamed to "Alt", for compatibility with the rest of the world.
+Keep in mind that on many keyboards, the key labelled "Alt" actually
+generates the "Meta" modifier.  (On Sun keyboards, however, the key
+labelled "Alt" does indeed generate the "Alt" modifier, and the key
+labelled with a diamond generates the "Meta" modifier.)
+*** Mouse, Active Region
+------------------------
+The mouse internals in mouse.el have been rewritten.  Hooks have been
+provided for easier customization of mouse behavior.  For example, you
+can now easily specify an action to be invoked on single-click
+(i.e. down-up without appreciable motion), double-click, drag-up, etc.
+Some code from FSF GNU Emacs has been ported over, generalizing some of
+the X-specific mouse stuff.
+** INCOMPATIBLE CHANGE **: The function `set-mouse-position' accepts
+a window instead of a frame.
+New function `mouse-position' that obsoletes and is more powerful than
+`read-mouse-position'.
+New functions `mouse-pixel-positon' and `set-mouse-pixel-position' for
+working with pixels instead of characters.
+The active (Zmacs) region is now highlighted using the `zmacs-region-face'
+instead of the `primary-selection-face'; this generalizes what used
+to be X-specific.
+New functions `region-active-p', `region-exists-p', and `activate-region'
+provide a uniform API for dealing with the region irrespective of
+whether the variable `zmacs-regions' is set.
+XEmacs is now a better X citizen with respect to the primary selection:
+it does not stomp on the primary selection quite so much.  This makes
+things more manageable if you set `zmacs-regions' to nil.
+*** Processes
+-------------
+Various process race conditions and bugs have been fixed.  Problems
+with process termination not getting noticed until much later (if at
+all) should be gone now, as well as problems with zombie processes
+under some systems.
+SOCKS support is now included.  SOCKS is a package that allows hosts
+behind a firewall to gain full access to the Internet without
+requiring direct IP reachability.
+*** Windows
+-----------
+Windows 95 is still not out yet.
+** INCOMPATIBLE CHANGE **: The functions `locate-window-from-coordinates'
+and `window-edges' have been eliminated.  It no longer makes sense to
+work with windows in terms of character positions, because windows can
+(and often do) have many differently-sized fonts in them, because the
+3-D modeline is not exactly one line high, etc.
+The new functions `window-pixel-edges', `window-highest-p',
+`window-lowest-p', `frame-highest-window', and `frame-lowest-window'
+are provided as substitutes for the above-mentioned, deleted
+functions.
+The function `window-end' now takes an optional GUARANTEE argument
+that will ensure that the value is actually correct as of the next
+redisplay.
+The window code has been merged with GNU Emacs 19.28, providing
+improved functionality for many functions.
+*** System-Specific Information
+-------------------------------
+Georg Nikodym's dynodump package is provided, for proper unexec()ing
+on Solaris systems.  Executables built on Solaris 2.3 can now run on
+Solaris 2.4 without crashing; similarly with executables built on one
+type of Sun machine and run on another.
+AIX 4.x is supported.
+The NeXTstep operating system is supported in TTY mode (this is still
+in beta).  There are plans to port XEmacs to the NeXTstep window
+system, but it may be awhile before this is complete.
+Problems with the `round' function causing arithmetic errors on HPUX 9
+have been fixed.
+You can now build XEmacs as an ELF executable on Linux systems that
+support ELF.
+Various other new system configurations are supported.
+*** Packages
+------------
+Most packages have been updated to the latest available versions.
+Some of the new Emacs Lisp packages ---
+Hyperbole: the everyday information manager.  Provides a Rolodex,
+	   allows links to be embedded in text, etc.
+OOBR: a sophisticated class browser for object-oriented languages.
+viper: a better VI emulator that allows Emacs and VI features
+to coexist happily.
+hm--html-menus: a sophisticated package for editing HTML code,
+		from Heiko Muenkel.
+ksh-mode.el: for editing shell scripts.
+lazy-lock.el: a lazy, on-the-fly fontifier.
+paren.el: an improved matching paren highlighter
+Major changes to existing packages --
+VM: has a toolbar, many other nice features.
+w3: has a toolbar, many other nice features.
+ediff: provides three-way merging, has a better user interface.
+info: has a toolbar.
+highlight-headers.el: now highlights URL's and makes them active so
+		      that when clicked either Netscape 1.1 is called
+		      or Emacs W3 is run.
+** 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, C++ and Objective-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 lemacs.
+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 Lucid Emacs.  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 lemacs
+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 lemacs 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 lemacs 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   EmacsFrame
+now it is
+argv[0]                 shell           pane    SCREEN-NAME
+ApplicationShell        EmacsShell      Paned   EmacsFrame
+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 lemacs 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 lemacs 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 lemacs, and will be able to use newer versions of lemacs 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 lemacs 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.

Mercurial > hg > xemacs-beta

comparison etc/NEWS @ 0:376386a54a3c r19-14