XEmacs History
John A. Turner
The following is an excerpt from the NEWS file included in the XEmacs
distribution. To see the whole thing, select the last item under the
Help menu (or do C-h n).
----------------------------------------------------------------------------
|John A. Turner |"At every cross-way on the path that leads to the |
|Los Alamos Natl. Lab. | future, tradition has placed against us ten |
|e-mail: tur...@lanl.gov| thousand men to guard the past." |
| |(I don't know who said this. If you do, tell me.)|
----------------------------------------------------------------------------
* The History of XEmacs
=======================
This product is an extension of GNU Emacs, previously known to some as
"Lucid Emacs", "Xemacs", or "Era". It is based on an early version of Emacs
Version 19 from the Free Software Foundation, and stems from a collaboration
of Lucid, Inc. with SunPro (a division of Sun Microsystems, Inc.) and the
University of Illinois.
** Why Another Version of Emacs? (The Lucid, Inc. Point of View)
=================================================================
Lucid's latest product, Energize, is a C/C++ development environment.
Rather than invent (and force our users to learn) a new user-interface, we
chose to build part of our environment on top of the world's best editor,
FSF GNU Emacs. (Though our product is commercial, the work we did on is
free software, and is useful without having to purchase our product.)
We needed a version of Emacs with mouse-sensitive regions, multiple fonts,
the ability to mark sections of a buffer as read-only, the ability to detect
which parts of a buffer has been modified, and many other features.
*** Why Not Epoch or FSF GNU Emacs?
-----------------------------------
For our purposes, the existing version of Epoch was not sufficient; it did
not allow us to put arbitrary pixmaps/icons in buffers, `undo' did not
restore changes to regions, regions did not overlap and merge their
attributes in the way we needed, and several other things.
We could have devoted our time to making Epoch do what we needed (and, in
fact, we spent some time doing that in 1990) but, since the Free Software
Foundation planned to include Epoch-like features in their Version 19, we
decided that our efforts would be better spent improving FSF GNU Emacs
instead of Epoch.
Our original hope was that our changes to FSF GNU Emacs would be
incorporated into the "official" v19. However, scheduling conflicts arose,
and we found that, given the amount of work still remaining to be done, we
didn't have the time or manpower to do the level of coordination that would
be necessary to get our changes accepted by the Free Software Foundation.
Consequently, we released our work as a forked branch of Emacs, instead of
delaying any longer.
Roughly a year after Lucid Emacs 19.0 was released, a beta version of the
Free Software Foundation branch of Emacs 19 was released. This version
was better in some areas, and worse in others, as reflects the differing
focus of our development efforts.
We planned to continue developing and supporting Lucid Emacs, and merging in
bug fixes and new features from the Free Software Foundation branch as
appropriate; we did not plan to discard any of the functionality that we
implemented which Richard Stallman of the Free Software Foundation has
chosen not to include in his version.
However, events have overtaken us, and Lucid, Inc. has effectively ceased
doing business and is (September 1994) in the process of being sold. Our
efforts on Lucid Emacs have also ceased and we've turned over the continued
enhancement of Lucid Emacs to the University of Illinois under Chuck
Thompson, a member of the Lucid Emacs team and a maintainer of Epoch.
At the same time, Lucid Emacs has been renamed XEmacs to reflect the
substantial contribution of the University of Illinois with the support of
Sun Microsystems.
Certain elements of Lucid Emacs, or derivatives of them, have been ported to
the FSF GNU Emacs. We have not been doing work in this direction, because
we feel that Lucid Emacs has a cleaner and more extensible substrate, and
that any kind of merger between the two branches would be far easier by
merging the Free Software Foundation changes into our version than the other
way around.
We were working closely with the Epoch developers to merge in the
remaining Epoch functionality which Lucid Emacs does not yet have. Epoch
and Lucid Emacs will soon be one and the same thing. Work is being done on
a compatibility package which will allow Epoch 4 code to run in XEmacs with
little or no change. (As of 19.8, Lucid Emacs is running a descendant of
the Epoch redisplay engine.)
** Why Another Version of Emacs? (The SunPro Point of View)
============================================================
Emacs 18 has been around for a long, long time. Version 19 was supposed to
be the successor to Emacs 18 with X support. It was going to be available
"real soon" for a long time (some people remember hearing about v19 as early
as 1984!), but it never came out. v19 development was going very, very
slowly, and from the outside it seemed that it was not moving at all. In
the meantime other people gave up waiting for v19 and decided to build their
own X-aware Emacsen. The most important of these was probably Epoch, which
came from the University of Illinois and was based on v18.
Around two years ago we decided that we wanted an integrated editor. We
contracted with the University of Illinois to provide a number of basic
enhancements to the functionality in Epoch. The University of Illinois
initially was planning to deliver this on top of Epoch code.
In the meantime (actually some time before we talked with the University of
Illinois) Lucid had decided that it also wanted to provide an integrated
environment with an integrated editor. Lucid decided that the Version 19
basis was a better one than Version 18 and thus decided not to use Epoch but
instead work with Richard Stallman, the head of the Free Software Foundation
and principle author of Emacs, on getting Version 19 out. At some point
Stallman and Lucid parted ways. Lucid kept working and got a Version 19 out
that they called Lucid Emacs 19.
After Lucid's v19 came out it became clear to us (the University of Illinois
and SunPro) that the right thing to do was to push for an integration of
both Lucid Emacs and Epoch, and to get the deliverables that we were asking
from the University of Illinois on top of this integrated platform. Through
the last two years, SunPro has been actively supporting this product and has
been investing a comparable amount of effort into it as Lucid has.
Substantial portions of the current code have originated under the support
of SunPro, either directly in SunPro, or in the University of Illinois but
paid for by us. This code was kept away from Lucid for a while, but later
was made available to them. Initially Lucid didn't know that we were
supporting UofI, but later we were open about it.
Currently, there is basically no difference in the source trees between what
is at the University of Illinois, SunPro, or Lucid. All the development
sites are in sync.
SunPro originally called the integrated product ERA, for "Emacs Rewritten
Again". SunPro and Lucid recently came to an agreement to find a name for
the product that was not specific to either company. An additional
constraint that Lucid placed on the name was that it must contain the word
"Emacs" in it -- thus "ERA" is not acceptable. The agreed-upon name is
"XEmacs", and this is what the product will be called starting with the
19.11 release.
* What's Different?
===================
Unless otherwise noted, this section describes differences between XEmacs
version 19.* and GNU Emacs version 18.57.
XEmacs *currently* requires an X Window System environment to run. TTY
support is currently being worked on. It will be included in the 19.12
release.
Auto-configure support has been added, so it should be fairly easy to compile
XEmacs on different systems. If you have any problems or feedback about
compiling on your system, please let us know.
We have reimplemented the basic input model in a more general way; instead of
X input being a special-case of the normal ASCII input stream, Emacs has a
concept of "input events", and ASCII characters are a subset of that. The
events that Emacs knows about are not X events, but are a generalization of
them, so that Emacs can eventually be ported to different window systems.
We have reimplemented keymaps so that sequences of events can be stored into
them instead of just ASCII codes; it is possible to, for example, bind
different commands to each of the chords Control-h, Control-H, Backspace,
Control-Backspace, and Super-Shift-Backspace. Key bindings, function key
bindings, and mouse bindings live in the same keymaps.
Input and display of all ISO-8859-1 characters is supported.
You can have multiple X windows ("screens" in xemacs terminology).
Our Emacs has objects called "extents" and "faces", which are roughly
analogous to Epoch's "buttons," "zones," and "styles." An extent is a region
of text (a start position and an end position) and a face is a collection of
textual attributes like fonts and colors. Every extent is displayed in some
"face", so changing the properties of a face immediately updates the display
of all associated extents. Faces can be screen-local: you can have a region
of text which displays with completely different attributes when its buffer
is viewed from a different X window.
The display attributes of faces may be specified either in lisp or through
the X resource manager.
Pixmaps of arbitrary size can be embedded in a buffer.
Variable width fonts work.
The height of a line is the height of the tallest font on that line, instead
of all lines having the same height.
Emacs use the MIT "Xt" toolkit instead of raw Xlib calls, which makes it be
a more well-behaved X citizen (and also improves portability). A result of
this is that it is possible to include other Xt "Widgets" in the Emacs
window. Also, Emacs understands the standard Xt command-line arguments.
Emacs understands the X11 "Selection" mechanism; it's possible to define
and customize selection converter functions and new selection types from
Emacs Lisp, without having to recompile Emacs.
Emacs provides support for ToolTalk on systems that have it.
Emacs now supports the Zmacs/Lispm style of region highlighting, where the
region between the point and mark is highlighted when in its "active" state.
Emacs has a menubar, whose contents are customizable from emacs-lisp.
This menubar looks Motif-ish, but does not require Motif. If you already
own Motif, however, you can configure Emacs to use a *real* Motif menubar
instead. If you have OLIT ("OpenLook Intrinsics"), you can use an
OpenWindows-like menubar.
Emacs can ask questions using popup dialog boxes. Any command executed from
a menu will ask yes/no questions with dialog boxes, while commands executed
via the keyboard will use the minibuffer.
Emacs has vertical scrollbars.
The initial load-path is computed at run-time, instead of at compile-time.
This means that if you move the Emacs executable and associated directories
to somewhere else, you don't have to recompile anything.
You can specify what the title of the Emacs windows and icons should be
with the variables `screen-title-format' and `screen-icon-title-format',
which have the same syntax as `mode-line-format'.
Emacs now supports floating-point numbers.
Emacs now knows about timers directly, instead of them being simulated by
a subprocess.
Emacs understands truenames, and can be configured to notice when you are
visiting two names of the same file. See the variables find-file-use-truenames
and find-file-compare-truenames.
If you're running on a machine with audio hardware, you can specify sound
files for Emacs to play instead of the default X beep. See the documentation
of the function load-sound-file and the variable sound-alist.
An Emacs screen can be placed within an "external client widget" managed by
another application. This allows an application to use an Emacs screen as its
text pane rather than the standard Text widget that is provided with Motif or
Athena. Emacs supports Motif applications, generic Xt (e.g. Athena)
applications, and raw Xlib applications.
Random changes to the emacs-lisp library: (some of this was not written by
us, but is included because it's free software and we think it's good stuff)
- there is a new optimizing byte-compiler
- there is a new abbrev-based mail-alias mechanism
- the -*- line can contain local-variable settings
- there is a new TAGS package
- there is a new VI-emulation mode (evi)
- there is a new implementation of Dired
- there is a new implementation of Isearch
- the VM package for reading mail is provided
- the W3 package for browsing the World Wide Web hypertext information
system is provided
There are many more specifics in the "Miscellaneous Changes" section, below.
The online Emacs Manual and Emacs-Lisp Manual are now both relatively
up-to-date.
** Differences between XEmacs 19 and FSF Emacs 19
=================================================
In XEmacs, events are first-class objects. FSF19 represents them as
integers, which obscures the differences between a key gesture and the
ancient ASCII code used to represent a particular overlapping subset of them.
In XEmacs, keymaps are first-class opaque objects. FSF19 represents them as
complicated combinations of association lists and vectors. If you use the
advertised functional interface to manipulation of keymaps, the same code
will work in XEmacs, Emacs 18, and and FSF Emacs 19; if your code depends on
the underlying implementation of keymaps, it will not.
XEmacs calls a top-level emacs X window a "screen," which is the terminology
that Epoch used. FSF 19 calls these "frames." We may adopt the term "frame"
as well, but we have not done so yet.
XEmacs uses "extents" to represent all non-textual aspects of buffers; FSF 19
uses two distinct objects, "text properties" and "overlays", which divide up
the functionality between them. Extents are a superset of the functionality
of the two FSF data types. A large subset of the FSF 19 interface to text
properties is supported in xemacs (with extents being the underlying
representation.)
Extents can be made to be copied into strings, and thus restored by kill
and yank. Thus, one can specify this behavior on either "extents" or
"text properties", whereas in FSF 19 text properties always have this
behavior and overlays never do.
FUHRMANN
John> The following is an excerpt from the NEWS file included in
John> the XEmacs distribution. To see the whole thing, select the
John> last item under the Help menu (or do C-h n).
John> This product is an extension of GNU Emacs, previously known
John> to some as "Lucid Emacs", "Xemacs", or "Era". It is based
John> on an early version of Emacs Version 19 from the Free
John> Software Foundation, and stems from a collaboration of
John> Lucid, Inc. with SunPro (a division of Sun Microsystems,
John> Inc.) and the University of Illinois.
...
[stuff deleted]
I am one those people who switched some months ago from FSF to Xemacs,
because xemacs is a "better X citizen" as somewhere (may be in this news file)
has been said and because I like the Motif interface (which isn't free,
but, as far as I know, moderately prized in comparision to other UNIX
software). Despite of some bugs (mainly in the TPU package - which
I could remove) I like xemacs very much.
As I am one of the maintainers of the emacs installation at our site
I have to support (for "backward compatibility") FSF emacs, too.
This causes a lot of additional work because some LISP packages
are not fully compatible etc. (I guess most people in this newsgroup
know the problem).
So my question (after lucid.com is dead) is:
Isn't it time to merge FSF and Xemacs in an emacs V20.x ?
I know the problem with FSF : RMS doesnt want to support Motif
because it is not free. But isn't there any possibility for
a compromise ?
For instance the following:
As far as I understand, Xemacs is rather GUI independent, it compiles
either with Athena or with Motif, so the code should be modular.
So there could exist a emacs-20.x distribution _without_ the motif
code and another package not distributed by FSF called
motif-interface-for-emacs-20.x or so which could be plugged into
the basic distribution.
May be this proposal is naive, but i couldn't resist to make it.
At least I think that it could be useful to start this thread.
Juergen Fuhrmann
--
Juergen Fuhrmann fuhr...@iaas-berlin.d400.de
Weierstrass Institute for Applied Analysis and Stochastics (WIAS)
Mohrenstrasse 39 D-10117 Berlin, Germany
phone: (49) 030 20377 560 fax: (49) 030 2004975
* Bad News is No News *
Chuck Thompson
FUHRMANN> time to merge FSF and Xemacs in an emacs V20.x ? I know
FUHRMANN> the problem with FSF : RMS doesnt want to support Motif
FUHRMANN> because it is not free. But isn't there any possibility
FUHRMANN> for a compromise ?
(official-word-mode)
Motif is _not_ a sticking point in a potential merger. There are,
however, other issues preventing a merger. At this point in time
there will be no organized merger of XEmacs and FSF Emacs. There will
continue to be an informal flow of ideas between the two editors as
there has always been.
I have talked with RMS. There are a number points where we could
reach a compromise. But there are still too many areas where we have
sharp differences of opinion. By 'we' I mean all of the XEmacs
developer's, not just myself. This situation is nothing new. It is
the reason XEmacs came into existence in the first place. Someday I
hope that there will once again be a single Emacs 19 (or 20). But it
is not going to be anytime soon.
(signature-mode)
--
Chuck Thompson primary XEmacs maintainer
Research Programmer
Department of Computer Science
University of Illinois at Urbana-Champaign
Paul A Vixie
I've heard that this is difficult because the internal interfaces have changed
a lot. I am sad to hear it, since I expect FSF's user population and therefore
its selection of contributed ELisp packages to continue running roughshod over
everything else, even if something else has better internal interfaces. RMS'
version of Emacs is the 600-pound gorilla in this picture -- it will sit where-
ever it wants to.
After careful consideration, I do not plan to switch to XEmacs. Better isn't
good enough, I don't want to learn how to convert ELisp. I expect that I am
representative, in this way, of the largest segment of the Emacs population.
--
Paul Vixie
La Honda, CA
<pa...@vix.com>
decwrl!vixie!paul
michael lamoureux
>> Isn't it time to merge FSF and Xemacs in an emacs V20.x ?
paul> RMS' version of Emacs is the 600-pound gorilla in this picture
paul> -- it will sit where- ever it wants to.
Exactly. And after the Ange-FTP fiasco, I wouldn't consider
running it. There's something to be said for distributing software
the way the author wrote it.
paul> Better isn't good enough
I will never understand this attitude. Better is always good
enough. If you can't determine which is better, then you have to make
a tough choice. But if it's obvious which is better, choosing the
inferior tool seems silly. (note that I'm not necessarily saying that
Xemacs is better than RMSmacs...and if I were, it would just be my
opinion, and what's that worth? ;-)
IMHO,
Michael
Jason L Tibbitts III
>>>>> "paul" == Paul A Vixie <vi...@gw.home.vix.com> writes:
paul> RMS' version of Emacs is the 600-pound gorilla in this picture -- it
paul> will sit where- ever it wants to.
ML> Exactly. And after the Ange-FTP fiasco, I wouldn't consider running
ML> it. There's something to be said for distributing software the way the
ML> author wrote it.
What exactly is the Ange-FTP fiasco? Does this have something to do with
the fact that the Ange-FTP I had under Emacs 18 could handle VMS and other
odd hosts while FSF 19 doesn't seem to?
--
Jason L. Tibbitts III - ti...@tcamc.uh.edu - 713/743-8687 - 221SR1
System Admin: Texas Center for Advanced Molecular Computation
1994 PC800 "Kuroneko" DoD# 1723 GM/CS/S
d--- -p+ c++++ l++ u+++ e+ m---(++) n--- s/-- h* f+ g+ w+ t- r- y+**
Jurgen Botz
michael lamoureux <lam...@engin.umich.edu> wrote:
> "paul" == Paul A Vixie <vi...@gw.home.vix.com> writes:
>paul> Better isn't good enough
>
> I will never understand this attitude. Better is always good
>enough. If you can't determine which is better, then you have to make
>a tough choice. But if it's obvious which is better, choosing the
>inferior tool seems silly.
An "inferior" tool might still have functionality that users depend
on, and which does not exist or works differently in the "superior"
tool. In this case the better tool had better be much better before
the work to switch or support both is justified.
Stainless Steel Rat
>>>>> writes:
paul> Better isn't good enough
michael> I will never understand this attitude. Better is always
michael> good enough.
"Better" is a relative term. Better for what? For my own personal use,
Emacs 18.59 is "better" than either version of 19. If XEmacs 19.12 has
useful and usable tty support than it may become "better" for me.
--
Rat <rat...@ccs.neu.edu> |Do not taunt Happy Fun Ball.
http://www.ccs.neu.edu/home/ratinox|
PGP Public Key: Ask for one today! |
michael lamoureux
>>>>>> "ML" == michael lamoureux <lam...@erpland.engin.umich.edu> writes:
>>>>>> "paul" == Paul A Vixie <vi...@gw.home.vix.com> writes:
paul> RMS' version of Emacs is the 600-pound gorilla in this picture -- it
paul> will sit where- ever it wants to.
ML> Exactly. And after the Ange-FTP fiasco, I wouldn't consider running
ML> it. There's something to be said for distributing software the way the
ML> author wrote it.
jason> What exactly is the Ange-FTP fiasco? Does this have something
jason> to do with the fact that the Ange-FTP I had under Emacs 18
jason> could handle VMS and other odd hosts while FSF 19 doesn't seem
jason> to?
Bingo. RMS rewrote Ange-FTP (or at least parts of it) for
emacs19 without contacting Andy at all. There was some stuff that RMS
didn't understand in it, so he decided to just leave it out. Ugh!!
so I heard,
Michael
michael lamoureux
jurgen> In article <LAMOUR.94O...@erpland.engin.umich.edu>,
jurgen> michael lamoureux <lam...@engin.umich.edu> wrote:
>> "paul" == Paul A Vixie <vi...@gw.home.vix.com> writes:
paul> Better isn't good enough
>> I will never understand this attitude. Better is always good
>> enough. If you can't determine which is better, then you have to
>> make a tough choice. But if it's obvious which is better, choosing
>> the inferior tool seems silly.
jurgen> An "inferior" tool might still have functionality that users
jurgen> depend on, and which does not exist or works differently in
jurgen> the "superior" tool. In this case the better tool had better
jurgen> be much better before the work to switch or support both is
jurgen> justified.
In my opinion, better is relative. If a tool is missing
functionality that users depend on, then it wouldn't be better than a
tool that had it. If the relative "goodness" of a tool is split for
different features, then that requires you to look at the pros and
cons of each, and estimate the usefulness of the tools based on your
findings. I alluded to this above (3rd sentence).
I believe Lucid Emacs was clearly better than FSF 19 at one
point. I think as they come closer together featurewise, it becomes a
tougher choice. I hope that in December (it's still December, right?)
that Xemacs will close the gap for most of the remaining areas in
which it lags FSF 19.
There are several reasons that I choose to use Xemacs over FSF
19. I seriously doubt that there are many (if any) others who run it
for the same reasons I do. I can see reasons that people would choose
FSF 19 at this point. I don't think that for many people either tool
is clearly better.
whatever,
Michael
James Buster
Chuck Thompson <cth...@willow.cs.uiuc.edu> wrote:
> FUHRMANN> So my question (after lucid.com is dead) is: Isn't it
> FUHRMANN> time to merge FSF and Xemacs in an emacs V20.x ? I know
> FUHRMANN> the problem with FSF : RMS doesnt want to support Motif
> FUHRMANN> because it is not free. But isn't there any possibility
> FUHRMANN> for a compromise ?
>
>(official-word-mode)
>
>Motif is _not_ a sticking point in a potential merger. There are,
>however, other issues preventing a merger.
>I have talked with RMS. There are a number points where we could
>reach a compromise. But there are still too many areas where we have
>sharp differences of opinion.
Please elucidate. What are the sticking points, and are they technical or
political?
--
James Buster
bit...@netcom.com
David Koppelman
For how much longer will there be new versions? FSF has been around
along time. Would the people writing Xemacs have that kind of staying
power? (I have no reason to believe they won't.)
David
Hamish Macdonald
>>>>> In message <KOPPEL.94O...@gate.ee.lsu.edu>,
>>>>> kop...@gate.ee.lsu.edu (David Koppelman) wrote:
David> There's another factor to consider when choosing FSF Emacs or
David> Xemacs. For how much longer will there be new versions? FSF
David> has been around along time. Would the people writing Xemacs
David> have that kind of staying power? (I have no reason to believe
David> they won't.)
This is silly... The source code is freely distributable. As long as
there are people interested in fixing bugs and releasing new versions,
there will be new versions. I expect that if Chuck and Ben fell off
the face of the earth, that there would be people interested in
carrying on their work.
Stainless Steel Rat
ML> Exactly. And after the Ange-FTP fiasco, I wouldn't consider running
ML> it. There's something to be said for distributing software the way the
ML> author wrote it.
Jason> What exactly is the Ange-FTP fiasco? Does this have something to do
Jason> with the fact that the Ange-FTP I had under Emacs 18 could handle
Jason> VMS and other odd hosts while FSF 19 doesn't seem to?
And just about every kind of non-Unix FTP server out there. RMS removed all
the non-Unix file support because he didn't understand it. Bzzt! Thank you
for crippling one of the neatest packages to come along since GNU Emacs.
--
Rat <rat...@ccs.neu.edu> |Warning: pregnant women, the elderly, and
http://www.ccs.neu.edu/home/ratinox|children under 10 should avoid prolonged
PGP Public Key: Ask for one today! |exposure to Happy Fun Ball.
David
>>>>> "Rat" == Stainless Steel Rat <rat...@ccs.neu.edu> writes:
>>>>> "Jason" == Jason L Tibbitts <ti...@tcamc.uh.edu> writes:
ML> Exactly. And after the Ange-FTP fiasco, I wouldn't consider running
ML> it. There's something to be said for distributing software the way the
ML> author wrote it.
Jason> What exactly is the Ange-FTP fiasco? Does this have something to do
Jason> with the fact that the Ange-FTP I had under Emacs 18 could handle
Jason> VMS and other odd hosts while FSF 19 doesn't seem to?
Rat> And just about every kind of non-Unix FTP server out there. RMS
Rat> removed all the non-Unix file support because he didn't
Rat> understand it. Bzzt! Thank you for crippling one of the neatest
Rat> packages to come along since GNU Emacs.
Now Rat, I have seen you on the net long enough to know that you don't
follow the stream. I am sure that you have solved this problem for
yourself. Is there some way we Emacs-19 users could get the
functionality back? (And don't ask me to go back to Emacs 18!)
/David
--
Have you updated your .plan recently?
Stainless Steel Rat
David> Now Rat, I have seen you on the net long enough to know that you don't
David> follow the stream. I am sure that you have solved this problem for
David> yourself. Is there some way we Emacs-19 users could get the
David> functionality back? (And don't ask me to go back to Emacs 18!)
Ok, I won't. But the full functionality won't be restored until efs goes
into widespread release.
--
Rat <rat...@ccs.neu.edu> |When not in use, Happy Fun Ball should be
http://www.ccs.neu.edu/home/ratinox|returned to its special container and kept
PGP Public Key: Ask for one today! |under refrigeration.