我之前试过common lisp 开发的lem 但是说实话有点卡手
但是如果支持多线程又要解决一些设计问题。 比如多个线程竞争刷新界面(暂时只想到这一个 
)。
不过我了解过unity的做法，单开一个主线程以60fps 去刷新界面，其余的线程不可以直接修改界面，只能委托主线程修改界面。
这里开个讨论贴，要是emacs要支持多线程，应该怎么设计emacs。 
1 个赞
lazycat 的 eaf 已经提供了思路了吧
为啥不支持？
因为设计之初就没考虑到多线程。等到它成为问题时，代码已经堆成了“屎山”，并且已经形成了围绕着“屎山”的生态圈。谁也不敢贸然改动，一动就塌了。
为今之计就是，“屎山”的代码继续留在“屎山”，旁边另外堆一座小的，做好规划，两山并立，然后捡那要紧的“屎”一点一点搬过去。日复一日年复一年，赶在脑机接口到来之前，应该能用上流畅的 Emacs。
4 个赞
双线并行的难点是，需要单独给每个用到的API做线程隔离处理，保证访问新API不要影响旧的单线程API，这个工作量非常之大，同时还面临单线程API在新增功能的同时，新的API和旧的API功能上不能有太大差异。
这是理论上可能，但是在emacs社区没有强力领导的存在，基本上就是不可能。
现在马上可以实现的参考方案: 图形用EAF类似的技术，非图形用lsp-bridge类似的技术，效果杠杠的，不需要修改emacs。
3 个赞
我把 EAF/lsp-bridge 算作双线并行的一种实现了，甚至更倾向这种形式。
这种外部实现多线程的方式，三方开发者可以自行评估可行性，率先迁移自己的包，不仰 Emacs 开发组的鼻息，好赖都是自己的锅。对用户来说，一些三方的包改坏了也打紧，至少还有 Emacs 兜底。
反而 Emacs 内部实现不太可行。如果短时间内完成改造，发一个破坏性更新的版本，会让所有的用户或三方包作者措手不及；如果循序渐进慢慢改造，则长期双线并行，必定消耗大量的人力。
6 个赞
多线程编程有共享内存, 用起来很麻烦, 各种 mutex condvar, 设计 API 时也要考虑是不是 thread safe 的.
最简单的访问一个defcustom定义的全局变量, 在多线程条件下就得加锁访问.
如果要接上第三方的 C 库, 那要是线程不安全的代码在多线程条件下执行了, 就出问题了.
再加上 Emacs 最开始也没现在这么多功能, 所以选择了简单的单线程
2 个赞
cooperative multithread，或者干脆同一时间只有一条线程在运行
最大的问题是没人在写代码。真写完了顶多半年也能上线了
老风扇在改GC，改了GC后有可能改多线程吧 ，，，
说不能在emacs内部改的都是在给自己改不动emacs代码找借口而已。
我目前在读emacs的image.c，从这里入个门
6 个赞
协程并不能解决图形卡的问题，要真正并发多线程才行。
我现在org文件8.3M，4356个headline，每次搜索3级以上的headline，平均体感要等待4秒。
我希望在大的org文件中（20M以上），搜索较深的深度（6级深度）的headline，展开任意篇幅的headline，能够秒出，像vim那种反应速度就棒棒棒！
这个用 ripgrep 搜索就可以了。
3 个赞
谢谢提示，我学习下这个，哈哈
行动起来，革了屎山的命，我相信EmacsGay的能力
这个表述不太好 ，用复杂不好懂这种中性词可能好点 
1 个赞
老项目积重难返吗 隔壁vim都开新坑neovim，结果nvim发展的还挺好
2 个赞
就我们公司的游戏项目，据说后端当时太急了就一个人。 当时我现在的老大一个后端 vs 8个前端。框架都没写就开始接业务了。 结果就是框架的并发数据重入问题到现在都没解决，不过好像是我来了才发现的就是了。 项目没那个量级，所以之前一直没出过问题。 但是虽然有这个问题但是却没人改，因为。。。。。。
上一个要革Emacs命的 Guile Emacs, 坟头草都三丈高了……就最近有人给上了个香
你说的就是我。。。。。。
我说的是那个提交的人 
2 个赞