Mac 下一切 ok，试了下太好用了，但奈何我主要在 terminal 中开发
我是 debian+emacs28，然后依赖项安装如下：
预期是 # 前缀可以搜索 current buffer，! 前缀可以在 project/directory 下搜索，但是我 # ok, ! 不 ok，是我依赖项有问题吗
# 正常工作容易理解，因为不涉及外部依赖项，但是 ! 依赖，会不会是依赖项的问题呢
blink-search 的逻辑是先看 git root project, 没有 git 就按照启动时所在的目录递归搜索， 看一下README, 有问题看看 *blink-search* 有啥报错。
再次多次强调， 出了问题先 emacs -Q 测试一遍（论坛输入框有方法）， emacs -Q 没问题先看项目的 README, 请先自助再他助。
好的好的，我先试试
观察了一下 blink-search，
fd 在 Mac 下是 fd，但是在 debian 下叫 fdfind，然后我去 search_find_file.py 里把 fd 改掉。 然后继续观察，是这样的： 然后我就把 google 那个 backend 都注释掉了。然后我干脆 emacs -Q，然后单独 load blink-search：
Alias fd=fdfind
这个这 python 代码里我改了，fd => fdfind
麻烦把这几张图发一下github issue吧，除了第一个debian改二进制名字外，其他有可能是健壮性bug，应该可以防御下。
谢谢。
1 个赞
google suggest 那个不用的话，不需要注释源码。之前专门加了一个选项, 例如这样：
(setq blink-search-search-backends '("Buffer List"
"Common Directory"
"Find File"
"Recent File"
"IMenu"
"Elisp Symbol"))
1 个赞
这个是另外一码事了，我目前之前改了 python 脚本绕过这个问题了
问题解决，个人猜测 blink-search 中 rg 不应该加 --no-binary flag
已经去掉了，谢谢反馈。
blink-search最大优点就是变态的快，快到你觉得所有结果都是马上就出现的。
不管多大的搜索结果，不会有一丝一毫的卡顿。
1 个赞
我感觉出来了，在 blink-search 问题解决前，用的 counsel-rg，稍微有点卡顿
不过我没仔细看 python RPC 那块源码，他有控制资源用量啥的吗。比如我输入 !abcde，我看日志是 a ，ab 这种前缀都会发送？
没有调度，就是暴力启动线程调用rg，所有老旧rg进程的搜索结果都会被无情的抛弃。
原因是即使外部进程介入，只要吐大量数据回emacs，emacs的GC就会让你卡住。
这也是lsp-mode, eglot, ivy等依然达不到丝滑的主要原因（elisp执行性能是辅因，没有多线程是死穴）。