11:13 a.m.
We've had a bunch of queries about "XEmacs vs. GNU Emacs" in the last
couple of months. It's time someone dusted off that page; here's my
hack at it. A reader's guide:
(0) Appointed myself author. I think that's appropriate since I don't
see how there can be a consensus on writing this page correctly.
I volunteer to be maintainer for it even if you can't stand the
way I write and insist that it be ghosted. :-)
(1) I substituted "Stallman" for "RMS" throughout. I'm more
comfortable with that, but would immediately revert if most people
preferred the initials.
Ditto "GNU Emacs" for "FSF" or "FSF Emacs". This one I
feel
stronger about. RMS really gets his back up about it.
(2) Substantial but very tentative reorganization of "The XEmacs Point
of View" according to functional lines. Some updates to recent
versions of XEmacs and FSFmacs. Questions I know I need answers
to marked "####" in HTML comments. I'm sure I slipped on some
other stuff.
(3) Added a "Community Participation" section to "The XEmacs Point
of View". Comments appreciated.
(4) Added a pretty turgid description of the "legal problem" as RMS
perceives it. It's a turgid topic.
(5) Added a bunch of sections describing some philosophical
differences (starting with "What Is the Role of the FSF?").
Seemed good when I wrote it, but the whole topic is flamebait.
Comments requested.
(6) Author's disclaimer. Seems required in context, but what to say?
here it comes, in .content format:
%title%
XEmacs vs. GNU Emacs
%author%
Stephen Turnbull <stephen(a)xemacs.org>
%main%
<h1>XEmacs vs. GNU Emacs</h1>
<p>There are currently irreconcilable differences in the views
about technical, programming, design and organizational
matters between Richard Stallman and the XEmacs development
team which provide little hope for a merge to take place in
the short-term future.
<p>If you have a comment to add regarding the merge, it is a
good idea to avoid posting to the newsgroups, because of the
very heated flamewars that often result. Mail your questions
to
<a href="mailto:xemacs-beta＠xemacs.org">xemacs-beta＠xemacs.org</a>
and
<a
href="mailto:bug-gnu-emacs＠prep.ai.mit.edu">bug-gnu-emacs＠prep.ai.mit.edu</a>.
<p>Many people have noticed the great difference in focus
between the two "Viewpoints" presented here, and also have
expressed confusion about the legal issues Stallman focuses
on. The final sections present some explanation and
interpretation regarding these FAQs.
<h2>Difference between XEmacs and GNU Emacs, from the XEmacs Point of
View</h2>
<p>This section is now quite dated. Much of it refers to GNU
Emacs 19 and XEmacs 20. However, the differences described
persist in the most recent versions of both Emacsen in some
form.
<h3>User-Visible Editing Features</h3>
<p>In XEmacs, images of arbitrary size can be embedded in a
buffer. (Soon available in GNU Emacs 21.)
<p>In XEmacs, variable width fonts work. (Soon available in
GNU Emacs 21.)
<p>The height of a line is the height of the tallest font on
that line, instead of all lines having the same height. (Soon
available in in GNU Emacs 21.)
<!-- #### Is this obsolete? -->
<p>XEmacs provides support for ToolTalk on systems that have
it.
<!-- #### Probably I should drop mention of DnD and xemacs-gtk? -->
Experimental support for drag-and-drop protocols is
provided from XEmacs 21.
<p>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.
<p>XEmacs has a built-in toolbar. Four toolbars can actually
be configured: top, bottom, left, and right toolbars.
<p>XEmacs has vertical and horizontal scrollbars. Unlike in
GNU Emacs 19 (which provides a primitive form of vertical
scrollbar), these are true toolkit scrollbars. A look-alike
Motif scrollbar is provided for those who don't have
Motif. (Even for those who do, the look-alike may be
preferable as it is faster.)
<h3>General Platform Support</h3>
<p>If you're running on a machine with audio hardware, you can
specify sound files for XEmacs to play instead of the default
X beep. See the documentation of the function load-sound-file
and the variable sound-alist. XEmacs also supports the
network sound protocols NAS and EsounD.
<p>XEmacs 21 supports database protocols with LISP bindings,
currently including LDAP and PostgreSQL (21.2 only).
<p>XEmacs 20 and 21 support the Canna, Wnn, and SJ3 Japanese
input method servers directly, as well as through the X Input
Method (XIM) protocol. GNU Emacs 20 supports only the XIM
protocol. Both Emacsen support the Quail family of input
methods (implemented in LISP) for many languages.
<h3>LISP Programming</h3>
<p>From XEmacs 20 on, characters are first-class objects.
Characters can be converted to integers, but are not integers.
GNU Emacs 19, XEmacs 19, Mule 2.3 (an extensive patch to GNU
Emacs 18.55 and 19.x), and GNU Emacs 20 (incorporating Mule 3
and later Mule 4) represent them as integers.
<p>From XEmacs 20 on, the buffer is treated as an array of
characters, and the representation of buffer text is not
exposed to LISP. The GNU Emacs 20 functions like
buffer-as-multibyte are not supported.
<p>In XEmacs, events are first-class objects. GNU Emacs 19
represents them as integers, which obscures the differences
between a key gesture and the ancient ASCII code used to
represent a particular overlapping subset of them.
<p>In XEmacs, keymaps are first-class opaque objects. GNU Emacs 19
represents them as complicated combinations of association
lists and vectors. If you use the advertised functional
interface to manipulation of keymaps, the same code will work
in XEmacs, GNU Emacs 18, and GNU Emacs 19; if your code depends on
the underlying implementation of keymaps, it will not.
<p>XEmacs uses "extents" to represent all non-textual aspects
of buffers; GNU Emacs 19 uses two distinct objects, "text
properties" and "overlays", which divide up the functionality
between them. Extents are a superset of the functionality of
the two GNU Emacs data types. The full GNU Emacs 19 interface
to text properties and overlays is supported in XEmacs (with
extents being the underlying representation).
<p>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
GNU Emacs 19 text properties always have this behavior and
overlays never do.
<h3>Packaged LISP Libraries</h3>
<p>Many more packages are provided standard with XEmacs than
with GNU Emacs 19 or 20.
<p>XEmacs 21 supports an integrated package management system
which uses EFS to download, then automatically install
prebuilt LISP libraries.
<h3>Window System Programming Interface</h3>
<p>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.
<p>XEmacs supports Motif applications, generic Xt
(e.g. Athena) applications, and raw Xlib applications. An
XEmacs variant which supports GTK+ is available (but not yet
integrated to the main CVS branch), although code to take
advantage of the support is as yet scarce.
<p>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.
<!-- #### This is new! -->
<h3>Community Participation</h3>
<p>Starting with XEmacs 20, joining the XEmacs development
team is simple. Mail to <a
href="mailto:xemacs-beta＠xemacs.org">XEmacs Developers
&lt;xemacs-beta(a)xemacs.org&gt;</a>, and you're in! (If you
<em>want</em> to be, of course. You're also welcome to just
post development-related questions and bug reports.) The GNU
Emacs development team and internal mailing lists are still by
invitation only.
<p>The "bleeding edge" of mainline XEmacs development is
available by <a href="http://cvs.xemacs.org">anonymous CVS</a>
as are some subsidiary branches (check out the xemacs-gtk
module for the latest in GUI features!)
<p>CVS commit authority is broadly dispersed. Recognized
maintainers of LISP libraries who are willing to maintain
XEmacs packaged versions automatically qualify for CVS
accounts for their packages.
<h2>The FSF Point of View</h2>
<p><a href="mailto:rms＠gnu.org">Richard Stallman</a>
writes:</p>
<blockquote>
<p>XEmacs is GNU software because it's a modified version of a
GNU program. And it is GNU software because the FSF is the
copyright holder for most of it, and therefore the legal
responsibility for protecting its free status falls on us
whether we want it or not. This is why the term "GNU XEmacs"
is legitimate.
<p>But in another sense it is not GNU software, because we
can't use XEmacs in the GNU system: using it would mean paying
a price in terms of our ability to enforce the GPL. Some of
the people who have worked on XEmacs have not provided, and
have not asked other contributors to provide, the legal papers
to help us enforce the GPL. I have managed to get legal
papers for some parts myself, but most of the XEmacs
developers have not helped me get them.
<p>XEmacs was possible because free software means that anyone
can change it and distribute a modified version. I have no
regrets about establishing this freedom for Emacs. Everyone
should have the freedom to change any program, and this is not
limited to changes that the original author likes.
<p>Many people have taken advantage of the freedom to change
GNU Emacs, over the last decade. Most of them were willing to
cooperate on integrating their changes into Emacs. XEmacs
arose as a separate forked version because some of the
developers--starting with Zawinski--were unwilling to do that.
<p>People should have the freedom to decide what to work on,
including the freedom to compete with the GNU project, but
it's a shame when they make that choice. The whole community
loses when someone chooses competition rather than
cooperation.
<p>But this is worse than competition--it is unfair
competition. The XEmacs developers can and do copy code they
like from Emacs. If I could copy the code I like from XEmacs
in the same way, at least the rivalry would be fair. But I
can't do that't, because substantial parts of XEmacs don't
have legal papers, or don't have known authors.
<p>As long as we cannot use XEmacs in the GNU system, the GNU
project has to make sure that Emacs is not left behind. In
other words, we have to behave like rivals too, even though we
wish there were no rivalry. When XEmacs developers try to
persuade people to use, test, fix and enhance XEmacs instead
of Emacs, the GNU project can't sit still; we need them to
use, test, fix and enhance Emacs instead.
<p>There is good code in XEmacs, which I'd be happy to have in
a merged Emacs any day. But I cannot copy it out of XEmacs
myself because of the uncertain authorship and/or lack of
legal papers.
<p>This problem could probably be resolved, at least for large
parts of XEmacs, with substantial help from the authors of
that code. Otherwise, the GNU project has to write or find
replacements for it.
<p>I invite people who like Emacs, and want the best possible
version of Emacs to be available for use in the GNU system, to
help in one way or the other.
</blockquote>
<!-- #### This really isn't source for the RMS quote. Obsolete?
Does anyone know where that came from? If not, this can go.
<p><strong>Sources:</strong> <a
href="http://www.xemacs.org/FAQ/">FAQ</a>
item 1.0.5, and XEmacs 21.0 NEWS file
-->
<h2>What Is the Legal Issue?</h2>
<p>There is no difference in the nature of the copyrights or
licenses of the two projects. Copyright is defined by law and
international treaty, and is automatically awarded to the
author as soon as a work is published. Both projects use the
GNU General Public License to protect their work while
providing it freely to the community.
<p>XEmacs has no choice, because much of its code is
copyrighted by the Free Software Foundation, and is only
available to XEmacs under the GPL. Under that license,
redistribution is only possible under the GPL. The GNU
Project uses the GPL as a matter of principle. (XEmacs
developers generally subscribe to a similar principle, of
course.) It is the same GPL, so sharing code is 100% legal.
<p>However, copyright is governed by the <em>civil</em> code,
not the criminal code. This means that the government takes
no interest in violations of copyright as such. It only
undertakes to provide law courts where the copyright can be
enforced. It is the responsibility of the copyright holder to
sue to prevent violations and receive damages for past
violations. The government <em>cannot</em> act on the
complaints of third parties.
<p>The FSF has received legal advice that a copyright holder
in a jointly-authored work is in a weak position to enforce
its copyright unless all coauthors participate in the legal
action. Evidently the FSF would be considered a third party
with respect to non-assigned code, weakening its ability to
defend the whole work. (Author's note: You'd have to ask a
lawyer why that might be so. I am not an expert, so I will
just assure you that some lawyers I have asked informally
agree that this theory is plausible, although it has not been
tested in court. It may also be more or less applicable in
jurisdictions other than the U.S.)
<p>Based on this advice, Stallman has concluded that
incorporating <em>some</em> code copyrighted by another entity
into a work such as Emacs puts the copyright of <em>all</em>
of the work at risk of being unenforceable in court in the
case of a violation. He has judged that this risk is
unacceptably large, and therefore insists that the whole
copyright of any software the FSF undertakes to defend be
assigned to the FSF, with few exceptions.
<h3>What Is the Role of the FSF?</h3>
<p>Stallman believes that copyright in software itself is
immoral; Copyleft is a device to undermine the whole idea. He
has little empathy for people who wish to retain
copyright---after all, he has given up his own. This is the
fundamental idea behind the FSF (as opposed to the GNU
Project, which actually develops software): a holding company
for all the software copyrights that shouldn't even exist in
the first place. According to the legal argument above, such
a trust is necessary to defend the GPL, which is what prevents
proprietary firms from misappropriating the software at the
same time as it prevents the holding company (the FSF) from
being a monopoly.
<h2>Well, Isn't That Paranoid?</h2>
<p>Many developers think so, but it seems that noone who holds
a different theory has retained a lawyer to check the
precedents. The FSF has done so, so its position must be
considered most credible.
<p>Also, it is important to remember that Stallman and the FSF
are not (in this context) acting as software developers. Rather,
they perceive themselves as guardians of a social movement.
Their responsibility is not to any one application or project,
but to the whole GNU system. For that reason as well, a
conservative approach can be justified.
<h2>Don't the XEmacs Developers Care?</h2>
<p>Of course we do. But even if we haven't consulted a
lawyer, we have the right to judge the risks to our own
product. Most of us consider it low. Furthermore, many
XEmacs developers take a different approach to the free
software movement itself, and so will differ from GNU/FSF
policy. The code <em>we</em> write will remain free. What we
are possibly losing is the ability to <em>force others</em> to
make their modifications free. This is central to the GNU
Project because it is a social movement. To many developers
as individuals, it is not so crucial.
<p>This also shows why the "Viewpoints" are so different in
style. XEmacs developers consider their project from a
technical point of view, and prefer it for technical reasons.
They see their contributions to the free software movement as
stemming from their development and publication of code.
Stallman, and the FSF, consider their primary role to be more
politically and socially oriented. Thus social and legal
issues come to the fore.
<h2>Fear of Forking Considered Harmful</h2>
<p>Many XEmacs developers do not consider having multiple
implementations of some features a bad thing. The original
Lucid fork arose, as Stallman writes, because the Lucid
developers (primarily Jamie Zawinski) would not "cooperate" in
merging the Lucid code into the GNU mainline. What Stallman
does not mention is that in his vision of "cooperation" the
Lucid developers would be working under <em>his</em> direction
to merge those features that <em>he</em> wanted, making
changes to <em>their</em> code as <em>he</em> directed. This
is obvious, when you think about it; of course Stallman was
the head of the GNU Emacs project, and would reserve the right
to make final decisions. Nor is it surprising that the Lucid
developers refused. They had egos, of course.
<p>But there were also those "irreconcilable technical
differences." Both Lucid Emacs and GNU Emacs 19 were excellent
editors, but in their different ways. The Lucid developers
honestly considered GNU Emacs 19, and the merge as outlined by
Stallman, to be broken in some important ways. He, just as
honestly, considered many of the changes the Lucid developers
demanded to be broken, or at best to be fixing what wasn't
broken. A fork was inevitable. That's what free software is
for, among other things: the right to fix what's broken, and
redistribute the improvements.
<p>And a little competition may be good for you! Without the
fork, GNU Emacs 20 <em>might</em> not have added Mule, and GNU
Emacs 21 might <em>not</em> have the GUI redisplay. Who knows
when GNU Emacs will get a library packaging system? All of
these features were successfully pioneered by Lucid Emacs or
XEmacs, at times when Stallman considered them broken,
irrelevant, or low priority. Conversely, not only is XEmacs
based on GNU Emacs; part of the development effort includes
regular synchronization of features and implementations with
the mainline versions.
<p>Of course, we all think it is best when all the good code
that results can be shared:
<blockquote>
All Emacs developers are free software developers.
</blockquote>
<p>But whether or not it <em>can</em> be shared is a matter of
point of view. On a question quite extraneous to the
development process itself: how much the legal system hinders
you from effectively protecting your copyright when you
cooperate with someone unwilling to give up their copyright.
<!-- #### This next probably should go or be cut way down.
Just taking out my frustrations! -->
<h2>Author's Disclaimer</h2>
<p>I disagree strongly with the Stallman/FSF position in many
respects. However, I have tried to present the facts of the
legal issue as objectively as possible, and have some hope I
succeeded. The interpretation of why XEmacs developers as a
group do not worry about this legal issue is my own; the most
I can say is nobody on the developer's mailing list has
complained about it.
<p>Statements about what Richard Stallman believes, judges,
concludes, and so on should be taken with a grain of salt.
Nobody in their right mind, except Stallman, would pretend to
speak for him. I have found certain conjectures useful for
establishing a coherent interpretation of his actions and
statements, and have taken the liberty of making them
available to you. (Go read the NO WARRANTY section of the
GPL!)
<!-- #### This definitely will go. But isn't "pusillanious"
a wonderful word? -->
<p>Ben Wing probably thinks this is pusillanimous. I don't
care. There are plenty of venues where you can read endless
flames on these issues; with a little effort, you can probably
find some of mine. (I wouldn't bother.)
<address>
Stephen J. Turnbull &lt;stephen(a)xemacs.org&gt;
</address>
--
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091
_________________ _________________ _________________ _________________
What are those straight lines for? "XEmacs rules."
7:56 a.m.
hello there.
awhile ago the faq had a link to something i wrote going into this in more
detail. steve removed it without consulting me, probably because he considered
it incendiary and was trying to cooperate with rms on merging [futilely, of
course]. thus he deleted all advocacy on our side; thus the "pusillanimous"
commentary from jamie. some time more recently, i rewrote my opinion piece;
here it is. obviously i am not objective, but i think it's important to have an
"our side" piece to match rms's "their side" piece that we
include.
---------------------------------------------------------------------------------------
Many people look at the split between GNU Emacs and XEmacs and are convinced
that the XEmacs team is being needlessly divisive and just needs to cooperate a
bit with RMS, and the two versions of Emacs will merge. In fact there have been
six to seven major attempts at merging, each running hundreds of messages long
and all of them coming from the XEmacs side. All have failed because they have
eventually come to the same conclusion, which is that RMS has no real interest
in cooperation at all. If you work with him, you have to do it his way -- "my
way or the highway". Specifically:
1. RMS insists on having legal papers signed for every bit of code that goes
into GNU Emacs. RMS's lawyers have told him that every contribution over ten
lines long requires legal papers. These papers cannot be filled out over to the
web but must be done so in person and mailed to the FSF. Obviously this by
itself has a tendency to inhibit contributions because of the hassle factor.
Furthermore, many people (and especially organizations) are either hesitant to
or refuse to sign legal papers, for reasons mentioned below. Because of these
reasons, XEmacs has never enforced legal signed papers for the code in it. Such
papers are not a part of the GPL and are not required by any projects other than
those of the FSF (for example. Linux does not require such papers). Since we do
not know exactly who is the author of every bit of code that has been
contributed to XEmacs in the last nine years, we would essentially have to
rewrite large sections of the code. The situation however, is worse than that
because many of the large copyright holders of XEmacs (for example Sun
Microsystems) refuse to sign legal papers. Although they have not stated their
reasons, there are quite a number of reasons not to sign legal papers:
1. By doing so you essentially give up all control over your code. You can no
longer release your code under a different license. If you want to use your code
that you've contributed to the FSF in a project of your own, and that project is
not released under the GPL, you are not allowed to do this. Obviously, large
companies tend to want to reuse their code in many different projects and as a
result feel very uncomfortable about signing legal papers.
2. One of the dangers of assigning copyright to the FSF is that if the FSF
happens to be taken over by some evil corporate identity or anyone with
different ideas than RMS, they will own all copyright-assigned code, and can
revoke the GPL and enforce any license they please. If the code has many
different copyright holders, this is much less likely of a scenario.
2. RMS does not like abstract data structures. Abstract data structures are the
foundation of XEmacs and all other modern programming projects. It is difficult
to impossible to write maintainable and expandable code without using abstract
data structures. In merging talks with RMS he has said we can have any abstract
data structures we want in a merged version but must allow direct access to the
implementation as well, which defeats the primary purpose of having abstract
data structures.
3. RMS is very unwilling to compromise when it comes to divergents
implementations of the same functionality which is very common between XEmacs
and GNU Emacs. Rather than taking the better interface on technical grounds, RMS
insists that both interfaces must be implemented in C at the same level (rather
than implementing one in C and the other on top if it), so that code that uses
either interface is just as fast. This means that the resulting merged Emacs
would be filled with a lot of very complicated code to simultaneously support
two divergent interfaces, and would be difficult to maintain in this state.
4. RMS's idea of compromise and cooperation is almost purely political rather
than technical. The XEmacs maintainers would like to have issues resolved by
examining them technically and deciding what makes the most sense from a
technical prospective. RMS however, wants to proceed on a tit for tat kind of
basis, which is to say, "If we support this feature of yours, we also get to
support this other feature of mine." The results of such a process is typically
a big mess, because there is no overarching design but instead a great deal of
incompatible things hodgepodged together.
If only some of the above differences were firmly held by RMS, and if he were
willing to compromise effectively on the others and to demonstrate willingness
to work with us on the issues that he is less willing to compromise on, we might
go ahead with the merge despite misgivings. However RMS has shown no real
interest at all in compromising. He has never stated how all of the redundant
work that would be required to support his preconditions would get done. It's
unlikely that he would do it all and it's certainly not clear that the XEmacs
project would be willing to do it all, given that it is a tremendous amount of
extra work and the XEmacs project is already scrapped for coding resources. (Not
to mention the inherent difficulty in convincing people to redo existing work
for primarily political reasons.) In general the free software community is
quite strapped as a whole for coding resources; duplicative efforts amount to
very little positively and have a lot of negative effects in that they take away
what few resources we do have from projects that would actually be useful.
RMS however, does not seem to be bothered by this. He is more interested in
sticking firm to his principles, though the heavens may fall down, than in
working forward to create genuinely useful software. It is abundantly clear that
RMS has no real interest in unity except if it happens to be on his own terms
and allows him ultimate control over the result. He would rather see nothing
happen at all than something that is not exactly according to his principles.
The fact that few, of any, if any people share his principles is meaningless to
him.
"Stephen J. Turnbull" wrote:
We've had a bunch of queries about "XEmacs vs. GNU Emacs" in the last
couple of months. It's time someone dusted off that page; here's my
hack at it. A reader's guide:
(0) Appointed myself author. I think that's appropriate since I don't
see how there can be a consensus on writing this page correctly.
I volunteer to be maintainer for it even if you can't stand the
way I write and insist that it be ghosted. :-)
(1) I substituted "Stallman" for "RMS" throughout. I'm more
comfortable with that, but would immediately revert if most people
preferred the initials.
Ditto "GNU Emacs" for "FSF" or "FSF Emacs". This one I
feel
stronger about. RMS really gets his back up about it.
(2) Substantial but very tentative reorganization of "The XEmacs Point
of View" according to functional lines. Some updates to recent
versions of XEmacs and FSFmacs. Questions I know I need answers
to marked "####" in HTML comments. I'm sure I slipped on some
other stuff.
(3) Added a "Community Participation" section to "The XEmacs Point
of View". Comments appreciated.
(4) Added a pretty turgid description of the "legal problem" as RMS
perceives it. It's a turgid topic.
(5) Added a bunch of sections describing some philosophical
differences (starting with "What Is the Role of the FSF?").
Seemed good when I wrote it, but the whole topic is flamebait.
Comments requested.
(6) Author's disclaimer. Seems required in context, but what to say?
here it comes, in .content format:
%title%
XEmacs vs. GNU Emacs
%author%
Stephen Turnbull &lt;stephen(a)xemacs.org&gt;
%main%
<h1>XEmacs vs. GNU Emacs</h1>
<p>There are currently irreconcilable differences in the views
about technical, programming, design and organizational
matters between Richard Stallman and the XEmacs development
team which provide little hope for a merge to take place in
the short-term future.
<p>If you have a comment to add regarding the merge, it is a
good idea to avoid posting to the newsgroups, because of the
very heated flamewars that often result. Mail your questions
to
<a
href="mailto:xemacs-beta＠xemacs.org">xemacs-beta＠xemacs.org</a>
and
<a
href="mailto:bug-gnu-emacs＠prep.ai.mit.edu">bug-gnu-emacs＠prep.ai.mit.edu</a>.
<p>Many people have noticed the great difference in focus
between the two "Viewpoints" presented here, and also have
expressed confusion about the legal issues Stallman focuses
on. The final sections present some explanation and
interpretation regarding these FAQs.
<h2>Difference between XEmacs and GNU Emacs, from the XEmacs Point of
View</h2>
<p>This section is now quite dated. Much of it refers to GNU
Emacs 19 and XEmacs 20. However, the differences described
persist in the most recent versions of both Emacsen in some
form.
<h3>User-Visible Editing Features</h3>
<p>In XEmacs, images of arbitrary size can be embedded in a
buffer. (Soon available in GNU Emacs 21.)
<p>In XEmacs, variable width fonts work. (Soon available in
GNU Emacs 21.)
<p>The height of a line is the height of the tallest font on
that line, instead of all lines having the same height. (Soon
available in in GNU Emacs 21.)
<!-- #### Is this obsolete? -->
<p>XEmacs provides support for ToolTalk on systems that have
it.
<!-- #### Probably I should drop mention of DnD and xemacs-gtk? -->
Experimental support for drag-and-drop protocols is
provided from XEmacs 21.
<p>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.
<p>XEmacs has a built-in toolbar. Four toolbars can actually
be configured: top, bottom, left, and right toolbars.
<p>XEmacs has vertical and horizontal scrollbars. Unlike in
GNU Emacs 19 (which provides a primitive form of vertical
scrollbar), these are true toolkit scrollbars. A look-alike
Motif scrollbar is provided for those who don't have
Motif. (Even for those who do, the look-alike may be
preferable as it is faster.)
<h3>General Platform Support</h3>
<p>If you're running on a machine with audio hardware, you can
specify sound files for XEmacs to play instead of the default
X beep. See the documentation of the function load-sound-file
and the variable sound-alist. XEmacs also supports the
network sound protocols NAS and EsounD.
<p>XEmacs 21 supports database protocols with LISP bindings,
currently including LDAP and PostgreSQL (21.2 only).
<p>XEmacs 20 and 21 support the Canna, Wnn, and SJ3 Japanese
input method servers directly, as well as through the X Input
Method (XIM) protocol. GNU Emacs 20 supports only the XIM
protocol. Both Emacsen support the Quail family of input
methods (implemented in LISP) for many languages.
<h3>LISP Programming</h3>
<p>From XEmacs 20 on, characters are first-class objects.
Characters can be converted to integers, but are not integers.
GNU Emacs 19, XEmacs 19, Mule 2.3 (an extensive patch to GNU
Emacs 18.55 and 19.x), and GNU Emacs 20 (incorporating Mule 3
and later Mule 4) represent them as integers.
<p>From XEmacs 20 on, the buffer is treated as an array of
characters, and the representation of buffer text is not
exposed to LISP. The GNU Emacs 20 functions like
buffer-as-multibyte are not supported.
<p>In XEmacs, events are first-class objects. GNU Emacs 19
represents them as integers, which obscures the differences
between a key gesture and the ancient ASCII code used to
represent a particular overlapping subset of them.
<p>In XEmacs, keymaps are first-class opaque objects. GNU Emacs 19
represents them as complicated combinations of association
lists and vectors. If you use the advertised functional
interface to manipulation of keymaps, the same code will work
in XEmacs, GNU Emacs 18, and GNU Emacs 19; if your code depends on
the underlying implementation of keymaps, it will not.
<p>XEmacs uses "extents" to represent all non-textual aspects
of buffers; GNU Emacs 19 uses two distinct objects, "text
properties" and "overlays", which divide up the functionality
between them. Extents are a superset of the functionality of
the two GNU Emacs data types. The full GNU Emacs 19 interface
to text properties and overlays is supported in XEmacs (with
extents being the underlying representation).
<p>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
GNU Emacs 19 text properties always have this behavior and
overlays never do.
<h3>Packaged LISP Libraries</h3>
<p>Many more packages are provided standard with XEmacs than
with GNU Emacs 19 or 20.
<p>XEmacs 21 supports an integrated package management system
which uses EFS to download, then automatically install
prebuilt LISP libraries.
<h3>Window System Programming Interface</h3>
<p>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.
<p>XEmacs supports Motif applications, generic Xt
(e.g. Athena) applications, and raw Xlib applications. An
XEmacs variant which supports GTK+ is available (but not yet
integrated to the main CVS branch), although code to take
advantage of the support is as yet scarce.
<p>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.
<!-- #### This is new! -->
<h3>Community Participation</h3>
<p>Starting with XEmacs 20, joining the XEmacs development
team is simple. Mail to <a
href="mailto:xemacs-beta＠xemacs.org">XEmacs Developers
&lt;xemacs-beta(a)xemacs.org&gt;</a>, and you're in! (If you
<em>want</em> to be, of course. You're also welcome to just
post development-related questions and bug reports.) The GNU
Emacs development team and internal mailing lists are still by
invitation only.
<p>The "bleeding edge" of mainline XEmacs development is
available by <a href="http://cvs.xemacs.org">anonymous
CVS</a>
as are some subsidiary branches (check out the xemacs-gtk
module for the latest in GUI features!)
<p>CVS commit authority is broadly dispersed. Recognized
maintainers of LISP libraries who are willing to maintain
XEmacs packaged versions automatically qualify for CVS
accounts for their packages.
<h2>The FSF Point of View</h2>
<p><a href="mailto:rms＠gnu.org">Richard Stallman</a>
writes:</p>
<blockquote>
<p>XEmacs is GNU software because it's a modified version of a
GNU program. And it is GNU software because the FSF is the
copyright holder for most of it, and therefore the legal
responsibility for protecting its free status falls on us
whether we want it or not. This is why the term "GNU XEmacs"
is legitimate.
<p>But in another sense it is not GNU software, because we
can't use XEmacs in the GNU system: using it would mean paying
a price in terms of our ability to enforce the GPL. Some of
the people who have worked on XEmacs have not provided, and
have not asked other contributors to provide, the legal papers
to help us enforce the GPL. I have managed to get legal
papers for some parts myself, but most of the XEmacs
developers have not helped me get them.
<p>XEmacs was possible because free software means that anyone
can change it and distribute a modified version. I have no
regrets about establishing this freedom for Emacs. Everyone
should have the freedom to change any program, and this is not
limited to changes that the original author likes.
<p>Many people have taken advantage of the freedom to change
GNU Emacs, over the last decade. Most of them were willing to
cooperate on integrating their changes into Emacs. XEmacs
arose as a separate forked version because some of the
developers--starting with Zawinski--were unwilling to do that.
<p>People should have the freedom to decide what to work on,
including the freedom to compete with the GNU project, but
it's a shame when they make that choice. The whole community
loses when someone chooses competition rather than
cooperation.
<p>But this is worse than competition--it is unfair
competition. The XEmacs developers can and do copy code they
like from Emacs. If I could copy the code I like from XEmacs
in the same way, at least the rivalry would be fair. But I
can't do that't, because substantial parts of XEmacs don't
have legal papers, or don't have known authors.
<p>As long as we cannot use XEmacs in the GNU system, the GNU
project has to make sure that Emacs is not left behind. In
other words, we have to behave like rivals too, even though we
wish there were no rivalry. When XEmacs developers try to
persuade people to use, test, fix and enhance XEmacs instead
of Emacs, the GNU project can't sit still; we need them to
use, test, fix and enhance Emacs instead.
<p>There is good code in XEmacs, which I'd be happy to have in
a merged Emacs any day. But I cannot copy it out of XEmacs
myself because of the uncertain authorship and/or lack of
legal papers.
<p>This problem could probably be resolved, at least for large
parts of XEmacs, with substantial help from the authors of
that code. Otherwise, the GNU project has to write or find
replacements for it.
<p>I invite people who like Emacs, and want the best possible
version of Emacs to be available for use in the GNU system, to
help in one way or the other.
</blockquote>
<!-- #### This really isn't source for the RMS quote. Obsolete?
Does anyone know where that came from? If not, this can go.
<p><strong>Sources:</strong> <a
href="http://www.xemacs.org/FAQ/">FAQ</a>
item 1.0.5, and XEmacs 21.0 NEWS file
-->
<h2>What Is the Legal Issue?</h2>
<p>There is no difference in the nature of the copyrights or
licenses of the two projects. Copyright is defined by law and
international treaty, and is automatically awarded to the
author as soon as a work is published. Both projects use the
GNU General Public License to protect their work while
providing it freely to the community.
<p>XEmacs has no choice, because much of its code is
copyrighted by the Free Software Foundation, and is only
available to XEmacs under the GPL. Under that license,
redistribution is only possible under the GPL. The GNU
Project uses the GPL as a matter of principle. (XEmacs
developers generally subscribe to a similar principle, of
course.) It is the same GPL, so sharing code is 100% legal.
<p>However, copyright is governed by the <em>civil</em> code,
not the criminal code. This means that the government takes
no interest in violations of copyright as such. It only
undertakes to provide law courts where the copyright can be
enforced. It is the responsibility of the copyright holder to
sue to prevent violations and receive damages for past
violations. The government <em>cannot</em> act on the
complaints of third parties.
<p>The FSF has received legal advice that a copyright holder
in a jointly-authored work is in a weak position to enforce
its copyright unless all coauthors participate in the legal
action. Evidently the FSF would be considered a third party
with respect to non-assigned code, weakening its ability to
defend the whole work. (Author's note: You'd have to ask a
lawyer why that might be so. I am not an expert, so I will
just assure you that some lawyers I have asked informally
agree that this theory is plausible, although it has not been
tested in court. It may also be more or less applicable in
jurisdictions other than the U.S.)
<p>Based on this advice, Stallman has concluded that
incorporating <em>some</em> code copyrighted by another entity
into a work such as Emacs puts the copyright of <em>all</em>
of the work at risk of being unenforceable in court in the
case of a violation. He has judged that this risk is
unacceptably large, and therefore insists that the whole
copyright of any software the FSF undertakes to defend be
assigned to the FSF, with few exceptions.
<h3>What Is the Role of the FSF?</h3>
<p>Stallman believes that copyright in software itself is
immoral; Copyleft is a device to undermine the whole idea. He
has little empathy for people who wish to retain
copyright---after all, he has given up his own. This is the
fundamental idea behind the FSF (as opposed to the GNU
Project, which actually develops software): a holding company
for all the software copyrights that shouldn't even exist in
the first place. According to the legal argument above, such
a trust is necessary to defend the GPL, which is what prevents
proprietary firms from misappropriating the software at the
same time as it prevents the holding company (the FSF) from
being a monopoly.
<h2>Well, Isn't That Paranoid?</h2>
<p>Many developers think so, but it seems that noone who holds
a different theory has retained a lawyer to check the
precedents. The FSF has done so, so its position must be
considered most credible.
<p>Also, it is important to remember that Stallman and the FSF
are not (in this context) acting as software developers. Rather,
they perceive themselves as guardians of a social movement.
Their responsibility is not to any one application or project,
but to the whole GNU system. For that reason as well, a
conservative approach can be justified.
<h2>Don't the XEmacs Developers Care?</h2>
<p>Of course we do. But even if we haven't consulted a
lawyer, we have the right to judge the risks to our own
product. Most of us consider it low. Furthermore, many
XEmacs developers take a different approach to the free
software movement itself, and so will differ from GNU/FSF
policy. The code <em>we</em> write will remain free. What we
are possibly losing is the ability to <em>force others</em> to
make their modifications free. This is central to the GNU
Project because it is a social movement. To many developers
as individuals, it is not so crucial.
<p>This also shows why the "Viewpoints" are so different in
style. XEmacs developers consider their project from a
technical point of view, and prefer it for technical reasons.
They see their contributions to the free software movement as
stemming from their development and publication of code.
Stallman, and the FSF, consider their primary role to be more
politically and socially oriented. Thus social and legal
issues come to the fore.
<h2>Fear of Forking Considered Harmful</h2>
<p>Many XEmacs developers do not consider having multiple
implementations of some features a bad thing. The original
Lucid fork arose, as Stallman writes, because the Lucid
developers (primarily Jamie Zawinski) would not "cooperate" in
merging the Lucid code into the GNU mainline. What Stallman
does not mention is that in his vision of "cooperation" the
Lucid developers would be working under <em>his</em> direction
to merge those features that <em>he</em> wanted, making
changes to <em>their</em> code as <em>he</em> directed.
This
is obvious, when you think about it; of course Stallman was
the head of the GNU Emacs project, and would reserve the right
to make final decisions. Nor is it surprising that the Lucid
developers refused. They had egos, of course.
<p>But there were also those "irreconcilable technical
differences." Both Lucid Emacs and GNU Emacs 19 were excellent
editors, but in their different ways. The Lucid developers
honestly considered GNU Emacs 19, and the merge as outlined by
Stallman, to be broken in some important ways. He, just as
honestly, considered many of the changes the Lucid developers
demanded to be broken, or at best to be fixing what wasn't
broken. A fork was inevitable. That's what free software is
for, among other things: the right to fix what's broken, and
redistribute the improvements.
<p>And a little competition may be good for you! Without the
fork, GNU Emacs 20 <em>might</em> not have added Mule, and GNU
Emacs 21 might <em>not</em> have the GUI redisplay. Who knows
when GNU Emacs will get a library packaging system? All of
these features were successfully pioneered by Lucid Emacs or
XEmacs, at times when Stallman considered them broken,
irrelevant, or low priority. Conversely, not only is XEmacs
based on GNU Emacs; part of the development effort includes
regular synchronization of features and implementations with
the mainline versions.
<p>Of course, we all think it is best when all the good code
that results can be shared:
<blockquote>
All Emacs developers are free software developers.
</blockquote>
<p>But whether or not it <em>can</em> be shared is a matter of
point of view. On a question quite extraneous to the
development process itself: how much the legal system hinders
you from effectively protecting your copyright when you
cooperate with someone unwilling to give up their copyright.
<!-- #### This next probably should go or be cut way down.
Just taking out my frustrations! -->
<h2>Author's Disclaimer</h2>
<p>I disagree strongly with the Stallman/FSF position in many
respects. However, I have tried to present the facts of the
legal issue as objectively as possible, and have some hope I
succeeded. The interpretation of why XEmacs developers as a
group do not worry about this legal issue is my own; the most
I can say is nobody on the developer's mailing list has
complained about it.
<p>Statements about what Richard Stallman believes, judges,
concludes, and so on should be taken with a grain of salt.
Nobody in their right mind, except Stallman, would pretend to
speak for him. I have found certain conjectures useful for
establishing a coherent interpretation of his actions and
statements, and have taken the liberty of making them
available to you. (Go read the NO WARRANTY section of the
GPL!)
<!-- #### This definitely will go. But isn't "pusillanious"
a wonderful word? -->
<p>Ben Wing probably thinks this is pusillanimous. I don't
care. There are plenty of venues where you can read endless
flames on these issues; with a little effort, you can probably
find some of mine. (I wouldn't bother.)
<address>
Stephen J. Turnbull &lt;stephen(a)xemacs.org&gt;
</address>
--
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091
_________________ _________________ _________________ _________________
What are those straight lines for? "XEmacs rules."
--
ben
I'm sometimes slow in getting around to reading my mail, so if you
want to reach me faster, call 520-661-6661.
See http://www.666.com/ben/chronic-pain/ for the hell I've been
through.
8:26 a.m.
>>>> "Ben" == Ben Wing <ben(a)666.com>
writes:
Ben> hello there.
Ben> awhile ago the faq had a link to something i wrote going into this in more
Ben> detail. steve removed it without consulting me, probably because he considered
Ben> it incendiary and was trying to cooperate with rms on merging [futilely, of
Ben> course]. thus he deleted all advocacy on our side; thus the
"pusillanimous"
Ben> commentary from jamie. some time more recently, i rewrote my opinion piece;
Ben> here it is. obviously i am not objective, but i think it's important to have
an
Ben> "our side" piece to match rms's "their side" piece that we
include.
I agree that members of the xemacs community should have a place to
put their opinion. Our group is too diverse to have an "Our Side",
however. So I suggest we have an "Opinion" web page, with opinions
clearly identified by author. Consider this a place to put a
"personal" web page for XEmacs developers, as long as the content is
clearly xemacs-related.
I have some opinions lurking in my brain that I would like to write
about, if only I ever got around to it....
Martin
8:53 a.m.
>>>> "Ben" == Ben Wing <ben(a)666.com>
writes:
Ben> some time more recently, i rewrote my opinion piece; here it
Ben> is.
Thanks!
Sorry about the misattribution of "pusillanimous."
Ben> obviously i am not objective, but i think it's important to
Ben> have an "our side" piece to match rms's "their side"
piece
Ben> that we include.
I see your point. Personally, I'd like to bend over backward to give
RMS's response prominence. That looks "objective".
I like Martin's suggestion. What I would suggest as an implementation
is that I move my discussion under "Fear of Forking Considered
Harmful" to a separate page, and add links that that page, Ben's op
piece, etc, as explicitly personal opinions.
--
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091
_________________ _________________ _________________ _________________
What are those straight lines for? "XEmacs rules."
8:26 a.m.
"Stephen J. Turnbull" wrote:
>>>>> "Ben" == Ben Wing <ben(a)666.com> writes:
Ben> some time more recently, i rewrote my opinion piece; here it
Ben> is.
Thanks!
Sorry about the misattribution of "pusillanimous."
but i completely agree with it. xemacs has ZERO name recognition compared to
emacs outside [and inside, for that matter!] of the miniscule and insulated free
software community.
Ben> obviously i am not objective, but i think it's important to
Ben> have an "our side" piece to match rms's "their side"
piece
Ben> that we include.
I see your point. Personally, I'd like to bend over backward to give
RMS's response prominence. That looks "objective".
xemacs is not objective, obviously. nor is rms. rms will never put rebuttals
of his arguments on his site, and if you make his response most prominent,
you're letting him have the last word once again! face it, xemacs is in its
death throes. what it desperately needs is advocacy, not moral
high-mindedness. no one cares whether you take the moral high road or not if
you die in the process.
I like Martin's suggestion. What I would suggest as an implementation
is that I move my discussion under "Fear of Forking Considered
Harmful" to a separate page, and add links that that page, Ben's op
piece, etc, as explicitly personal opinions.
--
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091
_________________ _________________ _________________ _________________
What are those straight lines for? "XEmacs rules."
--
ben
I'm sometimes slow in getting around to reading my mail, so if you
want to reach me faster, call 520-661-6661.
See http://www.666.com/ben/chronic-pain/ for the hell I've been
through.
9:14 a.m.
>>>> "Ben" == Ben Wing <ben(a)666.com>
writes:
Ben> if you make [RMS's] response most prominent, you're letting
Ben> him have the last word once again!
He'll get it anyway; that's my point. Personally, I've always thought
that just posting that monolith of illogic and bile "as is" was the
nastiest response we could make to it. But I guess I'm just too
subtle....
Ben> face it, xemacs is in its death throes. what it desperately
Ben> needs is advocacy,
And then what? Advocacy won't overcome the inertial effect that the
GNU name has.
Ben> not moral high-mindedness. no one cares whether you take the
Ben> moral high road or not if you die in the process.
Knocking RMS is not the same thing as advocating XEmacs. Rather than
explain why working with RMS is impossible, we should be explaining
why XEmacs makes your life better. Sure, it's worth responding to
him, but what we really need to do is to get it across why XEmacs is
better than FSFmacs.
From the point of view of typical users, I don't know that the
differences are so perceptible. If you must attack something, find
some way to emphasize the advantages of XEmacs over the FSF's version
of Emacs, a la MySQL's "crashme" page.
--
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091
_________________ _________________ _________________ _________________
What are those straight lines for? "XEmacs rules."
9:52 a.m.
Ben Wing <ben(a)666.com> writes:
but i completely agree with it. xemacs has ZERO name recognition
compared to
emacs outside [and inside, for that matter!] of the miniscule and insulated free
software community.
A small note; four out of six core KDE developers mention XEmacs as
their "favorite tool":
http://www.kde.org/people/people.html
(Emacs and joe for the remaining two.)
8794
days inactive
8807
days old
6 comments
4 participants
participants (4)
-
Ben Wing -
Martin Buchholz -
Simon Josefsson -
Stephen J. Turnbull