rg无响应导致emacs卡住，如何debug?

Emacs-general
,
1

我平时都是用wsl环境的emacs，这两天用windows版本的emacs30试试，doom配置，在win下ivy搜索文件内容，触发的应该是counsel-rg命令，有时候会整个emacs卡住，c-g一直按住也无用，打开任务管理器发现rg.exe无响应了，结束掉进程之后emacs立即恢复响应了。再次搜索同样的关键词，却又无法复现卡住的情况。

ripgrep 是用scoop安装的，已经是最新版了。

请问道友们，这种问题应该如何debug？

2

我的win11+doom用rg经常卡死，同求答案

3

counsel-rg 的话， 使用这个配置。 (setq consult-async-input-debounce 0.8)

更推荐用color-rg

(unless (package-installed-p 'color-rg)
     (package-vc-install "https://github.com/manateelazycat/color-rg"))
(use-package color-rg 
  :config
  (when (eq system-type 'windows-nt)
    (setq color-rg-command-prefix "powershell")))
4

试了一下设置debounce，没有改善，rg多搜索几次就一样会【已挂起】 :innocent:

5

检查一下 “explicit-shell-file-name” 和 “shell-file-name” 是否设置为了 “bash.exe”.

请设置成 “cmdproxy.exe” 试一试。

例如，全局设置 (假设 explicit-shell-file-name 为 nil)

(setq-default shell-file-name (executable-find "cmdproxy.exe"))

或者，局部设置

(let ((shell-file-name (executable-find "cmdproxy.exe"))
  (helm-do-grep-ag) ; 我使用 helm 来调用 rg
  )

之前我使用 helm 的 “helm-do-grep-ag” 也碰到了这样的问题，rg进程有时被无来由挂起，导致emacs假死，除非外部恢复或直接杀掉rg进程，否则无果。 后来发现应该是 bash.exe 导致的，似乎它在windws下不太稳定，bash在启动rg后可能自己出问题直接退出了，导致rg进程挂起无人管，emacs也在傻傻等待bash返回结果，导致emacs卡死。

换成"cmdproxy.exe"以后，一切顺畅，这个问题再没有出现过。

windows下emacs各种小问题多多，并不像linux下那么顺畅。 我还碰到一个问题，在emacs里用 “shell-command” (M-!) 运行 “gitk.exe”, 然后emacs的cpu单核使用率直接飙到100%，即使退出gitk也没用，只能含泪重启emacs。 这个也跟"bash.exe"相关，报了个bug，但是这用法太偏僻，没有修复的意义。

1 个赞
6

目前我 explicit-shell-file-name 为 nil的，按你说的全局设置为cmdproxy.exe后再试，现象还是一样会挂起 :slightly_frowning_face:

7

前面你描述的问题跟我之前碰到的一模一样，我觉得应该就是 bash.exe 导致的。

  1. 首先检查一下 cmdproxy.exe 的设置是否生效了。

    下面代码会检查 cmdproxy.exe 的路径，设置所有相关变量，可以用来试验。

    (let ((cmdproxy-file (or (executable-find "cmdproxy.exe")
                         (let ((f (expand-file-name "cmdproxy.exe" exec-directory)))
                           (if (file-exists-p f)
                               f
                             (user-error "cmdproxy.exe is NOT found"))))))
  ;; 为了测试，都设置上，确保 "cmdproxy.exe" 被使用，后面可以修改
  (setq-default explicit-shell-file-name cmdproxy-file
                shell-file-name cmdproxy-file)
  (setenv "ESHELL" cmdproxy-file)
  (setenv "SHELL" cmdproxy-file))

    在运行rg时，可以用 procexp / procmon 监视一下emacs启动的到底是 bash.exe 还是 cmdproxy.exe。

  2. 如果 bash.exe 依然被使用，那只能检查 counsel-rg 的源代码，看它调用什么来启动rg进程的。

    比如， helm-grep-do-ag 使用的 start-file-process-shell-command 来启动进程，会使用 shell-file-name 来运行rg命令，所以我设置了 shell-file-name 。

1 个赞
8

感觉说的很清楚，按这个设置完善了配置文件，希望能彻底解决问题 :+1:

9

SHELL和ESHELL环境变量都被置上了的，还是挂起了， 如何用procexp查看启动的是bash.exe还是cmdproxy.exe呢？

image
image1232×572 19.8 KB

image
image1226×436 10.1 KB

ivy代码：

image
image947×879 70 KB

counsel-rg代码：

image
image1043×721 71.1 KB

10

是不是跨操作系统读写了，尽量将 emacs rg 你的项目代码都放入 wsl2 虚拟磁盘

11

不会的，我要在wsl2工作的话，文件都是在wsl2的磁盘里。 现在我是想在windows下的emacs工作，访问的就是windows磁盘里的东西。

13

我发现只要我打字够快，就必然能触发这个问题，比如我快速输入format，会看到form的时候卡住了，然后我在任务管理器结束掉挂起的rg.exe进程，emacs就继续显示format的结果了。

看起来像是emacs想结束旧的正在搜索form的rg进程，然后开新的rg给我搜索format，但是结束的时候不知道为什么卡住了，无法结束，等我手动结束rg之后, emacs就新建了两个rg进程，界面显示搜索结果，然后自动结束了这两个rg。

14

那看上去是，即输即搜，这个特性导致了。我没这么频繁使用 rg，暂时无法复现你的情景，可能这个想法是个线索，供你参考。

1 个赞
15

加点延时应该就没这个问题，输入太快，电脑性能跟不上的话确实会卡住

16

应该怎么加呢？大佬指导一下 :thinking:

17

试试修改这个配置项

(setq counsel-async-command-delay 1.0)
18

我现在都把counsel-rg命令再包装一下,先调用read-string读取搜索关键字,再把它喂给原来的命令.

19

这样可以，不过只需要0.1就可以了，我设为0.2测试了几十次暂时没发现卡住。

20

我看ivy似乎有包装，但是看不太懂，所以还是得修炼 :grinning: