说不定重开一个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不卡关键是要有完全并发的多线程，协程不行。