加了这个选项 acm-backend-lsp-candidate-min-length， 默认是0
2 个赞
非常，非常感谢！
的确速度太快也有烦恼，比如有时获取不到当前项的文档。
概率还挺高，以下是重现步骤：
- 打开一个空白的 python 文件
- 输入
import os\nos. - 输入
path - 等待片刻，如果 doc frame 弹出，按
M-Del删除输入的 path，回到步骤3； - doc frame 没有弹出。
原因是获取文档的请求有时落后，候选列表更新几轮了，请求才开始执行，然而已经过时了，而新的请求又被阻挡。
我想我刚刚已经修复了这个问题，稍后发补丁。
6 个赞
lap-bridge 没有vscode流畅的原因会不会是因为每次候选词更新都会重新popup 出一个补全窗口。 我看了下vscode 和 corfu那边，输入变更的时候会尽可能利用已经弹出在界面上的补全窗口进行更新, 而不是先关闭再popup一个出来。
其实不会， lsp-bridge也会经常关， 而是后台数据太快了， acm会快速刷新。
如果只是从协议传输看， lsp-bridge和VSCode不会有消息级别的性能差别。
但是从图形绘制来说， Emacs本身的 frame 绘制肯定是没有浏览器或者Gtk/Qt快， lsp-bridge最早是用 PyQt 来绘制图形窗口的， Qt就会给人感觉界面刷新要快很多， 但是最后考虑 lsp-bridge 要带一个 Qt 没有必要就没弄。
那复用已经弹出的补全窗口呢
lsp-bridge/acm 就是复用的。
但是从我的经验看， Emacs这种自己造 frame 的代码，渲染效果就是没有 Gtk/Qt/Browser 快。
如果要比绝对图形性能， 只能拿EAF和VSCode比。
我的意思是，更新的时候不经过hide 再 show 而是 直接在已经显示的窗口更新
说实话，要是体验好，我是觉得加个qt也没关系
1 个赞
现在是这样的
可能是 Mac 的关系，频闪比较明显。 尤其是当补全提示窗口已经展示时，再一个一个删除刚刚输入的字符，闪烁会更加明显。
现在应该不闪烁了。
我把一些常规的向前删除字符的命令加入到 acm-continue-commands 中
这个版本macos 下acm不弹出了，没有任何变化，*lsp-bridge 文件也没有任何错误信息，已经回退到之前版本
1 个赞
我昨晚去看了下代码，应该是会复用已经显示的frame的。但是不知道为啥会闪烁。
应该是这里有问题， 加个not 就好了
(defun lsp-bridge-not-yank-command ()
"Hide completion if `this-command' is yank."
(not (string-equal "yank" (format "%s" this-command))))
可能跟mac版全屏工作区有关，要用这种方式启动emacs
确实是我的问题， 我一会修复一下。
更新了， 应该用 last-command 而不是 this-command , 已经修复了。
1 个赞
Elisp的解释性能不行， 而且数据超级大时（比如22万大小的列表） GC 也很慢。
今天用 Python 线程重写了 English 后端 Re-implement English backend with Python thread. · manateelazycat/lsp-bridge@dcf0e65 · GitHub
英文补全的体验直接从可用变成丝滑了， 推荐大家升级。
6 个赞
Python重写的好处是， 大家可以替换默认词典， 不一定要用 lsp-bridge 默认的词典， 甚至不是中英的词典， 具体用法如下：
-
acm-backend-search-sdcv-words-dictionary: 用于单词补全的 StarDict 词典， 默认是kdic-ec-11w, 可以自定义为其他 StarDict 词典， 如果你的系统存在词典/usr/share/stardict/dic/stardict-oxford-gb-formated-2.4.2/oxford-gb-formated.ifo, 你需要设置这个选项为/usr/share/stardict/dic/stardict-oxford-gb-formated-2.4.2/oxford-gb-formated, 不需要包括.ifo扩展