我觉得Emacs很难进化的是下面诸多偏见：
- 图形的快就是多线程要做好， 不是说语言执行有多快， 只要是多线程实现的好， 一个后台代码是1x的速度还是10x的速度， 只要不要卡住主线程图形绘制， 用户就会觉得很快， 所以很多Emacser理解不了， 用户说的图形流畅其实等于多线程不卡主线程， 而不是图形流畅就等于最快的执行速度， 如果rust也只能单线程， 一个任务的时间超过一个周期的耗时， rust也会卡的
- GIL主要是在多个线程高并发的执行时会出问题， 但是从图形编程来说， 只要 threading 处理好， 子线程和主线程只交换简单的处理结果， GIL不会阻碍多线程图形编程， 但是很多没有写过图形编程的人， 从来就没有写过一行图形多线程代码的人， 就会把后台多线程遇到的GIL问题归结为也会影响图形多线程
- 很多Emacser分不清楚多线程和协程， 因为协程式的多线程本质是单线程快速切换， Emacs没法解决全局变量/hook/advice的问题（这也是Emacs好hacking的优势）， 所以用了协程式的方式实现， 但是协程式的方法就没法解决图形多线程的问题， 因为任何一段代码卡死， 整个事件循环都会卡住， 因为切换不出去了
- gnus可以比较好的实现就是 blink-search 或者 telega 这种方式重写， 用外部进程来解决性能， 然后界面部分依然用 elisp 来实现， 只是虚拟窗口的界面实现要比超长buffer渲染的逻辑要更加复杂， 因为要有很多 screen offset 处理， 但是从我的 blink-search 实践看， 完全可行， gnus 或者 magit 都可以用外部进程来最小化代码改动来解决这些性能问题， 而不用大幅度修改Emacs本身代码
上面这些仅仅是一部分偏见， 我觉得这些偏见的来源于是大部分Emacser没有足够的知识去了解多线程、图形编程、协程、 GC瓶颈等细致的区别， 导致我说再多， 大家只会进入个人抬杠。
我现在基本只分享我的经验， 如果某些杠精（或者查理芒格说的基于忌妒心理来抬高自己）来故意抬杠， 我会说： ”对对对， 你说的都是对的”。
我总体对Emacs的态度来说， EAF + lsp-bridge 已经让我很幸福了， 我自己的小愿望已经实现， 同时不用对Emacs改造什么就很舒服了。
至于为什么要发这个帖子， 是因为我原来认真思考了所有逻辑， 我认为只有EAF这一个方案可行， 但是 @DogLooksGood 狗哥启发了我， 其实还有 Emacs Overlay Client + New Graphics Library + Multi-Thread 这一条路， 虽然我认为 Emacs Overlay Client 的难度不小， 但是依然是理论上可行的方案， 如果实现了， 效果要比 EAF 好很多。
所以我发了这个帖子， 但是我不期望大家理解， 只是分享。 懂的人自然懂， 说多无益。