VSCode的插件都运行在一个独立的进程里, 被称为 Extension Host, 它加载并运行插件, 让插件感觉自己好像在主进程里一样, 同时又严格限制插件的响应时间, 避免插件影响主界面进程.
这个东西挺神秘, 想象不出来它是怎么实现的. 跟async.el应该是大不一样的, 它跟主进程之间应该会有一些复杂的通信协议. 好像一直没看到过这方面的文档.
这个东西也非常适合emacs, 也许emacs里也可以搞一个类似的机制, 和现有的机制并存, 可以把部分影响用户体验的插件放在外部进程里运行.
是基于electron的，可以看下它的api
api在哪里?
你是不是把这个东西看太简单了? 或者对底层的东西不感兴趣?
重点不是electron, 而是这个插件进程, 它里面运行的是js代码, 但js代码实际生效的地方却在另外一个进程里, 这得需要多复杂的IPC协议才行? 如何保证它的效率? 如何限制js代码的响应时间?
想想感觉太复杂了.
VSCode的这部分文档不好找, 没找到, 也许要看插件进程的代码才行.
前两天看了一下firefox插件部分文档, 它的插件也是在独立进程, IPC协议相当复杂, VSCode跟他估计是完全不一样的, 但是功能差不多, 应该也是一套复杂的协议.
两三年前看的了，具体细节不记得了，直接去官网看啊。
通讯应该是ipc ，要写server和client两端的东西，然后根据track message id来通讯
差别有点大，async.el 就只是启动一个非阻塞 Emacs 进程运行代码，运行完了返回结果，进程也结束了。
官网看过了没有啊.
看了firefox的, 已经大致了解了.
看了firefox的文档, 感觉比async.el要复杂好几十倍