想新写一个LSP Mode

来个地址看看?

另外似乎不是第一次开战了

Issue 180倒还好…只能算是激烈讨论,他们在这里骂起来了

1 个赞

邮件列表里有人写了一个针对 java 的插件,我没用过,或许可以试试看。

https://lists.gnu.org/archive/html/emacs-devel/2019-12/msg00056.html

可以透过Emacs内建的completion-at-point-function机制实现补全(印象中eglot, lsp-mode都是这样做的),Company有一个company-capf后端可以直接使用completion-at-point-function的结果。这样不用自己写一个company后端,其他Emacs插件也比较好整合。

这玩意儿不是一个包,而是改的 emacs 的代码?

笑死,他们本来在issue里就快打起来了

LSP协议我觉得用其他语言实现反倒会更快一点, 因为lisp里的结构体, list, alist以及hash table 真不如其他语言里的结构体, 数组和map用起来简单方便. 多会话之类的管理起来也挺痛苦, 而且不能真并发. 所以lsp用其他语言比如golang或者rust开发起来可能更快. 当然最主要是更高效.

1 个赞

用 rust 实现性能是毋容置疑的,我指的是复杂度。功能多就会带来复杂度,少了用户体验又不会好。这需要平衡,很考设计功力啊。懒猫准备来克服这个难点吧

json解析的数据量多了关系就大了, 主要是因为emacs的单线程, 解析不是异步的.

之前用过dart的lsp, 极卡, 调试发现, lsp server给过来的补全数据太多了, 一下来上万行, 能卡几秒.

如果数据的接收和解析都是异步的, 解析后再限制一下补全结果数量, 然后再给传给emacs, 这样应该会很流畅.

对eglot来说, 协议通信好像用的jsonrpc库, 如果jsonrpc库用动态模块在异步线程实现, 性能应该会好很多.

包括复杂度, 我感觉lisp实现复杂的协议挺麻烦的, 远不如golang, golang比较适合做复杂的通信协议. 包括c++, 我觉得都会比lisp开发起来快. 当然, 可能我对lisp不够熟悉.

建议 @yyoncho 来看看这个贴

这个不好讲,有些用 lisp 实现很方便的,但和一般语言差别有些大。

印象中, lsp-mode的issue里有人提过用动态模块实现lsp的想法.

嗯嗯,我关掉了lsp-ui; 不知道是不是最近有更新,感觉会在底部提示很长的函数使用,我其实不需要,但不能关掉,很抱歉还没有认真读它的readme。

其实我用lsp很多,在python,在c++,也用dap和它配合,感觉还不错;在python上提示,比ananconda-mode要全面。

目前市面上各种服务和复杂协议几乎都是其他语言实现的, 整体经验和库肯定要比lisp成熟很多, 从这方面来讲, 开发效果几乎可以肯定会超越lisp.

Most likely it wont. Dynamic modules are extremelly inefficient when there are elisp calls from rust also converting RUST datastructures to elisp datastructures should happen in the emacs thread - you cannot call elisp methods not being in emacs thread.

See [Discussion] json dynamic module · Issue #676 · emacs-lsp/lsp-mode · GitHub

IMO ATM the easiest way to achieve what OP is describing is to rework emacs core to allow memory allocation to happen on multiple threads(we were discussing that with Eli Zaretskii) and then implement async JSONRPC either in core or in dynamic module(assuming async support is exposed in dynamic modules). But recently. Eli Zaretskii optimized the json parsing with 30-40% and also the JSONRPC layer in lsp-mode was rewritten and optimized (~2times faster) I cannot find a scenario in which lsp-mode is not reponsive when using latest Emacs 27. Before that I was planning to open a discussion with Eli in emacs-devel but now I do not have performance report to backup my request - everything is fast enough.

4 个赞

If you do not like the import project dialog you may turn it off via setting lsp-auto-guess-root to t. Without the interactive root selection we were getting dozens of bug reports from users who have selected the wrong project root due to monorepos or similar.

Also, for all that do not like lsp-mode defaults - please share your opinion here: [poll] review some default settings · Issue #1226 · emacs-lsp/lsp-mode · GitHub . I am planning to move flycheck integration into separate package so lsp-ui will become optional component. Apparently, a lot of people do not like it so maybe it should not be enabled by default. Bear in mind that it is impossible to have defaults which everyone likes…

1 个赞

@yyoncho so, what do you think about the idea of using dynamic module to improve lsp-mode? I also think rust (or golang?) is a good choice.

文档显示可以加入ghelp支持😁我可以PR