详细说一下吧，没看懂。
原来因为所有项目混合在一起的，所以怕重名，现在按照项目 hash 分目录了，已经做了文件存在就不在写入反编译内容了。
更新一下，应该好了。
1 个赞
能详细给一个重现的文件给我不？
别理他们吧，我觉得评论的人根本就不懂多线程，更多是基于自己的有限的认知和偏见在讨论。
他们用过 lsp-bridge 就知道什么叫流畅了。
1 个赞
现在的问题是，不管是 corfu-insert (回车）还是 corfu-complete (TAB) 都会调用 capf 的 exit-function , 而且 status 都是 finished, 从 capf 的角度看，无法区别 corfu-insert 和 corfu-complete.
而 volar 在你输入 v-if 的时候确实会要求 LSP Client 进行模板展开，目前看不是 lsp-bridge 的问题。
正确的处理方式是， corfu 要提供两种补全方式，一种是只是插入 label, 一种是扩展 textEdit 的内容。
这个问题已经被下面的补丁修复了
原因是 corfu 会过滤 label 是一样的候选词， 而 volar 其实是返回两个 v-if 的候选词，一个是 Value 类型的，一个是 Emmet 类型的，因为 label 一样被 corfu 过滤掉一个。
上面的补丁看到是 Emmet 类型时就在 label 后面加了一个空格，让两个 v-if 都可以显示出来， 正常补全 Value 类型的 v-if 会展开成 v-if="xxx" 的形式。
有个评论挺搞笑的，他觉得emacs不应该有多个别的进程来保证编辑的流畅度，问题lsp就是别的进程，而且根据需要还要多开 
1 个赞
Emacser 里面真正懂图形编程和多线程原理的很少吧，评论看看就行了，到底快不快，大家对比用一下 lsp-mode/eglot/lsp-bridge, 大家会用脚投票的，哈哈哈哈。
5 个赞
reddit 里确实还是在用脚投票的，得票第一的评论还是认为虽然项目在初期，还是对得起 fastest 这个称号的，并且鼓励大家做贡献。偏见的言论基本上被沉下去了。
大佬加油，我先不打扰了 
服务端通常会有完整的语义表，因此代价通常没有那么大。 另外LSP里有range的协议，只需要为窗口中可见的部分提供高亮。
但是关键的是Emacs实时的做语法高亮会很慢, 一是 elisp 端性能和渲染很慢，而是过多的对象会触发GC操作，最终效果就是滚动的时候会感觉到卡手。
比较看好的方式是， tree-sitter 合并到 Emacs 分支后，Emacs内在的语法高亮就用 tree-sitter , 不要两套 tree-sitter 和 font-lock-jit， 这样性能会好很多。
你好，我是 lua 语言服务的作者。要是能早点发现这个帖子就好了，LSP协议相关的问题都可以问我，我一直有在跟进。
14 个赞
大佬好哇，这个项目是五一节才开始研发的，发布才两个星期，以后多向大佬请教。
太强啦！又修复一个由于volar带来的补全bug。我这边更新后能正常使用了！
感谢反馈， volar 的bug我感觉还没完, volar 绝对是测试 LSP 协议健壮性的最佳测试程序，哈哈哈哈。
我刚刚爬了一遍楼，按照记忆回复部分问题哈（要是问题已经被解决了那更好）
-
CompletionTriggerKind = 1的情况是用户手动触发补全（默认快捷键是 ctrl+space），一般vim用户会关掉自动补全，然后需要的时候手动补全。 - Windows上的协议换行符问题我之前也遇到过，我的解决方案是使用二进制模式打开标准输入与标准输出，这样Windows就不会转义换行符了。
- completion协议服务端回复的 isIncomplete 参数表示是否期望客户端自己补全。因为一般来说补全的代价非常巨大（补全通常是输入触发的，而输入会修改文件内容导致需要重新解析语法），所以客户端应当尽量不询问服务器的补全。
1 个赞
明天写volar时说不定还能碰到潜在的问题，我会把怪异的行为都录下来及时反馈。 
