你要研究 typescript-language-server 的文档, 我不知道啊。
我给 typescript language server 提了 issue:
想要尽快解决问题,当然是报给最熟悉相关代码的人,一直在这里讨论很难有什么实质进展。
1 个赞
其实 typescript-language-server 没错,它返回的结果是完整结果,也就是 isIncomplete: false
,即 this.
和 this.i
补全项相同。
可能目前大多数所用的 ls 返回结果都是 incomplete,所以 lsp-bridge 显示正常,因而鲜有人报 bug。而 lsp-mode/eglot 上有前端过滤,所以 isIncomplete
是啥也不影响用户。
我测试了几款 ls,情况如下:
server |
isIncomplete 值 |
实际结果集 |
结果符合预期 |
lsp-bridge 显示 |
pyright |
True |
incomplete |
符合✅ |
无多余的项 |
pylsp |
False |
incomplete |
不符 |
无多余的项 |
jedi |
False |
incomplete |
不符。可能传染给了 pylsp |
无多余的项 |
gopls |
True |
incomplete |
符合✅ |
无多余的项 |
rust-analyzer |
True |
complete |
不符 |
有多余的项🐞 |
typescript-language-server |
False |
complete |
符合✅ |
有多余的项🐞 |
solargraph |
False |
incomplete |
不符 |
无多余的项 |
所以我认为 lsp-bridge 也需要处理一下这个问题。
首先我试着在 completion.py 中过滤补全项,但是发现 lsp-bridge 会缓存上一次请求的结果,因此在 completion.py 中过滤会有漏网之虞:
- 输入
self.
(所有补全项已缓存)
- 按
C-g
关闭补全菜单
- 按
i
激活补全
此时 lsp-bridge
会先从缓存读取补全项(所有),然后再向 ls 发起请求,得到符合 self.i
的补全项。
所以改为在 acm/acm-backend-lsp.el:acm-backend-lsp-candidates
中过滤。
这是我的修改 (鉴于目前发现存在 language server 错误标识 isIncomplete 的情况,所以一律对补全项进行过滤): Filter lsp completion · twlz0ne/lsp-bridge@ac5b1ac · GitHub
1 个赞
大佬测试这么多语言, 很严谨呀!
但是我强烈不建议在 Elisp 端做过滤, 因为像 volar 这样的变态 LSP Server, 它最多可以返回上万条的候选词列表, 如果在 Elisp 端做任何过滤, 都有可能导致用户输入一个字符就要对一万条候选词做Elisp模糊匹配, 最终结果是用户肉眼可见的前端补全 frame 卡顿。
大佬说的缓存的问题, 不应该存在啊, 因为 acm 菜单关闭后就会调用 acm-backend-lsp-clean lsp-bridge/acm-backend-lsp.el at fc7384d2850ad580fc32ecb490333fb4438cc099 · manateelazycat/lsp-bridge · GitHub 默认清空LSP返回的候选词列表, 是不是大佬的 acm-terminal.el 没有做 lsp-bridge/acm.el at fc7384d2850ad580fc32ecb490333fb4438cc099 · manateelazycat/lsp-bridge · GitHub 这个操作呀?
大佬, 有空还是把 acm-terminal.el 合并入 lsp-bridge 分支呀, 我改啥API的时候就一起帮你改了, 两个人干活搭把手。
1 个赞
大佬辛苦啦, 大家都很期待 acm-terminal.el, 我水平不够, 一直没有把 overlay frame 搞定。
我感觉老王喊人“大佬”就跟其他人喊“兄弟”一个意思。