lsp-bridge -- 速度最快的语法补全插件

Emacs-general
62

诊断有别的工具吧，我就想把性能做好，不想做乱七八糟的功能。

我不想变成下一个lsp-mode

63

赞同，我期待一个速度够快的补全前端已经很久了。我平常写动态语言和 c ，用 gtags/ctags/grep 进行代码索引，Flycheck 进行查错，唯独语义补全不是很满意。 lsp-mode 一是速度不够快，二是开启很多额外功能，只是用来补全有点牛刀杀鸡。

我用过一段时间的 vim, 因为 ycm 很快。那时候还没有 lsp, 不过我只用 ycm 补全，用 tags 导航代码。

64

确实应该做减法，而不是加上很多功能。

nvim+lsp用起来真是丝般顺滑。有时候写python会用nvim。

65

lsp-mode 就想完全模仿 VSCode, 我觉得 Emacs 这边主要应该关注高性能、全键盘和极简设计，大部分 Emacser 不需要像 VSCode 那样面向新手设计，塞一大堆华为不实的功能。

3 个赞
66

其实lsp-mode我用起来还挺顺滑啊，是不是配置不同？不需要的功能都禁用掉，然后按照readme中的性能优化修改一些配置。对我工作的项目够用，用的是gccemacs 28.1，Macbook Pro M1。

67

你不觉得 lsp-mode 每打开一个文件都要卡顿一下吗? 而且我不明白 lsp-mode 为啥要开发那么多没用的功能？ :sweat_smile:

68

不会啊，打开项目第一个文件时会启动server，这时卡一下，后面的文件都不会啦。也跟server有关，go、rust，工程2000多个文件丝毫无压力。python跟包含的lib多少有关。

而且我不明白 lsp-mode 为啥要开发那么多没用的功能？

每个feature都是可以单独打开关闭的，有些功能还是不错的，比如我喜欢用xref、peek，还有lsp-ui-doc，鼠标放上去显示文档，跟VS逻辑一致。

2 个赞
69

所以呀，这还是设计问题，lsp-bridge 不管 server 是什么语言实现的，都是秒开，不管 server 返回多慢，都不会卡 Emacs.

最终还是回归到设计问题，我真的忍受不了启动卡一下，补全会卡，而且默认一大堆乱七八糟的功能， 为什么 VSCode 更多功能，一点也不卡？ lsp-mode 要劝说用户去关闭功能才能性能好？这不是在回避设计问题吗？

5 个赞
70

因为还是不够快啊 :rofl:，虽然和 IDE 的一样强大了，但是对比下主要竞争对手 vim/nvim，还是要慢上不少的。

emacs/vim 等轻量级编辑器（虽然 emacs 也可以重量级），仍然是许多通用/动态语言开发者的首选，或许最紧要的需求就是补全了，而且速度要快，不然可能就跑去用 ide 了…

71

我只是按照这个修改了下配置： Performance - LSP Mode - LSP support for Emacs (emacs-lsp.github.io)。感觉目前够用。觉得功能太多就试试eglot，用得人也不少。如果有更快的当然更欢迎。功能和性能总是矛盾的，就像我不用VSCode一样，就是不想开一堆node进程 :joy: 话说，用Emacs不就是为了折腾么，前几天好像听说坛友游戏都戒了 ，哈哈哈哈

4 个赞
72

可以用eglot，甚至坛友的神作 citre，速度肯定够了。

73

不是说 lsp-mode 开发者的能力不够，而是 Emacs 本身没有环境支持超高性能的补全方案。

但是不认同你的这几楼回复：

  1. 说lsp-mode性能不好：回答去关闭 lsp-mode 的选项
  2. 说lsp-mode功能臃肿：回答 eglot 功能也挺多
  3. 说速度：回答用 eglot 或者 citre

为啥没有一个插件默认就可以实现补全速度流畅、打开文件不要卡一下、核心功能精简够用呢？ :joy:

4 个赞
74

卡一下其实挺不合理的，electron 底层用的是 nodejs 但是开启大型的项目却一点都不会卡（补全等功能会等待一段时间），我猜这完全得益于 V8 的异步协程实现，开启 lsp 的后端按道理根本不需要做成同步的。

75

lsp-mode 还是会卡的，就算关掉很多东西，项目的文件打开多了或者久了之后，补全都卡卡的。这里面不确定是 lsp-mode 的问题还是我自己的一些其他配置的问题，但 lsp-bridge 是值得期待的，因为 vscode 我也会用，明显目前 emacs 的补全体验是不如 vscode 的😂

76

eglot 是可以不卡的，但是 over tramp 时还是同步的

77

对我来说代码跳转是用的最多的（定义，引用，接口实现，或者实现了哪些接口）， citre 不错但是正常情况下没法跳转到第三方包中。

代码补全大部分时间都当拼写检查了。

78

像 VSCode 那样远程补全，可以直接把代码、lsp server和 lsp-bridge 都部署到远程主机，然后 lsp-bridge 和 Emacs 本地客户端用 WebSocket 长链接保持通讯，应该也可以实现 VSCode 那样流畅的远程代码补全体验。

79

ctags机制确实无法跳转到第三方包，这就是lsp的优势了。

80

我觉得你没看懂我的意思。我说lsp-mode对我而言性能够用，没说性能很好。除开多线程多进程的Emacs自身的局限，很多说性能不好可能是由于一些配置（比如gc-cons-thredhold，read-process-output-max等）导致，这些配置在wiki中有详细描述，修改后体验会有大幅提升。同时，我没有回答eglot功能也挺多。我只是简单试用过，速度还不错，功能不符合个人需求。如果lsp-bridge能做到极致我当然更欢迎，不过可能还是rust或者C来性能更靠谱。推荐用citre，是回复 xdash-bw 的需求。按照坛友的需求用citre就好了，功能越多性能越差，从大的纬度上讲这个几乎是没法避免的。个人做个取舍就好了。就好像多数人认为vim比emacs快，C++比Java快，从底层一开始就避免不了，但是硬件弥补了很多gap，所以现在emacs和java依然很成功。

5 个赞
81

OK、OK， OK