XEmacs Vs GNU Emacs ——From: www.xemacs.org By:
[email protected]
*******************
*******************
目前，在Richard Stallman(RMS)和XEmacs开发组之间，对于技术、编程、设计和组织等方面问题等开发上存在着如此不可调和的差异，使得那种想在近期将两者合并的希望几乎不可能实现了。
如果你对此有所评论，最好不要将之贴到新闻组中，因为那经常会掀起滔天大浪。将之寄往
[email protected]或
[email protected]是你的明智选择。
很多人已经注意到本文中两种不同“观点”所关注的焦点是截然不同的，并且因此表达了对RMS所关注的合法性问题的不可理解。本文的最后一节就这些疑惑提供了一些解释。
*XEmacs和GNU Emacs在技术上的差异（XEmacs方的观点）
=====================================================
本节中等内容已经有点过时了。大部分的对比都是根据XEmacs 20和GNU Emacs 19作出的。无论如何，在最新版本的Emacs中这些差异仍然以某种形式存在着。
**用户可见的编辑功能
在XEmacs中可以将任意尺寸的图像嵌入到一个缓冲区中。（在GNU Emacs中很快也将会有）
在XEmacs中可以显示变宽的字体。（在GNU Emacs中很快也会有）
一行的行高等于该行中最高字体的高度，而不是所有行都等高。（在GNU Emacs中很快也会实现）
在有ToolTalk的系统上，XEmacs对之提供了支持。从XEmacs 21版本开始将实验性的对拖放协议提供支持。
XEmacs可以使用弹出式对话框来向用户提问题。任何从菜单上执行的命令都会用对话框来提问是或否，而直接由键盘执行的指令将使用命令缓冲区（minibuffer）来完成类似操作。
XEmacs拥有内建的工具条。事实上XEmacs可以在上、下、左、右同时显示4条工具条。
XEmacs有水平和垂直的滚动条。和GNU Emacs 19不同（该版本只提供了一个原始的垂直滚动条），XEmacs提供的是真正的工具包工具条。XEmacs还为那些没有Motif工具包的用户提供了一个类Motif的滚动条。（即使那些有Motif的用户也往往因为速度的原因而更喜欢用类Motif的滚动条）
**总的平台支持
如果你是在一台支持声音的计算机上运行XEmacs，你可以用指定的声音文件来代替缺省的X鸣叫（听起来象是放屁:)——译者注）。详见load-sound-file函数和sound-alist变量的文档。XEmacs也支持网络声音协议NAS和EsounD。
XEmacs 21支持有LISP绑定的数据库协议，目前包括Berkeley DB, LDAP和PostgreSQL（仅限21.2版本）。
XEmacs 20和21直接支持Canna, Wnn和SJ3日文输入法服务器，也可以通过XIM协议支持。而GNU Emacs 20只支持XIM协议。不过两者都支持Quail族的输入法（鹌鹑输入法？？有趣）（在LISP中实现的）。
**包装的LISP库
现在有更多的包是以XEmacs而不是GNU Emacs19／20的标准提供的。
XEmacs 21提供了一个整合的包管理系统，它使用EFS下载，并自动安装内建的LISP库。这使得XEmacs用户能更直接的获取到任何库“最新和最伟大”的版本。
**LISP编程
从XEmacs 20开始，字符成为一个独立的类型。字符可以被转换为整数（反之亦然），但字符不是整数。而GNU Emacs 10, XEmacs19, Mule 2.3（一个GNU Emacs 18.55和19.x的扩展补丁）将两者视为等同。
从XEmacs 20开始，缓冲区被作为一个字符数组，并且不再将缓冲区正文暴露给LISP。GNU Emacs 20的一些函数，比如buffer-as-multibyte将不再被支持。
在XEmacs中，事件是最高级对象。GNU Emacs 19将之表示为整数，这模糊了键组合和某些代表一些特定键组合的古老的ASCII码之间的区别。
在XEmacs中，键图(keymap??)是最高级的不透明(opaque)对象。GNU Emacs 19将它们表示为复杂的列表和向量的组合。如果你使用的是建议的功能接口来操作键图，那你的代码在XEmacs，GNU Emacs 18/19下都可以正确执行；如果你的代码依赖于底层的键图实现方法则不能正确执行。
XEmacs用“度(extents)”来表示缓冲区所有的非文本方面的特性；GNU Emacs 19则使用两个特定对象：“文本属性”和“覆盖(overlay)”，来划分功能。度是这两个GNU Emacs数据类型（即“文本属性”和“覆盖”）的功能集的超集。XEmacs支持完整的GNU Emacs 19的文本属性和覆盖的接口（在此，度是作为底层的表示）。
度可以通过拷贝删除(kill)和粘贴(yank)被拷贝入串，然后还可以将之恢复。用户可以在“度”或“文本属性”上进行这样的动作。然而在GNU Emacs 19中只有文本属性可以而覆盖则不可以。
**窗口系统编程接口
XEmacs使用的是MIT的“Xt”窗口工具包而不是直接调用底层的X调用，这使得XEmacs成为X大家族中一个模范成员（这同时也增强了其可移植性）。因此在XEmacs窗口中可以包括各种Xt部件。而且，XEmacs也能解释标准的Xt命令行。
XEmacs支持Motif应用程序、普通的Xt（比如Athena）程序和直接使用Xlib底层调用的应用程序。目前已经有一个支持GTK+的XEmacs的变种（在XEmacs 22中已经计划将之结合到XEmacs的主线中作为一个选项），尽管利用这种支持的代码还很少。
一个XEmacs框架可以被置放在一个由其它应用程序管理的“外部客户部件”中。这使一个应用程序可以用XEmacs框架来替代其标准的Athena或Motif编辑部件。
**开发社区的参与
从XEmacs 20开始，加入XEmacs的开发团队将会变得十分简单。只要给
[email protected]发一封邮件就可以了（当然你必须在信中表达出你参加开发的意愿，也十分欢迎关于开发的提问或提交臭虫报告）。而对于GNU Emacs，非经邀请你还不能参加其开发团队或内部的邮件列表。
XEmacs开发的一些主版本以及一些次要／分支版本都可以从XEmacs的匿名CVS服务器获得（赶快来检出最新的GUI的xemacs-gtk模块吧！）。
LISP库的开发和维护是和编辑器核心的开发和维护是从低层就分隔开来。这不仅提供了更好的模块性，也使两个开发维护组队之间的责任划分更加明晰。即使对象Gnus这样大的模块，XEmacs的用户也可以在主版本发布的几周内获得一个预建版本，而对于小的升级就只需要几天就可以获得。
CVS提交的权限是十分离散的。那些自愿维护某些包的维护者将可以自动取得可以获得这些包的CVS帐户。
*FSF（自由软件基金会）的观点
================================
Richard Stallman 写道：
XEmacs是一个GNU的软件，这不仅因为它是一个GNU软件（即指emacs）的修改版本，而且是因为FSF拥有它的大部分版权。因此，无论我们愿意与否，保证它自由状态的责任都将落在我们的身上。这就是“GNU XEmacs”这个术语的合法性的缘由。
然而，从另一个意义上说，XEmacs又不是一个GNU软件，因为我们不能在GNU系统中使用XEmacs：一旦使用它将意味着我们将付出某种代价，而这种代价就是必须自己去实施GPL。一些XEmacs的开发者没有提供帮助我们实施GPL的法律文件，而且也没有告诉其它一些参与的人提供。我自己通过努力获得了一些部分的法律文件，然而XEmacs的开发者们却没有给我提供帮助。
自由软件意味着任何人都可以修改并重新发布它，正是基于此XEmacs才有可能产生。我从未后悔过将Emacs变成一个自由软件。任何人都应该有权任意修改任何软件，而且不仅仅是根据原作者的意愿。
在过去10年中，很多人都利用这种自由来修改GNU Emacs。其中的绝大部分都愿意合作将将他们的修改合并到Emacs中去。XEmacs却作为一个分离的分支版本出现，正是因为一些开发者——从Zawinski开始——不愿这样做（指将其合并到GNU Emacs中去）。
人们应该有决定自己活动的自由，包括决定和GNU项目竞争的自由，但人们应该为这样的决定赶到羞愧。选择竞争，而不是合作，对整个社会只能是有损无益。
对于XEmacs来说，情况可能比竞争更糟糕——这是一个不公平的竞争。XEmacs的开发者可以而且的确按他们的意愿任意从Emacs中拷的版权。他觉得这个风险大到了不能接受的程度。因此他坚持GNU系统中绝大部分软件的整体版权必须属于FSF，其中只有极少例外。
**FSF的目的
RMS认为就软件版权本身来说是不道德的。反版权(copyleft)是用来颠覆这整个体系的一个工具。他对那些企图保住版权的人毫不同情——毕竟，他自己就放弃了他应有的版权。这就是FSF的基本思想（和GNU项目形成鲜明对比，GNU项目的目的是开发软件）。FSF就象一个软件的控制(也可能翻译成控股——译者注)公司，保护所有那些本不应有版权的软件。根据上述的合法性讨论，我们有理由为GPL辩护。正是GPL，它不仅保护软件不被那些私有公司侵犯，同时也确保象FSF这样的机构也不至于成为垄断。
*好，这样是不是有点偏执？
============================
很多开发者都这样想，但好像还没有一个人提出另一套理论而且和律师协商过。FSF这样做了，因此它的地位应该是最可靠的。
而且，重要的是要记住RMS和FSF并不是作为一个软件开发者和开发机构的角色。更确切的说，他们将自己作为了一个社会运动的保护者。他们的职责不仅在某一个应用或项目，而且在于整个GNU系统。也因为这个原因，保守的方法将更加合适。
**难道XEmacs的开发者不关心吗？
我们当然关心。但即使我们并没有咨询过律师，我们也有权力来自己判断我们产品的风险。我们中的绝大部分都认为风险不高。而且，许多XEmacs开发者都以不同的方式加入到自由软件运动中，因此这就和GNU/FSF的策略产生了差别。我们的代码将保持自由。我们可能丧失的是迫使其它人将他们对代码的修改保持自由公开的权利。对于GNU项目来说这是一个关键，因为它是一个社会运动。但对很多个体开发者来说则并非如此重要。
这也表明了为什么两个“观点”在风格上会如此不同。XEmacs开发者从技术的观点上考虑他们的项目。因为来源于开发和开放代码，他们将他们的软件视为对自由软件运动的贡献。而Richard Stallman和FSF则更多的从政治和社会角度考虑他们的首要任务。因此社会和法律问题就走到了前面。
*害怕产生分支是有害的
========================
在XEmacs开发者中几乎没有人认为对某些功能上产生几种实现是一件坏事。RMS认为最初的Lucid分支的产生是因为Lucid的开发者们（主要是Jamie Zawinski）不愿意合作把他们的代码合并到GNU主流中。然而RMS没有提到在他的“合作”观点中，Lucid开发者应该在他的领导下合并那些他想要的功能，修改他想要修改的代码。想一想就应该知道这是显而易见的。当然，他是GNU Emacs项目组的头，应该拥有作最后决定的权利。那Lucidn J. Turnbull <
[email protected]>
译者——
[email protected]
整整翻译了五个小时才翻译完，不过不能全怪我，Chinput还是不太好用:) 其中有很多不知如何翻译的，只好按自己的理解了。错漏多多指教。
也许我们大部分人都和本文的原作者持相同的观点——我只想关注技术问题，其它的与我无关。也许你不同意（或不完全同意）他的观点，但你不能不佩服象RMS这样的人。他象苦行僧一样生活，象天才一样工作，象哲人一样思考。没有他，不知还有没有现在的如火如荼的开放源代码活动，微软还会不会改变它封闭的代码政策、、、