麻烦问下，我昨天安装了，发现这个版本好吃cpu，我用触控板滑动几页cpu很高，风扇狂转，有好的建议么！
我自己使用没有问题的，可以试试其他的仓库的，github 搜索关键字 emacs mac。
我没法重现这个问题。
好的，我再试试
我这边就是执行lsp-bridge-code-action 这个命令后导致补全失效，
目前，执行它后，会导致，所有的lsp-bridge*命令都不能正常工作，没有任何错误信息。
只要执行了，就会出问题，比如跳转定义什么的，都不生效了。只有lsp-bridge-restart-process 才恢复正常。
大佬，我发现一个问题，我打开一个文件，没有进行输入，只是滚动 lsp-bridge会去调用lsp服务！这个可以优化成，只有输入的时候再去调服务吗？
目前的方案会提前启动好 lsp server, 到你真的输入的时候会直接补全。
滚动应该不影响你的操作呀， lsp-bridge 是完全异步的。
暂时不影响的，就是滚动越快node消耗cpu好高，风扇狂转，估计和我电脑也有关系吧= =！
lsp-bridge-code-action 这个问题和你覆盖是两个问题吧？
问题是两个， 但是目前发现都是执行它导致的。 两个问题：
- 移动函数最后，提示一个补全输入回车后，会覆盖至结构 =xxx{} 等号那里。
- 其他lsp-bridge* 失效，比如跳转定义，补全也不会正常工作
你可以给 lsp-bridge-call-file-api 函数加一个打印消息， 看滚动的时候是不是在发送请求给 lsp server ?
覆盖的问题我没法重现， lsp-bridge-code-action 导致后续命令失效的问题我确实遇到了。
这个应该是更新 lsp-bridge 没有重启 Emacs 导致的， elisp 和 python 两边 API 不一样， 重启应该就会好。
好的，可以了
为啥我lsp-bridge-loopup-documentation 会导致我的frame放大
emacs -Q 测试了吗？
lsp-bridge-code-action 执行失效的时候， 我用了 “gopls”, “serve”, “-debug”, “0.0.0.0:8484”, “-rpc.trace” 作为参数， 发现 第二次 code-action 的时候 gopls 并没有针对 textDocument/codeAction 返回消息， 通过 http://0.0.0.0:8484 可以看到 gopls 的内部日志。
感觉是 gopls 自己的bug呀， 其他服务器暂时还没有发现这个问题。
我刚试了，滚动是发送请求了，可以优化吗?
发了什么请求