会切换到 yasnippet 还是有点怪的， 毕竟第二次内容也和第一次候选词不一样。
手速太快， 选择第二个确实容易触发， 虽然不影响补全， 但是有可能会导致思维被影响了， 第二个问题我想想。
停留在 snippet 的问题不好重现是只有你上次确实是匹配 snippet， 然后删除字符后， 匹配上次 snippet 就会跳到下面去， 只是你会误认为是输入字符会乱跳， 我一会想想怎么避免删除字符的问题。
手速快的问题很矛盾， 因为 LSP 一直都在根据它理解的上下文进行候选词排序， acm 能够保证两次补全排序不一样时， 上次候选词不要换成第二次候选列表的第一个， 但是保持候选词在输入过程中一直都是第一个选中很难做到的原因是LSP补全过程中， 第一个候选词在中间补全过程中可能不存在。
比如LSP总共返回了3次候选词， 第一次和第三次都有 score_a 这个候选词， 第二次没有， 所以 acm 延续上次选中候选词的算法就会断掉。
这个逻辑你只能反复读了， 确实是实验后的结论。
你反馈的问题应该修复了 Adjust the selection position of candidate when typing fast. · manateelazycat/lsp-bridge@3c17517 · GitHub
LSP服务器返回候选词的顺序确实没法预测， 同时平常写代码的过程中第一个选择的候选词经常在变， 不是一直都存在的， 这种情况下， lsp-bridge 很难保持选中的候选词位置相对固定。
新的算法换了种思路， 只针对手速特别快的三种情况进行动态调整：
- 候选词的位置从第一行变成第二行时， 交换候选词列表前两个元素的位置
- 候选词的位置从第二行变成第一行时（候选词补全的同时快速选择了第二个）， 交换候选词列表前两个元素的位置
- 候选词的位置前后都是第二行时（候选词补全的同时快速选择了第二个）， 不交换候选词列表， 但是在最新的候选词列表保持选中第二行
这三种算法能够很好的处理手速快的问题， 也避免引入新的问题。
2 个赞
这个可以，因为候选词默认不选择第一个，我个人感觉挺反我的使用直觉的。
对， 其实就是把一些简单的例外情况， 强制做一下位置交换， 因为手速快一般就是前两个元素的位置在变。
人是很难在两次LSP补全计算之间可以选择到第三个候选词， 除非某种语言的服务器计算特别慢。
哈哈哈，今天写了公司的项目，之前的那些问题在我3个小时的中强度压榨下，没再出现过了。
不过gopls 这东西是真的占内存，现在已经占用6个G。难怪感觉有的时候卡卡的。
1 个赞
感谢强力测试， lsp-bridge 遭遇更多极限测试， 代码也会更健壮。
1 个赞
你这个看着像tempel后端的问题，你把tempel先禁用对比看。
很多用户都测试过，所有平台都很流畅。
实锤了，关了以后快了好多的说
(setq acm-enable-tempel nil) ok!
那这个后端写的还是不行，我要看看问题再哪里。
void-function 我是win10 ，是不是因为这个卡的
啥是void-function?
反馈要全，不要说一半。
你卡的时候用emacs -Q对比试过没？
真的，我关了acm的 templ特性。立马就跟acm刚出来的时候一样丝滑了。我还奇怪怎么最近acm好像变卡了呢。
1 个赞
不过templ是默认开着的，我没有任何的templ的代码片段
没有执行，但是我知道关了以后超流畅 
因为不用templ所以 
主要是没有装 tempel 的时候 (ignore-errors (require 'tempel)) 这个比较慢
那就是了，我是没有安装tempel的