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

Emacs-general
853

win10系统下支持吗，比如用jdtls

854

应该支持，有开发者就在windows上写java

1 个赞
855

我的理解是调用 exit-function 之前补全已经被插入了，exit-function 只是把补全的内容删除了然后又插入了一遍（如果是 snippet 的话就展开），而服务端想的是在插入补全选项前删除它返回的 start 到 end 的内容，然后在插入补全选项。更改 exit-function 中的 delete-end-pos 是不行的，这个时候补全已经被插入了，这就造成已经插入的补全只会被部分删除，然后又插入了一次补全。不知道对不对。

856

不是这样的。

现在是补全前端会在 exit-function 的时候插入 label, lsp-bridge 会根据服务器返回的 textEdit range 删除已经插入的 label, 然后再插入 textEdit 带的 newText ， 最后用 yas 对 newText 的内容进行展开。

简单说就是删除 label, 插入 newText 最后展开，他这个两个 > 的原因未知，但肯定不是 先展开再删除 。

857

那不知道为什么按照服务器返回的 range 并不能完全删除已经插入的 label，而实际范围是 start 到 (point)

我是直接把 exit-function 删了，看还能能补全。所以我就觉得代码中的

;; Insert candidate or expand snippet.
(delete-region delete-start-pos delete-end-pos)
(funcall (or snippet-fn #'insert) insert-candidate)

是把补全删了再插入一遍。

858

我看了下服务器回复，不管怎么做也达不到目标啊。 这个是在 <std|> 这个地方触发的，range 里面 start 和 end 只管了 std 这三字符，是说把 std 替换成 stdio.h>, 而原先本来有的那个 “>” 是没有删除的。如果他的 end 包含了最后那个 “>” 是应该可以的。但是现在这样的补全和 <std| 返回完全一致的。所以说起来可能还是 server 返回没考虑到后续重复字符吧。

{
            "filterText": "stdio.h>",
            "insertText": "stdio.h>",
            "insertTextFormat": 1,
            "kind": 17,
            "label": "stdio.h>",
            "sortText": "3f800000stdio.h>",
            "textEdit": {
               "newText": "stdio.h>",
               "range": {
                  "end": {
                     "character": 13,
                     "line": 11
                  },
                  "start": {
                     "character": 10,
                     "line": 11
                  }
               }
            }
859

其实比较好的办法就是不要开 < 的括号补全插件。

860

他前面描述的操作看起来是 yasnippet 干的。我记得里面有个 inc 的 snippet. 其实同理还会出现 #include 双引号的问题。

861

现在还没时间调研这个，哪位大佬发现原因，欢迎PR.

我今天晚上专门给 lsp-bridge 写一个高性能诊断前端 （避免使用庞大的 flycheck/flymake, 同时兼顾诊断性能）

4 个赞
862

我这里遇到一个问题，我在 home 目录下创建一个 1.py 文件，可以补全，但当我保存这个文件的时候，文件被保存到了 /tmp/!home/!xxx/!1.py 这样的路径下面，请问这是设计如此吗？

PS：又多试了下，不论在什么路径下，保存文件时都会保存在 /tmp/!home/!xxx/*.py 这样的路径下面。

863

这个明显和 lsp-bridge 没有关系，请 emacs -Q 先排查一下自己的配置文件，再报bug

864

贴一下我导出的日志，Eval in Emacs: (lsp-bridge--first-start '42593)(AutoLog) Called: ThreadingEP - Pastebin.com

4325 行开始开始，补全发起是从

"position": {
  "line": 0,
  "character": 13
},

后面接收到的补全的 range 结束是

"end": {
  "character": 14,
  "line": 0
},
865

你这个看起来好像确实是 range 的替换没处理好。我的 clangd 版本是12， macos 自带的，我这装其他版补全一直有点问题。

我看了下代码。你试试把这行改成提取 end-pos 再试试？好像它直接取的当前 (point) 位置了。

866

我这里使用最小配置，仍会出现同样的问题。复现的步骤 1. 任意路径下创建一个 py 文件 (单文件或某个项目下） 2. 启动 lsp-bridge-mode 3. 键入一些内容，然后保存。文件就会被保存到 /tmp/!home 这样的路径下。

867

试过了，像上面说的，这样只会不完全，删除已有的内容，还会插入新的内容。

868

你不说我还没在意，今天用 Python 的时候也出现了这个问题。刚试了下，的确有这个问题。

869

我输出看了下， start-pos 和 end-pos 都变成一样的数值了。(point) 是正常的。所以本应该删除的，没有删。我看能不能查到问题。

1 个赞
870

我目前重现不了，我天天用

871

大概知道问题了，不过处理好像有点麻烦。比如你这个，需要记录开始补全的 position，然后和补全得到的 range 对比。如果补全位置和 end 不相等，需要把 delete-end-pos 里面的差值加进去，出问题的时候就是 range 里面的 end 比补全 position 更大的时候。

至于为什么改 end-pos 那段没用，是因为插入 label 时候其实整个context 已经变了。还只记录之前的 range 肯定没用。

872

估计是 Fix issue #152 , not always send textDocument/completion request. · manateelazycat/lsp-bridge@8d19f83 · GitHub 这个补丁的原因，这个补丁做了缓存处理，导致 range 的值比较旧。

你把 fileaction.py 的 try_completion 的那些条件都去掉看看会不会就好了？