等等，你的意思是要重写个编辑器？那为啥选择Lisp啊，别的语言有更好的周边库支持的吧，比如图形界面什么的，开发可能更方便。
这是你的个人爱好开发计划？计划上github么？
差不多吧。Common Lisp 有 FFI，各种图形库绑定也都有现成的。
每个部件成熟后会以独立项目公开的
不从底层重构优化一波加入一些现代化特性，搞这些干啥。
论office，文献用pdf，文档有ms office，哪里轮得到emacs。
When I was working at the AI Lab, one of the older programmers told me that hackers are often eager to make improvements of this sort: which make the program better in an abstract sense, but not better for users. I took that advice to heart. Now I pass it on.
前人的智慧
正是因為你們每天想著"底层重构优化一波加入一些现代化特性"，才会覚得"论office，文献用pdf，文档有ms office，哪里轮得到emacs。"
Office 用戶会考慮"底层重构优化一波"嗎？
当然不会，重不重构那是微软的事儿，问题是微软的office一直在演进，底层架构也一直在调整，不然你以为怎么做到17年的软件还能兼容93年的格式？
emacs咋样？是啊，有新功能。那新功能好用不？好用个蛋蛋。好不容易搞出个多线程还是残疾版的。以各种历史原因平台原因为借口不改进，干啥呀，x86平台干嘛收到powerpc的限制而不能享受更优秀的特性？
瞅瞅隔壁vim，之前也是牛逼哄哄的说“老子就是不改，就是好用”，结果neovim一出怂了，该改的改，该加的加，社区活跃度再次上升，各领风骚。搞得我都感觉啥时候应该有个neoemacs啊，也引入一些新鲜血液。
你也别吐槽底层重构，咱们都是平时写代码的，都知道数万行的代码加几个功能都可能导致架构完全乱掉，更别说像emacs这种庞大的代码量了。不经过仔细推敲重构，哪里经得起加入新特性这么折腾？
以上言论偏激不？偏激！为啥偏激？用的不爽啊！要是社区里面清一色的说emacs如何如何好，那不就变成宗教了么。也让我这种普通用户发发声，吐个槽
2 个赞
用户需求。兼容个格式有个啥难度能让你吹的，兼容个平台就被难看了？不讲道理啊
本来我和你想的一样。
后来……
底层代码从来不是问题，guile emacs 那时候就靠一次 google code summer 的时间把 guile emacs 从 20 bump 到 24。
那么，问题来了，除了说在一匹马牵到面前以后说“我要一匹更快的马”以外，你能提出什么 Emacs 没有，别的编辑器也没有的新特性呢？
哈哈，这个真的是。neovim 一出来，多年不挪窝的 vim 版本号迅速飙到了 8.0，加了一堆新特性。
Emacs 的问题之一，我觉得是把事情搞复杂化了。比如我的 .vimrc/init.vim 配置才 20 几个插件，并没觉得少了什么缺不得的重要功能。而反观流行的 spacemacs 配置，插件将近 300 个，这个已经完全不是我能 handle 得了的。重要的是 bug 多多…
不如简单点，再简单点。
2 个赞
是的。但我认为这是 Unix 的原罪間接导致的。
在比较差的机器上，我真觉得emacs比vim卡
当年XEmacs也倒逼GNU Emacs加入了好多特性，尤其是GUI方面的。可惜XEmacs黄了很久了。
邮件列表和官网还有人，就是不更新了
已经沦为编辑器了
底层代码从来不是问题，guile emacs 那时候就靠一次 google code summer 的时间把 guile emacs 从 20 bump 到 24。
咱不是在说emacs的事儿嘛，怎么和guile emacs搞上关系啦，这俩哥们的底层实现应该完全不一样吧。光运行lisp速度比emacs快我就觉得很有前途，就想不通怎么黄了。。。
那么，问题来了，除了说在一匹马牵到面前以后说“我要一匹更快的马”以外，你能提出什么 Emacs 没有，别的编辑器也没有的新特性呢？
哎，你这个问法就不对了。咱们在这儿说的都是1和100的问题，不是0和1的问题。
emacs的特性多了去了，依赖于神一般的lisp语言（褒义），把emacs说成操作系统的确不为过。BUT，对这里的确有个转折：有没有是一回事儿，做的好不好是另一回事儿。
打个比方说吧，org mode是emacs里面的大杀器，都被直接集成了，这东西大名鼎鼎，易用好用还上瘾，能打100分，正面典型；ecb呢，也被集成，然而体验那叫一个差，能不能打60分都难说，这就是个反面典型。
你说有功夫去取代libreoffice，干嘛不提升一下运行速度，你好我好大家好
是的, 有竞争才能更好地发展, 不一定就是浪费精力
兼容个格式有个啥难度能让你吹的，兼容个平台就被难看了？不讲道理啊
别挑骨头，兼容平台和兼容格式还真不是一个难度等级的。兼容平台无需考虑软件架构，只需要实现compat层的函数即可，而兼容格式需要一直在增加功能的同时保持对原有格式的兼容，这对于软件本身就有重构的要求。要是几个版本不重构，后面越是加功能就越会导致软件结构摇摇欲坠，最后只能重写。
而且，软件本身不是语言，其本身应该提供的是最大能力集，而不是受限于平台提供的通用最小能力集，也就是说如果某个平台无法跑这个功能，裁掉就好了呀，干嘛为了这个平台而不提供这个功能？
你的百分之一 == 别人的百分之百
某些历史原罪不是说改就改的，也不是一些新鲜血液能解决的问题。
另外我最烦的就是所有的兼容性问题……我偏激的希望以后所有的硬件软件都不要考虑什么兼容性，都通通给我只支持最新的……
你的百分之一 == 别人的百分之百
嘿，要是软件用多了你口味也会变高。
你不是在用emacs写C++嘛，如果现在的emacs表现能够让你满意，那你试试vs+vax，那就是惊艳了。如果用的时间长了，惊艳变成了标准，那原先的标准也就变成不及格了。
当然满意程度还是个人标准，就是这么吐一个槽。
2 个赞
Guile Emacs 和 GNU/Emacs 到 24 版时是 90% 兼容的。所以可以证明另起炉灶不是不可能的事。至于为什么提这个，就是证明单纯的换个语言引擎小提升一下性能，乃至换个更优秀的语言并没有实际吸引力。同理还有 Java Emacs，也基本凉了。
Scheme 是否比 Emacs Lisp 更优秀？至少 RMS 是同意的。
因为有人要用这个平台。
对于好不好，每个人标准不一样。比如对我来说 org mode 明显是过度复杂的体现，其臃肿程度远超过标记语言了。我不觉得好用，因为单独做 GTD 有 planner mode，写文档我个人偏好直接用 LaTeX。
Emacs 当初选择用 Lisp，就已经定下了功能大于性能的基调了。打个比方，「政治敏感言论」。所以现在虽然有做性能上的提升，但把这个放第一位，就很有问题了。
你以为所有 Emacs 用户都会觉得 org 是好的，正如你以为所有 Emacs 用户都和你一样用御三家系统，如同你以为所以 Emacs 用户都是写代码的。
要知道不喜欢 org 的 Emacs 用户大有人在，因为支持“小众”平台用 Emacs 的人大有人在，用 Emacs 搞文学的人大有人在。
总是从个人出发，牢骚就只能是牢骚，没法成为建设性的意见。
编译器/解释器也是软件，同时也可以是语言本体。 如果你是指“应用程序”，Emacs 也很难算单纯的应用程序。所以你的命题不成立。
4 个赞
你们的讨论我跟不上，您的这条回复我很赞同，有理有据令人信服 
如果系统支持我会多点几个赞
我就不喜欢 Org，太复杂了。
1 个赞