你把选项 (setq lsp-bridge-enable-log t) 打开，看看你出错 KeyError result 之前服务器都返回了啥？
lsp-bridge commit: 9d8ead517fca3df9c74f79d729b57628975e021c (目前最新的） volar的日志：
第一步，触发补全命令（输入了 “<”， reqeustId: 35261），表现是：
1. 读取了conten-length
2. skip empty line
3. 然后就没有消息了，我等了一会。
第二步，尝试再次尝试出发补全命令（输入“<x”）,表现是：
1. requestId: 35261 的结果返回了
2. 读取了 content-lenth
3. skip empty line
遇到这些问题我一般都先切回 lsp-mode 然后 ps 一下看看 command 到底是啥 
所谓 skipped region 是不是 lsp 语法高亮的功能？有些 server 只简单的实现选中某单词高亮所有 occurance，而 clangd、ccls 这类高亮某个区域？
目前只有volar这个server有这个情况，原因未知，暂时还不知道怎么修复。
不晓得呀，还没研究，我个人不是很想加这种语法高亮功能，一来容易把emacs jit-font-lock 搞挂，二来容易有性能问题卡手。
1 个赞
以及这个clangd的 issue Grey out code in inactive preprocessor branches · Issue #132 · clangd/clangd · GitHub
应该是可以只处理未激活代码部分的，再返回给Emacs
先把debug关掉。。。这个buffer内容太多是容易卡住补全啥的。
盲猜是这么个情况，是 lsp 协议的一部分。
搞挂 fontlock 应该不至于，不过高亮覆盖来覆盖去搞得有点乱倒是可能，看看 fontlock 有没有手动控制某区域这功能。但是还有 treesitter，得定义高亮优先级，多了很多工作。 
不是调试，不要打开日志，volar这个不是把lsp-bridge卡住了，而是光打印就把emacs搞废了。
先看看吧，lsp-bridge目标是高性能，凡是返回信息对emacs性能挑战很高的功能我都谨慎加。
智能辅助的前提是不能卡手，卡手就像lsp-mode一样，一点写代码的兴趣都没有了。
lsp 规范越搞越多了。按这个 textDocument_semanticTokens 情况，感觉以后 vscode 肯定不会集成 treesitter了，全部交给 server 端去搞高亮？
volar 这个很难搞。。。我感觉是返回 Content-Length 的长度比接收到的内容（可能中间有啥字符）长，导致没读取够，又没有读到 \n ，就一直 hang 在哪里了，毕竟其他的都好好的，总感觉是它那一坨返回内容里有问题
大佬，能不能有一个 lsp-bridge-find-def-other-window，类似于 xref-find-definitions-other-window
(if lsp-bridge-jump-to-def-in-other-window
(find-file-other-window filepath)
(find-file filepath))
是不是直接这么写好一些，窗口策略让 emacs 自己去根据用户策略来搞，还是说这么写有什么其它问题