因为 vim 有个 vi 兼容模式, 所以很多发行版干脆就把 vim 内置了. 然后就是马太效应.
Emacs 想要提高知名度, 最高效的方式就是某个流行的发行版把 Emacs 设为默认的 editor (但是我不清楚 Emacs 有没有 vi 兼容模式, 还有行编辑功能).
或者发行版将系统的某些脚本用 ELisp 写; 把 Emacs 作为 ELisp 解释器一起打包.
很多码农似乎对 Lisp 有种迷之崇拜, 可以利用这一点. 现在简中互联网上 (比如 B 站, 知乎等) Lisp 的教程并不多, 如果有人能抢先给出 Emacs Lisp 的优秀教程, 那也会提高很多热度.
没有破局，也不需要。
看上面的回复大多认为 Emacs 挺好的，没有局怎么破呢？
这是好事，但动了某些人的蛋糕，所以就受到了攻击。反对主要是基于物质利益的，比如每当此时，m$ 之流就会跳出来说自己的软件如何如何。
类似于资本论讲的：“在政治经济学领域内，自由的科学研究遇到的敌人，不只是它在一切其他领域内遇到的敌人。政治经济学所研究的材料的特殊性，把人们心中最激烈、最卑鄙、最恶劣的感情，把代表私人利益的复仇女神召唤到战场上来反对自由的科学研究。例如，英国高教会宁愿饶恕对它的三十九个信条中的三十八个信条展开的攻击，而不饶恕对它的现金收入的三十九分之一进行的攻击。”
至于其他的反对理由，大多都是对这一动机的遮羞布和自觉或者不自觉的伪装。
无论安全、功能性还是用户友好或别的什么反对理由，它们其实都是 纯粹技术性质 的，而这种纯粹技术的内容，其实是和生产软件的历史的生产关系、以及软件本身扮演的社会角色（被谁控制和拥有）无关的。这意味着：
我们既不能简单判定自由软件就有天生的安全或功能上的优势，也不能认为开发私有软件的人注定就没法写出良好的代码或完成聪明的实现。从纯粹技术的理由（如是否具有 xx 功能）来反对自由软件或者谴责私有软件，都是不靠谱的。就技术能解决的问题而言，双方都不是彼此的不可逾越的上限。在这个问题上，以自由软件基金会为代表的一派的观点是正确的，他们巧妙地避开了自己处于弱势的事实，强调开放源码软件的主要优势在于能为采用它的人提供最大程度的自由和主动性，而不承诺它天生具有某种技术方面的魔法。而自由软件运动中的机会主义的一派相反，拒绝谈论自由，只谈开源，倾向于用纯粹的安全或者效率方面论证开源的必要性，这乍看很聪明很实在，但其实说服力有限，因为：
造成今日自由软件的某些困境的，不在于技术原因，而主要在于社会原因。
软件生产方式和消费模式的变革，改变的主要是“生产资料和产品由谁占有、如何组织生产、为了谁的利益而生产”，而不是“如何用代码实现某个功能的具体方法”。因此，完全没有理由认为用自由软件替换掉私有软件，会带来不便或造成质量下降。更何况，现在已经涌现出来的大量的、在完全不同于资本主义公司的劳动方式中、由社区所创造出来的优秀的自由软件被行业广泛采用的事实，已经从很多方面驳斥了这种观点。
我就是用了 vim 一年多转到 emacs 的, vim 水平不算很好, 但也写过几个插件, 我觉得 vim 定制化的容易程度 emacs 差太远了, vim 提供的函数就远远不如 emacs 丰富. 但也可能是我不了解现在的 vim/nvim.
其实不太友好, 因为我觉得 emacs 比 vim 难上手多了 (可能我是用 vim 习惯了有些先入为主).
哲学家被采访的这段就很有吸引力…
但是emacs到底在更新啥呢 
一些痛点好多年也没解决。
啥痛点没解决？
Elisp 慢？这不有 gcc emacs
GC 实现差？现在在做 MPS
字体渲染卡顿？29 就有做优化
平滑滚动？29 更新的
没有真正多线程？现在没条件，等 MPS 实装就可以开搞了
再比如 emacs 30 更新了什么？
性能更好的 JSON parser 好提升 lsp 体验。
自带 use-package 能通过 git 安装包
基于 tree sitter 的 elixir, html, lua 等 mode
editorconfig 配置的支持
针对开发者，compat 特性方便包作者支持多个 emacs release 版本
改进都是要一步步来的，不播种 patch 又不会自己从地里长出来
emacs开发的真正阻力在于不用git，贡献难度太高，写功能增强时，一堆政治正确的键盘党在bbbb，难得扯，就不贡献了。
用的啥输入法，把「换」打成「換」了？
有人用、有人维护就好，没那么快死的，vim, neovide, emacs, mg, me, joe, acme, sam 都没死绝。zed,helix 想成主流是不可能的。
3个大版本前就开始和其他 GNU 项目一样是在用 git 的，当然不用 GitHub，不是开发者没有要到写入权限就得邮件发 PR，但这个就是 git 本来的用法，Linux 那边也是这么搞的。而且版权协议还是要签的，的确算个门槛。但以我这种只会做小修小补的来说也不算很麻烦，论坛里也有不少人签过。
仓颉，混几个异体字进去防止无断转载的，当然这其实是有几个简体字仓颉码不如繁体有规律的借口
Emacs 是用 Git 的, 具体可以看这里:
https://www.gnu.org/software/emacs/CONTRIBUTE
他们现在已经做得挺好的了, 由志愿者提交的 patch 会署上 author 那一栏, 比如 这个. 虽然 Git 本来就支持这么做…
简短的 patch 一般是直接合并, 同一个 author 累计修改了很多行之后会叫你签署版权转让协议. 总的来说还是能明显感受到 Emacs 的开发是欣欣向荣的, 除了专业的开发人员, 还有一大票的业余爱好者帮忙修修补补.
不知道 Emacs 以前的开发模式是不是像 Bash 一样.
我看过 Bash 的邮件列表和 commit log, 基本上只有一个人在提交. 有志愿者发邮件贡献 patch, 维护者在打补丁时仍然把 author 和 committer 都只写成自己.
这应该跟以前的 Vim 是一样的.
editorconfig 配置的支持
emacs 30 内置 editorconfig 了？
这些年的一些事件, 让我对自由软件有点迷茫, 比如前几年openssl的漏洞问题, 还有一个很流行的js基础库开发者的困顿生活. 自由软件全靠兴趣爱好无私付出, 好像也不是很健康的发展模式:
比如个人兴趣可能丧失, 个人时间和精力可能受生活工作因素影响而不稳定, 维护负担一般会随着时间逐渐加重, 有没有新的人力加入不知道…
再看现在的主流大型自由软件, 比如linux, firefox, 真正发展健康的, 大都离不开商业公司的背后资助, 还有像apache基金会下面众多项目.
一个好的软件, 用于生产环境之后, 就非常依赖稳定可靠的维护, 而不是不确定因素很大的个人爱好和业余时间.
现在好像容易一点了, 大神可以再研究一下.
据我这两年的了解, 他们现在贡献patch比较推荐的做法是, 直接把git patch以文本方式放在邮件内容里, 发到邮件列表里面, 供大家讨论. 不过这个讨论常常很激烈, 经常会有各种争议.
一旦采纳, 需要跟GNU签个贡献协议, 然后应该会对你开放git仓库的写权限, 然后就可以提交.
是的，说起来像是暴论，但大多数开源都是背后有商业公司支持才能持续干下去的，商业公司也不是无偿支持，一般都是需要一些话语权，例如方便开发某些新特性、方便主导社区
这些是开源软件的通病，不单纯是自由软件。
至于 JavaScript 那个测试框架库，它作者一开始自己选择了 MIT 协议，最后被某个大公司白嫖了没法说理；如果选 GPL 协议，可能就是被公司请过去专职做个新的更好的。
知道他为什么选 MIT 协议吗？因为这样约束更少，受众更广泛，有助于这个库的流行，提高作者的知名度。所以说都是自己的选择。
我的看法是，如果你会眼红大公司白嫖你的成果去赚钱，那你一开始就不该选择 MIT 协议。
