vscode插件可以多线程，可以看下开发文档
emacs插件可以多线程，可以看下开发文档
3 个赞
我咋没找到？
你说的emacs 26以后的伪多线程吧? 我知道啊. 这种可称之为协程. 我说的是真多线程. 另外emacs 26的伪多线程还有问题没解决, 所以基本没有插件使用.
我说的是VS code的language server相关插件.
需要并发多线程的地方是真正耗性能的地方, 比如渲染引擎(webkit应该是多线程的吧? firefox的都多线程了), lsp等. 其他很多小功能是可以用单线程异步来实现的.
我是说你写个module
这个考虑过, 但是有个很大限制: 你的线程很难主动和emacs通信. 没有正规高效的通信途径. 如果能提供一个高效的通信接口, 这种方式也很不错.
用hook不行吗？
多线程会带来新的问题。我觉得目前lsp的思路才是emacs真正多线程的解决方案。
emacs27里 lsp 大约快多少呀？ 
post-command-hook这样的吗? 不够及时, 用户半天无操作, 就没法接收数据了. 而且感觉挺别扭.
看到一种方法是用signal来通信, module里给emacs发送一个信号, 好像是类似SIGUSER的, emacs收到信号后, 过来取数据, 效率比较低, 也挺别扭.
感觉emacs 26目前的线程模型不合理, 类似python的GIL模式, 而python多少年都还是类似单线程, 没有突破.
我感觉web worker的多线程模型更适合emacs, 限制后台线程的功能(不能访问用户buffer, 不能访问界面, 不能跟用户打交道), 甚至可以用沙盒环境来隔离执行后台线程, 后台线程与主线程运行环境隔离, 后台线程只用来做高负荷任务, 任务完成把结果发送给主线程. 有点类似外部进程模式, 但是通信更高效, 而且依然用elisp来开发. 这样对emacs现有的东西影响不大.
实现思路: 把现有的elisp解释器多跑几份就行了, 可以每个worker单独一个, 隔离开, 然后在多个解释器之间建立一套通信API就OK了, 工作量应该不是很大.
当然多线程还有其他比较重要的地方(elisp看不到的), 编辑器内部, 比如渲染部分, 这部分可能比较复杂.
2 个赞
不用mac不清楚…
应该是多进程
我也转到vscode一年多了，偶尔登录这个网站，看看emacs有什么进步没有。。。
叛逃直接用个人博客就好，还非要用社区知名账号，赶在五一放假期间发文，就是个戏精。
2 个赞
虽然我是传火萌新，但我喜欢纯大剑😶
现在win10上emacs的环境还是msys2比较好用，我已经觉得能稳定使用了。
不传火，去如密看海，杀猪，跳大坑
神器进化需要全新的思考、UI和交互模式，增强稳定性和中文的支持。
4 个赞