谢谢提示，我学习下这个，哈哈
行动起来，革了屎山的命，我相信EmacsGay的能力
这个表述不太好 
，用复杂不好懂这种中性词可能好点 
1 个赞
老项目积重难返吗 隔壁vim都开新坑neovim，结果nvim发展的还挺好
2 个赞
就我们公司的游戏项目，据说后端当时太急了就一个人。 当时我现在的老大一个后端 vs 8个前端。框架都没写就开始接业务了。 结果就是框架的并发数据重入问题到现在都没解决，不过好像是我来了才发现的就是了。 项目没那个量级，所以之前一直没出过问题。 但是虽然有这个问题但是却没人改，因为。。。。。。
上一个要革Emacs命的 Guile Emacs, 坟头草都三丈高了……就最近有人给上了个香
你说的就是我。。。。。。
我说的是那个提交的人 
2 个赞
说不定重开一个neo emacs会起飞
1 个赞
Guile Emacs 只是想革 ELisp 的命吧？就算革命成功，也不改 Emacs 本质。
vim其实也是单线程的程序，neovim也没办法改变vim单线程的问题。但是neovim使用了lua作为配置语言，lua配合libuv想要多线程啥的就很容易了，但是所有legacy的vim的东西，比如buffer，ui，tab。window之类的东西，都是没办法在子线程里访问的。但是luajit确实就是快，再加上vim本身没有很重的ui渲染（始终是一个终端的编辑器），所以单线程的问题其实并没有在这边体现的很严重。
多开lua虚拟机？
渲染都是在主线程做的啊，安卓在主线程跑阻塞的任务也卡
Gtk+陷阱与进阶技巧 我十多年前给 deepin 团队做的内部培训的PPT， 大家可以看一下。
很多没有图形编程经验的人区分不了操作系统并发多线程、 应用或语言内部实现的协程的区别。
图形编程不卡的关键核心不是主线程运行的代码或语言性能要多高， 因为一个屏幕的图形绘制都是常量性能要求， 关键是要完全并发运行的后台线程要分担非图形的耗时代码出去， 不要影响主线程绘制就可以了。
而所有协程的实现（Haskell、 Golang和Emacs等）的原理是自己做线程调度， 一瞬间只有一个线程在跑， 这种原理都不能完全解决图形卡顿的问题，因为一旦非图形线程耗时太长， 协程根本没法停掉非图形线程， 也会导致主线程因为没有得到事件循环和绘制的机会而卡顿。
而这个话题之所以翻来覆去的说， 是因为很多Emacser自己并没有自绘控件和并发多线程的编程经验， 没有实际实践过的人就傻傻的分不清楚协程和操作系统线程的区别。
协程的应用场景是服务器后台IO密集、 CPU不密集的场景， 来回切换协程资源占用少， 并不适合图形编程。
10 个赞
golang 这种有栈协程，好处就时切换的时候快的飞起， 但是runtime确实非常的重。
它这种模式倾向于公平调度的场景，不适合gui的绘制，绘制的主线程 每16ms至少分到10ms做事情才不会有卡顿感。
golang不是一个线程的吧，只是一个线程只会在某一瞬间被一个协程占用，但是协程与协程之间是并行的
lua的协程才是单线程的
真正的图形多线程，主线程绘制线程和后台非图形线程之间是不需要切换的，快速切换的都是语言自己实现的协程。
协程代码没有执行完之前是没法切出去的。
可以搜索一下为什么所有图形库都要支持多线程和事件循环。
2 个赞
所以说UI需要的是真正的多线程，而不是协程。如果能有一个统一而稳定的异步机制就可以，可惜历史包袱太重。终端下倒也无所谓。
对，UI不卡关键是要有完全并发的多线程，协程不行。