你要把选项 lsp-bridge-enable-log 打开再收集一次日志。
还有就是你是GUI还是Terminal？
我实现了这个功能，可以用这个分支测试一下 ，只支持 clangd
xhcoding/lsp-bridge at feat/render-preproc (github.com)
用法：
(require 'lsp-bridge-semantic-tokens)
(lsp-bridge-semantic-tokens-render-preproc-enable)
如果不想自动，也可以手动调用 lsp-bridge-semantic-tokens-render-preproc
效果 ：
大佬，可以提交一个pr。
我想试试的，但是小白不会配置langserver的project root, 我的C语言项目目录结构是下面这样的，.git和compile_commands.json不在同一个目录下，包括compile_commands.json里面写的路径都是相对于sdk内部的，lsp-mode在第一次打开项目的时候可以让你选择哪个是源码目录，此时我选择了sdk，然后ccls一切正常开始索引解析。 用lsp-bridge的时候不知道如何指定这个sdk……导致lsp报找不到头文件，各种解析都不正常。
.
├── .editorconfig
├── .git
├── .gitignore
├── docs
└── sdk
├── library
├── apps
├── compile_commands.json
└── Makefile
好的，有空的时候再采集一次。我用的是GUI，试过Terminal也一样。
我再用一下，没有问题就提PR
1 个赞
lsp-bridge 可以设置 lsp-bridge-get-project-path-by-filepath 自定义获取 project 的方式
(defun my-get-project-path (filepath)
(let ((project-root (nth 2 (project-current))))
(expand-file-name "sdk" project-root)))
(setq 'lsp-bridge-get-project-path-by-filepath #'my-get-project-path)
这个补丁只支持 clangd
我看了一下补丁， 如果是实时获取 LSP 返回的 tokens， 要注意 Emacs 的 GC.
Emacs 的GC现在很脆弱， 如果你在很短时间内快速创建上千个对象， 它就会立即介入， 一旦GC介入， 就会导致很卡。
所以如果要渲染 LSP Tokens， 建议在 Python 端缓存最新的 Tokens, 然后监控 Emacs 的滚动， Emacs 滚动的时候再动态获取屏幕区域内的 tokens 做动态渲染。
因为每个用户的屏幕大小是固定的， 这样可以把 Tokens 性能从根据文件大小相关降低到和屏幕大小相关的常量性能， 具体的做法可以参考 lsp-bridge 在诊断信息缓存上的设计。
主要看日志， 如果 lsp-bridge python 端返回补全， 就要看是不是 acm 的问题或者其他插件的干扰。
首先要知道是 LSP Server 参数还是 lsp-bridge 后端或者前端的问题。
1 个赞
好的，我按照这个思路优化一下，每次更新只处理在屏幕内的行
1 个赞
提交了一个 commit，python 端在响应的时候先获取 emacs 当前窗口显示的行的范围，不在这个范围的 token 都丢掉，然后再让 emacs 更新
1 个赞
我的理解是， 只要编辑过文件， LSP Server 会实时计算新的 Tokens, 所以我的代码改进建议是：
所有Tokens记录到Python端存储下来， 这样用户只是滚动 Buffer 的时候， LSP Server 应该不会重新生成新的 Tokens, 这时候可以从Python存下来的数据中获取滚动后窗口范围的Tokens再取回来渲染。
如果直接丢弃，滚动Buffer后就没法渲染Tokens.
获取 Tokens 需要客户端请求，不像诊断信息由服务端 publish 过来，不好做缓存。 现在就是 emacs 这边每隔 3s 请求一次，然后 python 端根据情况决定要不要让 emacs 重新渲染
如果是主动请求，可以加个判断，3秒并且文件修改后才发请求，避免文件没有变动也一直向LSP SVERSER发请求。
大佬，我的doom还是配不好……按你说的配置之后看上去已经启用了，但是很卡
你是不是吧log给打开了
也没有专门去开Log的，是哪里看呢？
这个选项 lsp-bridge-enable-log ， 除非你是 lsp-bridge 的开发者， 平常要关闭这个选项， 要不就会导致性能极度下降。
看上去是nil的，company, lsp 都在init.el里注释了, config.el也只加了这些：
(use-package! lsp-bridge
:hook
(python-mode . lsp-bridge-mode)
(c-mode . lsp-bridge-mode))
(unless (display-graphic-p)
(after! acm
(use-package! acm-terminal)))
(defun my-get-project-path (filepath)
(let ((project-root (projectile-project-root)))
(expand-file-name "sdk" project-root)))
(setq lsp-bridge-get-project-path-by-filepath #'my-get-project-path)
(set-lookup-handlers! 'c-mode :async t
:definition #'lsp-bridge-find-def
:implementations #'lsp-bridge-find-impl)
一些运行log:
--- [22:34:47.753216] Recv textDocument/signatureHelp response (42147) from 'clangd' for project sdk
ERROR:epc:ReturnError([Symbol('invalid-function'), Symbol('lsp-bridge--with-file-buffer')])
I[22:34:52.411] <--
--- [22:34:52.411197] Send textDocument/signatureHelp request (54223) to 'clangd' for project sdk
textDocument/signatureHelp(54223)
I[22:34:53.068] --> reply:textDocument/signatureHelp(54223) 656 ms
--- [22:34:53.068369] Recv textDocument/signatureHelp response (54223) from 'clangd' for project sdk
I
--- [22:34:57.077680] Send textDocument/signatureHelp request (53938) to 'clangd' for project sdk
[22:34:57.077] <-- textDocument/signatureHelp(53938)
I[22:34:57.752] --> reply:textDocument/signatureHelp(53938) 674 ms
--- [22:34:57.752547] Recv textDocument/signatureHelp response (53938) from 'clangd' for project sdk
I[22:35:25.567] <-- textDocument/signatureHelp(16315)
--- [22:35:25.567085] Send textDocument/signatureHelp request (16315) to 'clangd' for project sdk
I[22:35:26.165] --> reply:textDocument/signatureHelp(16315) 598 ms
--- [22:35:26.165874] Recv textDocument/signatureHelp response (16315) from 'clangd' for project sdk
[LSP-Bridge] Start LSP server (clangd) for /home/dark/xxxxx/sdk...
[LSP-Bridge] Start LSP server (clangd) for /home/dark/xxxxx/sdk with ’project’ mode, enjoy hacking!
看来只能继续努力学习elisp一段时间后再来折腾了
使用ruff做lsp-bridge-code-action的后端， 能够弹出menu，但是按TAB也好按Enter也好都没有反应。有人遇到过同样的问题吗？