Eglot 这个最新的 commit 应该已经解决了你的问题。
恩，我刚才试用了一下，没有出现问题了。可以从 lsp 迁移到 eglot 了。
1 个赞
今天试了一下windows下面的lsp和eglot，都很卡，没法用。尝试了各种优化方案都没用，gcc emacs也没用。准备试试Nox，如果不行，windows上面只考虑tags方案了
这个速度也和 lsp server 有关吧。nox 是基于 eglot 改进的，差别应该不会特别明显?
很明显,nox去掉elgot很多影响性能的功能。请看前面帖子
嗯嗯，我最开始一直用的 nox，就是之前遇到我上面说的问题，在 nox 和 eglot 下面使用 pyright 都会报相同的错误，就只好转到 lsp。当时我把问题报到了 eglot 的 issue 下面，最近给 fix 了。
感觉windows下面还是不太流畅， ctags + citre速度太快了
eglot 什么时候能支持多个后端就好了，我现在就是因为需要额外附加一个 TailwindCSS 后端，不得不使用 LSP
试了一下补全用 ctags, 跳转定义，imenu, refactoring, find-reference, 语法检查用 lsp，windows下面编辑 Unity项目很完美，后面搞顺了再分享一波设置。
项目 c#代码 40多万行代码， ctags文件 140M, 补全速度很快，没有使用 mysys2, cygwin或者 WSL，用的 emacs 29 (开启 nativecomp)， GUI版本
6 个赞
确实很明显。nox完全不卡。lsp/eglot都卡的不行。
windows下配合msys2会好一些。也还是不够流畅，但没有到卡的地步。
期待学习配置。
Windows 下面卡主要是 flymake/ flycheck，flycheck 查一次错误要等很久，如果项目大则更明显。
Nox 因为去除了 flymake 这个依赖，所以会感觉性能提升明显。
LSP 卡主要是进程 IO 数据太多了，像一个 vue 项目，光标随便动两下就有十几万条 io，本来 Windows 上 IO 就慢，emacs 又没办法在后台处理数据，所以就会一卡一卡的。
优化方案就是去掉一些功能，减少数据量
@manateelazycat 刚刚看到你在开发 lsp-bridge，发现是用 QApplication 写的，有点好奇，所以来咨询一下，是因为想复用 EAF 的积累，所以直接用了 QT + Python 吗？我看似乎主要是用 QThread？
还在实验中，主要目标是像vscode那样永远不卡手，多线程处理和补全ID对比是关键。
QT目的是提供现代的补全窗口，比如图标，左右对齐，周边留白，不那么脆弱的snippet管理等。
lsp各后端初始化参数都不一样，这个项目还很早期。
这个项目我也觉得很有意思，但是 QT 补全窗口这块感觉是不是可以单独抽离出来🤣 ，单独解决速度问题，感觉吸引力就很大了，QT 这个依赖也不算轻
1 个赞
先试验下原型，补全窗口可以按照popweb来实现，线程可以用语言本身的线程库。
现在的方案是，跨进程通讯，图形库和线程库pyqt都有，不用装几个包。
QT作为跨平台库，各平台都很容易安装，分散实现用户配置也很麻烦。
这个项目的最初目标就是让补全不要卡手，对标vscode体验，欢迎大家一起开发。
2 个赞
对，我基本能理解你的思路，而且之前有 EAF 的积累，直接用 QT 搭个原型确实比较快。
就像你说的，补全窗口和 lsp 也可以分开做，定义好接口，后续也能组合着用，至于配置，反正该有的配置都会有，只是在一个地方还是两个地方，应该也还好。
lsp 现在确实太多冗余信息了，有机会我也可以看看能不能帮上忙
1 个赞
