报告一个问题： 今天在org-mode（估计和模式无关）使用english-helper，发现在窗口不是最大化的情况下，弹出的补全菜单有时会错位，超出窗口位置； 复现步骤：窗口不是最大化（我的窗口大约是屏幕的一般，但高和宽都不是最大化），开启english-helper，然后在行头的几个位置，输入modern这个单词，当输入mod三个字母时，弹出的补全菜单在窗口外，继续输入modern完成，补全窗口自动回复正常，在光标下了； 如果窗口最大化，则没有这个问题；感觉像是窗口在非最大化时计算位置有偏差； 并不是所有单词都会出现这个问题；我是输入modern时发现的；而且可以稳定复现；
大家也试试是不是有这个问题？
macOS emacs 29.0.50没有发现这个问题。补全菜单位置正确，没有跳动。
emacs -Q 先对比测试一下。
cargo 第一次 index 的时候会会很慢， 只要你加了依赖包， 和项目大小都不相关。
感觉应该是网络问题，网络环境是不是通畅？cargo 会拉 GitHub 的东西
考试回来一个下午了，还是卡在那里， 
@zwPapEr 手动编译一下还是这样诶
我发现问题在哪里了，我的项目结构是这样的
win10，emacs 29.0.50，问题依然容易重现，发现了两个单词，一个是modern，输入mod会出现，继续全部输入modern回复正常；另一个是master，即使输入完整了也不会回复正常； 但是如果是全屏，就不会出现问题；
今天又试了下，发现在elisp模式下没问题。看来还和模式有关？
每次编译之前 Cargo 默认应该都会拉一下 Index，手动编译不影响 LSP Bridge 用 Cargo 拉 Index 的部分，所以很可能 Cargo 一直在拉 Index 吧。
话说， @manateelazycat LSP Bridge 在拉 server 起来的时候，有没有传递 HTTPS_PROXY 之类的环境变量？
我觉得不是卡顿了，你看看我新的回复
要不要把acm拆出去作为一个单独的包维护？
是不是没有在main.rs里面引用这些文件？
lsp-bridge 不管这些吧， 自己配置工具可以用梯子或者用国内镜像吧， lsp-bridge 不能管太多。
没有必要啊， acm + lsp-bridge 威力才大， acm 本身只提供绘制功能， 不提供补全功能，和在一起好用， 用户安装了 lsp-bridge 就是开箱即用， 我不想拆开以后， 用户还要折腾两个包。
以前那些补全方案，要折腾一堆安装包， 多麻烦。
引用过了哦 。。。
你们的不会出问题吗?
dabbrev 对于非语义的补全非常方便，但是 dabbrev 的算法性能非常差，特别是当它搜索所有 buffer 并提取单词的时候非常耗性能， 再加上当前输入的关键字和所有单词做对比性能就更慢了，甚至会卡手。
今天实现了一个新的后端 acm-backend-search-words, 用来替换 acm-backend-dabbrev, acm-backend-search-words 后端的原理是， Emacs告诉 Python 进程哪些文件被打开了， Python 进程就开一个子线程在后台计算每个文件的单词， 并对提取的单词进行清洗、去重和排序。
当我们在Emacs输入字符时， acm-backend-search-words 会开启一个新的线程用于对比输入字符和所有单词， 只把匹配的单词返回给 Emacs 来实现 dabbrev 同等功能。
相对于 dabbrev 的优势主要有两点：
再也不用 dabbrev-expand 按到手抽筋了， acm-backend-search-words 对于写 elisp 代码超级爽。
我在Windows下，在python-mode 中打开lsp-bridge 会出现类似如下错误：
E:\Python39\python.exe .\testsubprocess.py
path: ['C:\Users\wcq\Desktop', 'E:\Python39\python39.zip', 'E:\Python39\DLLs', 'E:\Python39\lib', 'E:\Python39', 'E:\Python39\lib\site-packages', 'C:\Users\wcq\AppData\Roaming\npm']
Traceback (most recent call last):
File "C:\Users\wcq\Desktop\testsubprocess.py", line 20, in
subprocess.Popen(['pyright-langserver', '--stdio'], bufsize=DEFAULT_BUFFER_SIZE, stdin=PIPE, stdout=PIPE, stderr=stderr)
File "E:\Python39\lib\subprocess.py", line 951, in init
self._execute_child(args, executable, preexec_fn, close_fds,
File "E:\Python39\lib\subprocess.py", line 1420, in _execute_child
hp, ht, pid, tid = _winapi.CreateProcess(executable, args,
FileNotFoundError: [WinError 2] 系统找不到指定的文件。
把
subprocess.Popen(['pyright-langserver', '--stdio'], bufsize=DEFAULT_BUFFER_SIZE, stdin=PIPE, stdout=PIPE, stderr=stderr)
改成
subprocess.Popen(['pyright-langserver', '--stdio'], bufsize=DEFAULT_BUFFER_SIZE, stdin=PIPE, stdout=PIPE, stderr=stderr, shell=True)
就好了， 我专门把这个函数放到一个单独的文件中， 分别在 cmd.exe , powershell, msys2, 还有emacs 安装路径下的 cmdproxy.exe 去跑这个文件， 无一例外都报错了。 我的环境：
Anaconda 安装的Python3.8
官网下载安装包安装的Python3.9
msys2 下 pacman 安装的Python3.9
npm 安装的pyright (npm -g install pyright)
想请教一下各位Windows大佬，有没有遇到过这样的问题？ 是怎么解决的？
pip install pyright 可解，或者把 pyright.json 拷贝成 pyright_windows.json 里面 pyright-langserver 改成 pyright-langserver.cmd
Windows是不是一定要用 pyright-langserver.cmd ？ 可以内置对 Windows pyright 的支持。
完全按照 readme, 用 pip install pyright 是没问题的，只有 npm 装的 pyright 才需要改成 cmd
