今天刚刚在 reddit 看到了这篇 post: https://www.reddit.com/r/emacs/comments/zdi61n/emacsconf2022_lspbridge_a_smoothasbutter/.
里面有不少挺有意思的评论，不过最值得关注的应该是以下几点：
狡辩的人大多数都没有横向对比测试过，试过都说快，哈哈哈哈。
真是为难matthew大佬了，顶着感冒来讲。
试过都说好～～
其实我不是很理解为什么 emacs 社区的人希望一切补全都做成 capf。
vim有个内置的omni补全的机制和capf其实差不多，当然不如capf那么灵活。但是好像vim社区没什么人在用这个omni completion。流行的补全框架，比如coc.nvim，nvim-cmp都是自己搞了一套，完全不用omni。
Emacs社区有非常严重的政治倾向和守旧思想， capf 不过就是一个普通接口， 但是大家都认为旧的接口就是好， lsp-bridge 想告诉很多老顽固的是， 代码补全只要速度足够快， 大家会用脚投票的。
同时， Emacs社区的人是精神分裂的， 一边说这要遵循标准， 一边又在用 ivy 和其他补全插件， 而这些插件都是自成一体系。
所以， 最后都还是要回归到价值导向， 是否真的有价值？ 我现在都不去和 reddit 那些人争论了， 因为很多争论的人从来都没有写过多线程代码， 一本正经的胡说八道， 他们的结论不是来自于真的把 lsp-bridge 和 lsp-mode 做过性能对比事实， 而是根本不试用就凭着自己的经验去评价他们自己都不懂的东西。
以后有不懂多线程的人和我争论 1 + 1 = 3, 我只会说， 对， 你说的对， 你最棒了。
同时， Emacs社区的人是精神分裂的， 一边说这要遵循标准， 一边又在用 ivy 和其他补全插件， 而这些插件都是自成一体系。
您好，我觉得阁下这样的表达方式，或者有点偏激了。
在讨论的时候，只是顺着个人想法的话，就会很难看到更大的角度。每个人的价值观不一样，是没有必要说的那么死。
抱歉，我没有意识到阁下就是lsp-bridge的author，原来您是和 minad 在 github post 又一次的进行了讨论。
其实Emacs社区，也有很多人觉得您做的project 也就是 lsp-bridge 是非常成功的。 饮用其中一个redditor的comment：
But great work from lsp-bridge team, they really show me how super fast lsp on Emacs can be.
那么为什么 Emacs 社区的人会更喜欢 capf 呢。这其实和为什么 emacs-china 社区的人喜欢用 lsp-bridge 大致是同一个道理。讲清楚的话就是，提供很好的功能啊。capf 就像一个communication standard，如 TCP/IP, Bluetooth。有这个 standard 之后，所有想要提供 completion 功能的 packages 就可以按照这个模式来编写他的代码。这是 Modularity and extensibility。
而这位大佬呢，发觉capf是无法达到他想要的目标而从新编写了 acm，这是完全合理的。也是通过这些这位大佬才能写完 lsp-bridge，这也是合理的。
那么为什么 Emacs 社区 希望 写成 capf 呢，请先看上上一点。与manateelazycat 所言描述的：“有非常严重的政治倾向和守旧思想”，我是无法完全同意的，确实 Emacs 是一个非常老的 software, 所以有很多旧包袱。就想现在依旧很多 低层次的软件 kernel 啊都是用 C 来编写的，因为 historical artifects. 但是我觉得我们更应该。。。
其实之前还有一个插件叫 selectrum, 但是我们现在不用了 为什么？deprecated? 他被 vertico 取代了。长江后浪推前浪，世上新人替旧人。详细请见 Issues · minad/vertico · GitHub
在原文中第三点中我提到：“emacs fork of LSP authors, which makes JSON processing async”，这个如果被 upstream 以后，大家都可以享用到更快的 lsp experience。 其实大家都是为了让使用 Emacs 的体验更好，每个人都有自己的执行方式。 儒释道三教本一母所生，而。。。
您有大能的能力，我也希望可以看到大能的胸襟。
以上是我的个人小小建议，还请笑纳，如果阁下有所受用，那就是我的小小贡献。
请不要给我戴这么高的帽子吧， 我就是一个普通人。
我只是希望大家在讨论性能、生态、个人品味、道德和胸襟的时候能够分开去思考。
capf并不是大家说的标准， 只是写插件的人多了而已， capf本身缺乏对性能设计的考量， 这是我一直想和大家强调的， 还有多线程知识的普及。
但是很多人讨论真的不基于事实去讨论， 讨论不清楚， 就开始搬政治、 道德、 上游、 胸襟这些东西出来， 真的很烦。
Emacs是工具， 提升其功能和性能是每个插件作者的目标， 如果觉得有更好的方案， 就像 Linus 说的， Stop talking, show me the code， 事实说话吧， 不要把代码、政治和自我意识混在一起吧。
我没有大家想的那么高尚， 我只是讨厌社区的道德绑架 （己所不欲， 勿施于人）。
欣赏猫哥的技术和洒脱，搞技术这玩意，暂时还不需要上升到道德这个层面来说吧。我也真的挺烦那种要求猫哥做圣人的道德绑架。猫哥不但技术好，还一点不装。哈哈，有趣
价值导向，这个词很对。
corfu的作者觉得 capf 在一些地方很好用，比如 comint 模式， eshell 模式那就在那些好用的地方使用 corfu 来配合 capf。
capf 的机制不适合 lsp （这点他自己也是同意的，只是认为可以用很 hack 的方法实现），那就在写 lsp的时候不要配合capf。
不能对原作者提出过多的苛责，说没做这个没做那个，这个应该怎么做，那个应该怎么做，如果是小的方面还好，改一下也就过去了，如果是比较大的考量，还是提意见或建议的人自己动手做做看，看看效果如何。
在这个具体的例子里，猫哥对 capf 做了一定的研究，发现不适合自己的需求，另起一套也没什么，没道理说非得怎样怎样。有人说能不能让 lsp-bridge 给 capf 提供数据，有这种需求就直接去做好了，总不能让没这种需求的人去做吧。
如果是要包含在 Emacs 里面，那考虑的东西多点没啥，需要各种讨论，有了决议再做改动。个人项目的话还是作者自己的想法最重要，谁也说服不了谁的话，fork 就是了，看谁能活下来。
天下武功，唯快不破
说的是啊， 原教旨主义在软件领域里可太多了。 