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

manateelazycat · 2022 年5 月 9 日 15:56

可以，欢迎提交PR

guanghui.qu · 2022 年5 月 9 日 16:12

fix void function reduce by zilongshanren · Pull Request #17 · manateelazycat/lsp-bridge · GitHub 提交了。

速度贼快，ui优化一下无敌了。

目前有个问题，当前buffer lose focus时没有 destroy frame，会把frame带到别的buffer去。

guanghui.qu · 2022 年5 月 9 日 16:14

(add-to-list 'load-path "~/Github/lsp-bridge")
(add-to-list 'load-path "~/Github/lsp-bridge/completion/")
(add-to-list 'load-path "~/Github/lsp-bridge/core")

我要多加几个load path才不报错，不知道为啥。。

manateelazycat · 2022 年5 月 9 日 16:18

因为有三个 elisp 文件分别放到这几个子目录里面。

manateelazycat · 2022 年5 月 9 日 16:22

我把 *.el 文件都移动到外面吧，方便用户添加 load-path

guanghui.qu · 2022 年5 月 9 日 16:23

嗯嗯，这样方便点

manateelazycat · 2022 年5 月 9 日 16:24

换了 lbcf.el 应该和 VSCode 的补全速度有的一拼了。

manateelazycat · 2022 年5 月 9 日 16:28

没有重现你的问题，但是盲加了一个补丁，应该可以修复

manateelazycat · 2022 年5 月 9 日 16:28

已经修复了。

manateelazycat · 2022 年5 月 9 日 18:22

目前 lsp-bridge 已经支持十种编程语言。

目前还剩补全菜单UI美化、引用跳转、文档查看三个功能了。

感谢大家这几天贡献的补丁。

zerol · 2022 年5 月 9 日 22:30

我的想法是，虽然没法兼容 company 的 backend 的接口，但 frontend 还是可以的，这样就能少造轮子，自动获得了好用的 TUI 和 GUI 的补全界面。

我先试着接一下 company-box

zerol · 2022 年5 月 9 日 23:01

很有希望（目前只需要小改两处 company-box，还需要解决一下图标和 annotation 的问题

manateelazycat · 2022 年5 月 9 日 23:07

加油，干脆直接fork company-box代码，你先都用一个图标和统一的备注，接口我一会来弄

guanghui.qu · 2022 年5 月 10 日 00:36

clangd 的lsp-server会报一个错：

BrokenPipeError: [Errno 32] Broken pipe
Exception in thread textDocument/didChange:
Traceback (most recent call last):
  File "/usr/local/Cellar/[email protected]/3.9.12/Frameworks/Python.framework/Versions/3.9/lib/python3.9/threading.py", line 973, in _bootstrap_inner
    self.run()
  File "/Users/lionqu/Github/lsp-bridge/core/lspserver.py", line 159, in run
    self.process.stdin.flush()
BrokenPipeError: [Errno 32] Broken pipe
Exception in thread textDocument/completion:
Traceback (most recent call last):
  File "/usr/local/Cellar/[email protected]/3.9.12/Frameworks/Python.framework/Versions/3.9/lib/python3.9/threading.py", line 973, in _bootstrap_inner
    self.run()
  File "/Users/lionqu/Github/lsp-bridge/core/lspserver.py", line 131, in run
    self.process.stdin.flush()
BrokenPipeError: [Errno 32] Broken pipe

manateelazycat · 2022 年5 月 10 日 00:42

帮我提一个 issue 吧，论坛上太多信息会漏掉，谢谢！

manateelazycat · 2022 年5 月 10 日 01:27

大佬，好改吗？要不先推送一个版本？

zerol · 2022 年5 月 10 日 01:42

在搞了在搞了，一小时内给个 draft PR

manateelazycat · 2022 年5 月 10 日 01:47

哈哈哈哈，好吧，我先放弃我魔改 corfu 的方案了。

aqua0210 · 2022 年5 月 10 日 02:12

之前 cape 也讨论过如何在 Corfu 上支持异步，不过目前也还没实现。

github.com/minad/cape

Idea: Async CAPFs = ACAPFs

opened 08:54PM - 22 Nov 21 UTC

closed 06:02AM - 06 Dec 21 UTC

jdtsmith

I see you have as a TODO supporting company's async-flavoring. An interesting i…dea is to extend this to vanilla CAPFs as well, with a simple extra `:async` property, to make... async-capf's or ACAPFs. The idea would be to extend the CAPF mechanism to allow it to return (if it thinks it can eventually complete something there) a null table, but include an `:async callback-receiver` property in the return: ``` (list start end nil :async callback-receiver) ``` This would "break nothing" for non-supporting UIs (though you'd get no completions). A supporting UI would pass the `callback-receiver` function it receives its _own_ (unique!) callback function — a function which will accept just one argument: `capf-result`. The unique callback could be for example a closure that includes a request-id or some other disambiguator, so the UI knows which request is giving it results. When the ACAPF eventually has some candidates (from a process or remote server, say), it can _complete_ the CAPF operation by calling this callback with a regular CAPF response (``(funcall callback `(,start ,end ,table ,@extra-props))``), and then everything proceeds as a normal CAPF would have. The `table` could be a function (if it wants to specify some metadata and do something fancy) or just a simple collection, like always. The UI can either drop this request if the buffer has in the meantime changed, such that the completions are "no longer relevant", or pop-up the UI, if they have arrived "in time". Or a UI could allow the ACAPF to itself make that call in its table function (e.g. if the original region text includes a prefix of the current probe text), and only provide "relevant" completions. I'd suspect the former would be more robust. To support both async-capable and "regular-old" completion UI's, the CAPF-author could wrap the async CAPF with a simple "polling" wrapper which supplies the ACAPF its own simple callback, and polls for completion (with timeout), before returning the full `capf-result`, seemingly synchronously.

manateelazycat · 2022 年5 月 10 日 03:11

如果基于 lsp-bridge 的设计，补全整个流程应该这样设计：

根据不同的后端名字，创建一个 backend / completin_items 的字典
每个后端自己去更新字典的内容
后端更新内容以后， company / corfu 重新加载字典的内容， company / corfu 就不要管什么时候触发补全，什么时候更新内容

这样做可以做到完全不卡顿 Emacs ，company / corfu 现在的设计还是受限制于 Emacs 的单线程性能。