lsp服务有个capability的能力可以检测是否实现了这个功能来决定是否发送对应的请求
oldhu
124
从lap-mode的describe session看,eslint提供的能力确实很少,以下是eslint:
一个正常的ts language server就多了很多能力:
以上是对同一个文件同时启用两个lsp server的结果
3 个赞
lsp-bridge 是为了解决性能问题而创建的,尽量用完整功能的 lsp server 吧, 多个 lsp server 太折腾了
换一个思路,可以同时用 lsp mode 与 lsp bridge ,这样也能解决你的问题。
Bridge 专注在性能上,你这个场景不是它要解决的问题。
oldhu
127
嗯,是的。我个人依赖lsp server的跳转、错误分析和格式化,会持续关注这个项目。
1 个赞
kongds
129
试了一下lsp bridge,确实挺快的,不过好像无法补全缩进情况下的输入
应该是这里的completion_prefix_string
没有去掉缩进的空格,导致候选项全部filter了
还有种情况是行内插入空格,比如补全import tor,无法补全后续的输入,貌似也是因为completion_prefix_string
是“import torc”,导致补全选项也filter了。
反馈一个小问题。
LSP返回的路径中,可能有quote字符(比如@,quote成%40),需要unquote下。
lsp-bridge 支持 Haskell 语言了!
2 个赞
因为 lsp-bridge 是基于多线程来实现的补全机制,lsp-bridge 获取最新的补全列表后会主动 push 给Emacs, 完全避免 Emacs 卡顿。
Emacs目前主流的 company-mode 和 corfu 都是采用 async + callback 的方式,没法体现 lsp-bridge 的补全性能, 今天针对 lsp-bridge 专门写了一个 lbcf.el (lsp bridge completion frame) 补全前端, lsp-bridge push 的时候会主动调用 lbcf.el 来显示补全列表。
lbcf.el是新写的补全前端用来替代 company-mode , 目前还有诸多细节不成熟,欢迎大家一起改进。
5 个赞
zerol
140
主要底层机制不一样,倒不是前端样式的问题,魔改的估计会有一堆奇奇怪怪的bug
lbcf 里面用了 reduce, 好像缺库,查了下好像牵扯到 cl, cl-lib 什么的,我加了 (require 'cl-lib) 然后 reduce 改成 cl-reduce, 倒是可以用了,不过不知道是不是常规的改法。