台湾的 Emacs Twitter 账户维护者“叛逃”到 VSCode

vscode插件可以多线程,可以看下开发文档

emacs插件可以多线程,可以看下开发文档

3 个赞

我咋没找到?

你说的emacs 26以后的伪多线程吧? 我知道啊. 这种可称之为协程. 我说的是真多线程. 另外emacs 26的伪多线程还有问题没解决, 所以基本没有插件使用.

我说的是VS code的language server相关插件.

需要并发多线程的地方是真正耗性能的地方, 比如渲染引擎(webkit应该是多线程的吧? firefox的都多线程了), lsp等. 其他很多小功能是可以用单线程异步来实现的.

我是说你写个module

这个考虑过, 但是有个很大限制: 你的线程很难主动和emacs通信. 没有正规高效的通信途径. 如果能提供一个高效的通信接口, 这种方式也很不错.

用hook不行吗?

多线程会带来新的问题。我觉得目前lsp的思路才是emacs真正多线程的解决方案。

emacs27里 lsp 大约快多少呀? :thinking:

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和交互模式,增强稳定性和中文的支持。

3 个赞