Source

xemacsweb / About / XEmacsVsGNUemacs.content

Full commit
  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
%title%
XEmacs vs. GNU Emacs
%author%
Stephen Turnbull <stephen@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 (RMS) and the XEmacs development team which provide
    little hope for a merge to take place in the short-term future.
  </p>

  <p>
    If you have a comment regarding a 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>

  <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 RMS focuses on.  The final sections
    present some explanation and interpretation regarding these FAQs.
  </p>

  <h2>
    Technical Differences between XEmacs and GNU Emacs<br />
    (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.
  </p>

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

  <p>
    In XEmacs, variable width fonts work.  (Soon available in GNU
    Emacs 21.)
  </p>

  <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 GNU Emacs 21.)
  </p>

  <p>
    <!-- #### Is this obsolete? -->
    XEmacs provides support for ToolTalk on systems that have it.
    <!-- #### Possibly I should drop mention of DnD? -->
    Experimental support for drag-and-drop protocols is provided from
    XEmacs 21.
  </p>

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

  <p>
    XEmacs has a built-in toolbar.  Four toolbars can actually be
    configured simultaneously: top, bottom, left, and right toolbars.
  </p>

  <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.)
  </p>

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

  <p>
    XEmacs 21 supports database protocols with LISP bindings,
    currently including Berkeley DB, LDAP, and PostgreSQL (21.2 only).
  </p>

  <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.
  </p>

  <h3>Packaged LISP Libraries</h3>

  <p>
    Many more packages are provided standard with XEmacs than with GNU
    Emacs 19 or 20.
  </p>

  <p>
    XEmacs 21 supports an integrated package management system which
    uses EFS to download, then automatically install prebuilt LISP
    libraries.  This allows XEmacs users much more straightforward
    access to the "latest and greatest" version of any given library.
  </p>

  <h3>LISP Programming</h3>

  <p>
    From XEmacs 20 on, characters are a separate type.  Characters can
    be converted to integers (and many integers can be converted to
    characters), but characters are not integers.  GNU Emacs 19,
    XEmacs 19, Mule 2.3 (an extensive patch to GNU Emacs 18.55 and
    19.x), and GNU Emacs 20 (incorporating Mule 3 and later Mule 4)
    represent them as integers.
  </p>

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

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

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

  <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 union of the functionality of the
    two GNU Emacs data types.  The full GNU Emacs 19 interface to text
    properties and overlays is supported in XEmacs (with extents being
    the underlying representation).
  </p>

  <p>
    Extents can be made to be copied into strings, and then restored,
    by kill and yank.  Thus, one can specify this behavior on either
    "extents" or "text properties", whereas in GNU Emacs 19 text
    properties always have this behavior and overlays never do.
  </p>

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

  <p>
    XEmacs supports Motif applications, generic Xt (e.g. Athena)
    applications, and raw Xlib applications.  An XEmacs variant which
    supports GTK+ is available (integration as an option in the XEmacs
    mainline is planned for XEmacs 22), although code to take
    advantage of the support is as yet scarce.
  </p>

  <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.
  </p>

  <!-- #### 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@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
    <em>still</em> by invitation only.
  </p>

  <p>
    The "bleeding edge" of mainline XEmacs development is available by
    <a href="<!-- _GP_ relPath(qq{Develop/cvsaccess.html})
    -->">anonymous CVS</a> as are some subsidiary branches (check out
    the <em>xemacs-gtk</em> module for the latest in GUI features!)
  </p>

  <p>
    Development and maintenance of Lisp libraries is separated from
    the core editor development at a fairly low level.  This provides
    better modularization and a better division of responsibility
    between external library maintainers and the XEmacs core
    development team.  Even for packages the size of Gnus, XEmacs
    users normally have access to a pre-built version within a few
    weeks of a major release, and minor updates often within days.
  </p>

  <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.
  </p>

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

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

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

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

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

    <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, because
      substantial parts of XEmacs don't have legal papers, or don't
      have known authors.
    </p>

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

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

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

    <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.
    </p>

  </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>

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

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

  <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, but 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>

  <p>
    Based on this advice, RMS 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.  Therefore he insists
    that the whole copyright of any software that included in the GNU
    system be assigned to the FSF, with few exceptions.
  </p>

  <h3>What Is the Role of the FSF?</h3>

  <p>
    RMS 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).
    It is 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. It is
    the GPL that prevents proprietary firms from misappropriating the
    software at the same time as it prevents the holding company (the
    FSF) from being a monopoly.
  </p>

  <h2>Well, Isn't That Paranoid?</h2>

  <p>
    Many developers think so, but it seems that no one 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>

  <p>
    Also, it is important to remember that RMS 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.
  </p>

  <h3>Don't the XEmacs Developers Care?</h3>

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

  <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.  Richard Stallman, and the FSF,
    consider their primary role to be more politically and socially
    oriented.  Thus social and legal issues come to the fore.
  </p>

  <h2>Fear of Forking Considered Harmful</h2>

  <p>
    Few XEmacs developers consider having multiple implementations of
    some features a bad thing.  The original Lucid fork arose, as RMS
    writes, because the Lucid developers (primarily Jamie Zawinski)
    would not "cooperate" in merging the Lucid code into the GNU
    mainline.  What RMS 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 he
    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.  But ... well, you
    can, and should, <a href="http://www.jwz.org/doc/lemacs.html"
      shape="rect">judge for yourself</a>.
  </p>

  <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 RMS, 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 one
    thing free software is for: the right to fix what <em>you</em>
    consider broken, and redistribute the improvements.
  </p>

  <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.  They were
    implemented at times when RMS considered them broken, irrelevant,
    or low priority.  Conversely, not only is XEmacs based on GNU
    Emacs, but part of the development effort includes regular
    synchronization of features and implementations with the mainline
    versions.
  </p>

  <p>
    Of course, we all think it is best when all the good code that
    results can be shared:
  </p>

  <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.  And the question is quite extraneous to the development
    process itself.  "How much does the legal system hinder you in
    effectively protecting your copyright when you cooperate with
    someone unwilling to give up their copyright?"  Maybe you don't
    need to care.
  </p>

  <h3>Author's Disclaimer</h3>

  <p>
    I disagree strongly with the FSF position in many respects.
    However, I have tried to present the facts of the legal issue as
    accurately and 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 XEmacs developer's mailing list has complained
    about it.
  </p>

  <p>
    Statements about what Richard Stallman believes, judges,
    concludes, and so on should be taken with a grain of salt.  I am
    not so foolish as to pretend to speak for him.  Rather, 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.  The NO WARRANTY section
    of the GPL definitely applies to them, though!
  </p>

  <p>
    I just wanna say that I am proud that this page <em>still</em> gives
    <a href="http://www.jwz.org/" shape="rect">Jamie Zawinski</a> an
    excuse to use a <em>wonderful</em> word like
    <a href="http://www.jwz.org/doc/lemacs.html" shape="rect">pusillanimous.</a>
    There are plenty of venues where you can read endless flames on
    these issues.  With little effort, you can probably find some of
    mine.  This isn't one.  So big deal.
  </p>

  <p>
    Oh, yeah.  I'm sorry I get so wrapped up in the politics.  I'll
    try to spend more time on the technical details in the next
    round.  Maybe even find out what's happened in Emacs 20 and 21!
  </p>

  <address>
    Stephen J. Turnbull &lt;stephen@xemacs.org&gt;
  </address>

  <!-- Keep this comment at the end of the file
  Local variables:
  mode: xml
  sgml-omittag:nil
  sgml-shorttag:nil
  sgml-namecase-general:nil
  sgml-general-insert-case:lower
  sgml-minimize-attributes:nil
  sgml-always-quote-attributes:t
  sgml-indent-step:2
  sgml-indent-data:t
  sgml-parent-document:("../template.html" "html" "body" "table" "tr" "td")
  sgml-exposed-tags:nil
  sgml-local-catalogs:nil
  sgml-local-ecat-files:nil
  End:
  -->