其实你第一楼是不严谨的，emacs大多数卡是post command太多或者大数据导致的gc回收不及。
本质是没有多线程的原因。
但是你很多表述不严谨，异步进程只要返回大量数据让emacs处理就会卡，lsp-mode本质就是异步调用lsp server，为什么卡呢？lsp server本身不会卡emacs，但是它吐很多数据硬塞给emacs处理，emacs处理不过来就卡，产生过多gc就会导致卡顿加剧。
gc不是不会卡，而是你产生的数据量不够大，你对几千条字符串做一个复杂正则和overlay操作，马上就卡了。
我觉得不能脱离emacs生态谈技术，那个谁都会，但是怎么改善emacs呢？
你有很好的学习劲头，可佳可赞，但是思考不严谨。
彻底解决emacs卡的方法是，把emacs当做elisp解释器用，界面绘制和界面状态管理用新的进程去弄，这样启动多少个elisp解释器都没问题。
这样既可以利用现代界面和并发多线程，又可以兼容elisp语法写阻塞插件慢慢算。
这就是neovim的做法，可行有效果，什么时候有希望呢，哪天哪个牛人花几年时间写一个新的emacs前端，只要效果好，大家都愿意转。
其实我觉得clojure+ skia是最少纠结的实现方法。
抛砖引玉。
我没怪插件的作者。我的意思是如果遇到emcas卡，多找找插件是不是把io/异步这些东西处理好了，解决方法是不是可以优化，别总是怪emacs gc不ok，没多线程。
unwind-protect是一个异常处理上的问题，有可能是想这段代码不管出不出问题后续的代码都应该继续执行，且必须清除之前对全局变量的操作。如果只是关注全局变量操作恢复，用let临时绑定也行，但是考虑到要进行异常处理，我不觉得这个地方有什么不妥。
你说的正则匹配什么的，29之前可能是问题。29之后好好写，应该不会造成问题，本质就是一些计算。如果并不涉及io阻塞，除非里面写出了恶性的循环，或者需要对一个大文件进行一次扫描这种耗时操作，理论上不会卡。如果里面做了大量耗时操作，是不是应该考虑优化呢。 如何实现同样的操作，得看是在什么样的场景下。你说的这个情况就像是，我要用反射，就有些人喜欢跳出来说反射慢。但是不问我要在什么地方什么场景下面用，实际上我用反射的地方可能服务器启动10天只会调用到10次，这东西能不能用你得先预估或者算一下。1个编辑操作1ms完成和2ms完成对用户来说并没有什么不同。如果一个操作花了一秒，就算语言本身性能提升5倍，也是200ms的延迟，这个用户就可以感知得到了。用户不觉得卡，你怎么实现顶多是优雅不优雅的问题。
今天我做了一次fib的bench, emacs开native-comp (speed 2) 大概比jit过后的python,lua慢2-5倍。但是要好过没jit的python。本身数据处理量不大的话，你用哪个语言感知是不强的。按我的理解，29之后，emacs已经提供足够好的性能了。
这种情况我建议只对视窗下的界面做渲染，数据量太大go这种也gc不过来的。当然同样没优化的情况下，go 肯定比emacs挺的更久，抗住的数据量更大。
如果是大数据量可以考虑用对象池，只对可视范围做渲染这样的方式做优化。优化的方式还是有的，就是愿不愿意去做的问题。语言本身如果性能更好，当然皆大欢喜。当然，emacser都是用爱发电，我也不能要求他们都按照商业项目的标准去优化。
谢谢，我想到一个问题，既然都是多线程，在事务原子性前提下，理论上二者应该没有区别吧？
协程实现的多线程代码如果多处理执行会产生新的问题吗？
要看是有栈还是无栈，像go这种有栈携程可以拿到线程，是可以真正并行的。lua那种无栈的，不会跑到别的线程上执行，不能说是并行的。
建议搜索一下，肯定是有区别的
blink-search已经是针对界面做渲染处理的，效果是很好，但是我要说的是，仅限于普通的列表渲染实现复杂度还行。
但是对于上下文很长的情况，像emacs这种编辑器，还有很多视窗外的对象需要处理，编辑器级别做可视化坐标渲染转化工作量会大很多。
我之所以回复这么多就是如果你有什么想法你自己做吧，现在的问题不是能不能做的问题。而是做之前你和不懂的人沟通，浪费彼此的时间。
因为你和没有做过图形编程的人沟通，你并不会说服他们，他们反而拿着局部的知识和你掰扯对和错，你要从普及多线程图形编程开始说，累不累啊？
话说现在mps有望解决gc导致卡顿的问题吧
没用过哇， 期待。
有编译好的mps版本，猫哥品鉴下呢
主要是 EAF + lsp-bridge + blink-search 这三个工具已经卸掉我99%的GC了， 所以我超级流畅哇， 哈哈哈哈。
@manateelazycat 看了大佬的帖子 New Emacs 构想
提一下这篇博客 Emacs GUI library · Andrey Listopadov
其中提到 https://gtoolkit.com
阅读了这篇博客之后的一个思考就是：
Emacs 用户真正需要的一定是在 Emacs 的纯文本界面中做一切事情吗？
还是一系列围绕着软件开发所需要的，所有可互相感知的功能组件。尤其是在图形界面能提供越来越多直观帮助的今天。
我打算有空深度尝试一下 GToolkit
我理想中的开发环境：一个 GUI 界面管理 Workspace，在 Workspace 里开启各种各样的 GUI Widgets 之类的东西，比如 VCS View 使用像 Magit 这样的工具， Edit View 我可以选用 helix，还可能有 Test View、 Run View，通过统一管理的键绑定在这些功能组件间自如切换。
我以前读过， 不要有洁癖， 现在EAF就已经实现了外部GUI和Emacs无缝融合（mac用户支持不了）。
如果有洁癖， 就是New Emacs （NeoVim）那样搞， 但是工作量巨大， 完全可行， 头发要掉一半。
如果没人做， 我觉得大家就不要讨论了吧， 纯粹浪费时间。
新的 emacs 版本下，mac 上配置 eaf 也达到可用水平，尽管 eaf 的界面有时会不跟着 emasc 的窗口走，但总算可用
是嘛， 大佬发一张截图看看？
可用了么？怎么配置的呀
有点尴尬…
之前用的是 30.91，当时是可以用的，看 pdf，上网，还有 file-manager 和 pyqt-terminal 都没啥问题。但昨天升级了 31，是 emacs-plus@31 这个发行版，然后发现出问题了：
我升级 emacs-plus@31 的目的是能够使用中英混输的 patch。
总之，在前天，我还很愉快地用 file-manager 来找文件，看了一会儿 pdf。
emacs-plus@30，没特别配置， 就是官方 Readme 的参考配置。但我现在 emacs-plus@31 有问题，请参考我上一条回给懒猫大佬的回复。
看看是不是依赖没装
