目前 Emacs 及 (neo)vim 中的各个 lsp 实现,其性能和完成度表现都如何?

成熟且活跃开发的有 lsp-mode、eglot、coc.nvim。

新的主打性能的有 lsp-bridge、lspce、nvim-lsp。

前面三个功能较为成熟,lsp-mode 的性能问题十分严重,另外两个评价似乎都不错(我本人没有用过)。

lsp-bridge 性能很好,但是功能较为精简,且使用独立的补全后端,要和现有的非 lsp 的后端共用需要给它们写接口。

lspce 性能稍差于 lsp-bridge,功能同样较为精简,兼容现有的 capf。

nvim-lsp 我没有尝试,从基于它的 lunarvim 来看似乎可以实现较完整的功能,包括基于 lsp 的高亮等。性能方面不知道,有同时使用 neovim 和 emacs 的用户分享一下感受吗?

希望 emacs 早日获得一个全功能且高性能的 lsp 客户端。

我补充一点:前端开发有同时多个 LSP 后端的情况,目前只有 lsp-mode 一家支持,希望这个特性早点儿补上吧。

我是无能为力了:Elisp 只是基本会用,能改配置;好多语法都不懂,当然我也会慢慢学习,但短时间内不会有什么代码贡献了。。。

我目前用lsp-mode 感觉速度还可以,尤其是在28.1 以后。 使用的这两年,感觉没啥问题。

同lsp-mode,可能是我开的补全延迟比较高(1.5秒钟)所以没有感觉到卡手。

lsp-mode 的性能问题十分严重 ,这个结论从哪里得来的?

从emacs 28.1开始,如果从源码编译的时候开启 --with-native-compilation–with-json,然后再按Performance - LSP Mode - LSP support for Emacs 中优化下lsp-mode,目前使用下来没有很明显的卡顿,只要不是急性子的话,估计大都可以忍受了。
别的不说,lsp-mode的功能是真的全,lsp协议本来的目的就是尽可能提供接近IDE的体验。lsp-mode尽可能实现lsp协议中功能的思路我感觉倒很是贴合lsp协议设计的初衷。

5 个赞

目前 Emacs 及 (neo)vim 中的各个 lsp 实现,其性能和完成度表现都如何?继续讨论:

  • vim

就vim 和 emacs文件编辑和软件开发上的体验来说,vim更加稳健,emacs更加方便。我之前nvim使用的 coc.nvim全家桶,体验非常好,唯一感觉不好的是node作为补全运行环境。后来又全部迁移到nvim-lsp,全lua运行时环境,感觉和coc.nvim差不多。

  • emacs

emacs 之前很早就接触过,但是一直没有怎么使用。由于vim搜索功能没使用到位,以及定制化脚本很难看懂,所以就暂时转到emacs,elisp脚本语言相对来说较规范。快捷键功能、搜索等都集成度很高。

如果vim有emacs方便的快捷键功能和搜多功能 我还是喜欢vim的稳定,稳如老狗

lsp-mode 和nvim-lsp我都用过。当初就是lsp-mode太慢转到neovim了。用着的体验,最快应该就是nvim-lsp了。不过lsp-bridge也很快,几乎感觉不到两者在速度上的差别。

也就是说 nvim-lsp 同时拥有接近 lsp-mode 的功能和 lsp-bridge 的速度吗

neovim内置的lsp跟lsp-mode这类功能全的不太一样。nvim-lsp更像是一个内置库的存在。你所说的功能,都是各个插件实现的,都是基于nvim-lsp这个内置的东西。光有nvim-lsp是不够的,缺什么就找相关的插件,或者自己写。基于nvim-lsp的插件太多了,我感觉应该能满足的你需求。

对于 lsp-mode 的功能完善程度而言,性能还算不错了,其他的框架要做这么多的功能,性能不一定好到哪里去

我用lsp-mode感觉还行啊,把乱七八糟的东西都关掉,单独用补全的话我感觉还可以的;本来输入也没有那么快的手速; 楼主用过哪一种?怎么就感觉lsp-mode的性能问题严重了?哪一种语言?开启了哪些功能?

eglot用着也很舒服,可惜我比较喜欢的breadcrumb不支持,最后还是换回lsp-mode了; lsp-bridge很流畅,但是匹配排序的细节感觉不如lsp-mode,而且和company,corfu都不兼容;我有些配置是依赖company的,实在懒得改了。

现在还是lsp-mode用着;

这个和电脑配置关系比较大,我公司的垃圾电脑(五六年前的 mbp),lsp-mode 卡到没法用(只用补全和跳转,别的功能都关了不用,我也不喜欢),家里的电脑就还在可忍受的范围,项目不大,golang项目10万行以内,python三四万行的样子。lsp-bridge 就完全不卡手。每当有人说 lsp-mode 性能没问题时,我都想让人远程到我电脑上写几行代码试试。。(不过觉得不卡的接着用,觉得卡的换就好了,这种环境差异的问题,也没啥)

当然是在相同水平的硬件下进行比较

这是我回复上面那位的。不过关于这个帖子的主题,我觉得 nvim 内置(也不能说内置)的 lsp 就比 emacs 这些都好用(我不需要太多花哨的功能),luajit 还是快,之前 emacs 太卡,配了 nvim 用了一阵子,虽然不是太习惯,现在 lsp-bridge 出来,就换回 emacs 了

nvim的内置lsp的性能估计是最好的,毕竟是luajit。lsp协议基本上应该也都实现了,但是nvim主流用treesitter做高亮,社区似乎基本都不太在意lsp的语义高亮做的怎么样。nvim-lsp目前也支持多个lsp用于同一个文件,使用的时候比如多个lsp都支持format,会弹出来让你选择使用哪个lsp来format。

话说vim和emacs一样都是单线程的程序,之前看懒猫分析过为什么emacs的lsp性能会这么卡,就是因为elisp的性能不够,会堵住主线程。在nvim里coc和内置lsp其实表现是差不多的,但是coc也是异步架构,vimscript+js,但是我很好奇为什么coc就一点都不卡,非常好奇,理论上来说vimscript应该性能要比elisp还要差很多才对。

再慢的语言,只要有多线程支持,都不会卡手。

emacs的线程本质是和协程类似的概念,只要当前线程阻塞,就切换不出去,不是真正意义上的并发线程模型。

1 个赞

不管什么样配置的电脑, 同时用一下 lsp-mode 和 lsp-bridge , 就可以明显感受到可用和流畅的区别。

建议直接对比用一下, 感受就很明显。

多个LSP服务器都支持 format 的时候, 每次format或者其他操作都要让用户选择一个LSP服务器, 这样弄不麻烦吗?

只有format需要主动选择使用哪个lsp吧,code action之类的会自动把所有得lsp提供的code action合并到一起,补全的话由补全前端把结果合并到一起。nvim里可以主动选择禁用掉某些lsp的某些功能,这样就可以每个操作都只有一个lsp。

vim其实也是单线程的程序,也不支持多线程。但是coc一点都不卡,是因为emacs的completion-read之类的函数处理补全结果都是在主线程处理才导致卡顿的吗?coc是补全后端前端都是由自己提供的。