emacs suppended when input(change) too quick in counsel-rg

[lld2001]

os:win7(64),
emacs:27.0.60
when I use counsel-rg and input or change the searching condition too quickly, it can cause the emacs suppended. It even cannot be resumed by CTRL+G. There is a "rg.exe" process in windows TASK MANAGER lists. If I kill that process by hand. Then emacs is resumed. I dont konw if there is way I can set the searching delay. Or how cope with this issue.

Sorry, English is not my native language.

[lld2001]

This is the gif screenshot. When I press backspace quickly to delete "helpful" (query condition), it cause emacs suppended.
https://emacs-china.org/uploads/default/original/2X/d/d262c52b191a1aa3aa5eade17f70a357686a08af.gif

[lld2001]

I got the answer from other website!
(setq ivy-dynamic-exhibit-delay-ms 200)
plus, it can be suppended when set to 150 ms.

[lld2001]

NO, that way does not always WORK. Sometime, it's still suppended. I think it need a useful way to cooperate the sender and the receiver in windows.

[lld2001]

I test this function in the following mininal configuration(put into .emacs file). The emacs is still blocked.

(toggle-debug-on-error)
(setq package-user-dir (format "%s/elpa--test-smartparens/%s" user-emacs-directory emacs-version))
(setq package-archives
      '(("gnu" . "https://elpa.gnu.org/packages/")
        ("melpa" . "https://melpa.org/packages/")))

(package-initialize)

(defun require-packages (&rest packages)
  (dolist (pkg packages)
    (unless (package-installed-p pkg)
      (package-refresh-contents)
      (package-install pkg))
    (require pkg)))

(require-packages
 'counsel
 )

(require 'package)
(defun list-installed-package ()
  (mapcar
   #'car
   (mapcar
    (lambda (p) (cons (package-desc-full-name p) p))
    (delq nil
          (mapcar (lambda (p) (unless (package-built-in-p p) p))
                  (apply #'append (mapcar #'cdr package-alist)))))))

;; ------------------------------------------------------------------

(add-hook 'after-init-hook
          '(lambda ()
             (switch-to-buffer "*.c")
             (insert "// -*- mode: c -*-\n")
             (insert (format "// Installed packages: %s\n" (list-installed-package)))
             (insert "// Press ' below:\n")
             (c-mode)
             ))

(run-hooks 'after-init-hook)

[lld2001]

• blocked Emacs screenshot:
  https://emacs-china.org/uploads/default/original/2X/a/aa8ee80fe67b6bec6d8d744258baab308ab98e7d.png
• after kill the "rg.exe" process:
  https://emacs-china.org/uploads/default/original/2X/1/1a5036e79efa6507556a938a4156ca7a8065c0e0.png

[lld2001]

another minimal configuration also cause emacs dead:

(add-to-list 'load-path "F:/emacs/.emacs.d/elpa--test-smartparens/27.0.60/ivy-20200424.1054/")
(add-to-list 'load-path "F:/emacs/.emacs.d/elpa--test-smartparens/27.0.60/swiper-20200319.1334/")
(add-to-list 'load-path "F:/emacs/.emacs.d/elpa--test-smartparens/27.0.60/counsel-20200422.1208/")
(require 'ivy)
(require 'swiper)
(require 'counsel)

[lld2001]

When I set the delay to this:

(setq ivy-dynamic-exhibit-delay-ms 250)

all command (especially including C-n and C-p) in ivy are also affected.

[abo-abo]

Sorry that it's not working. I use Linux and never had this problem. That's why the default setting for ivy-dynamic-exhibit-delay-ms is 0.

If you or anyone else can manage to fix the problem on Windows, patches are welcome.

[lld2001]

I'd like to try to solve this problem. Could you please give me some suggestion? This is the profile report after reproduced the problem:

• command-execute 38 100%
• call-interactively 38 100%
• funcall-interactively 38 100%
• counsel-M-x 38 100%
  - ivy-read 38 100%
  • apply 38 100%
  • #<compiled 0x3a1a5d3> 38 100%
  • ivy-call 38 100%
  • #<compiled 0x3c5a287> 38 100%
    - counsel-M-x-action 38 100%
    • command-execute 38 100%
    • call-interactively 38 100%
    • funcall-interactively 38 100%
    • +ivy/project-search 21 55%
      - +ivy-file-search 21 55%
      • let* 21 55%
      • progn 21 55%
      • progn 21 55%
      • let* 15 39%
        - counsel-rg 14 36%
        • counsel-ag 9 23%
        • ivy-read 6 15%
        • counsel-require-program 3 7%
          - or 1 2%
        • doom-project-root 1 2%
        • let 1 2%
        • projectile-project-root 1 2%
        • cl-some 1 2%
          - #<compiled 0x3ce595b> 1 2%
          • projectile-root-bottom-up 1 2%
          • cl-some 1 2%
          • #<compiled 0x3ce5967> 1 2%
          • projectile-locate-dominating-file 1 2%
            - apply 1 2%
            • #<compiled 0x374ba05> 1 2%
              projectile-file-exists-p 1 2%
      • if 6 15%
        - executable-find 6 15%
        locate-file 6 15%
    • edebug-pop-to-backtrace 17 44%
      - debug 17 44%
      • recursive-edit 16 42%
      • command-execute 13 34%
      • call-interactively 13 34%
      • funcall-interactively 13 34%
        - counsel-M-x 13 34%
        • ivy-read 10 26%
        • apply 10 26%
        • #<compiled 0x3a1a5d3> 10 26%
        • read-from-minibuffer 5 13%
          - ivy--queue-exhibit 1 2%
          • ivy--exhibit 1 2%
          • ivy--update-minibuffer 1 2%
          • ivy--format 1 2%
          • mapcar 1 2%
            - ivy-rich--counsel-M-x-transformer 1 2%
            • ivy-rich-format 1 2%
            • mapconcat 1 2%
            • #<compiled 0x3cd7d51> 1 2%
            • ivy-rich-format-column 1 2%
              counsel-M-x-transformer 1 2%
        • ivy--reset-state 4 10%
          - sort 3 7%
          • ivy-prescient-sort-function 2 5%
            prescient-sort-compare 1 2%
        • counsel--M-x-externs 3 7%
        • amx-detect-new-commands 3 7%
        • mapatoms 3 7%
          #<compiled 0x3cd6ec7> 2 5%
• ... 0 0%
  Automatic GC 0 0%

[abo-abo]

I suggest examining your rg.exe. It's a grep program. It should not hang. If the problem goes away when you kill rg from the Task Manager, maybe the bug is not in ivy.

Try executing in a different environment, e.g. Cygwin.

[lld2001]

I tested with the latest rg.exe, both under windows native(ripgrep-12.0.1-x86_64-pc-windows-msvc) and gnu(ripgrep-12.0.1-x86_64-pc-windows-gnu). Emacs is still hung.

[kiennq]

In counsel-delete-process if you replace delete-process with kill-process, the hang will disappear.
I think counsel-rg is trying to delete old rg process but it turns out taking too much time (the process can just hang) and the emacs hang over there. The kill-process don't have this problem

[lld2001]

But that will ask you confirm:
Buffer " * counsel *" has a running process;kill it?(y or n)
It cannot even input y or n, because the input is inserted to minibuf's condition area.

[lld2001]

The above seems happen sometimes.

[lld2001]

Plus the =kill-process= can also hang emacs.

[kiennq]

I've set

(setq ivy-dynamic-exhibit-delay-ms 20)
(setq counsel-async-filter-update-time 1000000)

what's your value?
Using kill-process may require more hacks, but it never (or significantly less) hangs for me compare to delete-process

[lld2001]

It's 20 ,500000

[lld2001]

What's your hacks when using kill-process.

         (kill-buffer-query-functions
    (delq 'process-kill-buffer-query-function kill-buffer-query-functions))

hack from google.

[kiennq]

Yep, that's the hack https://github.com/abo-abo/oremacs/blob/0a0ce9adc13e19f07a80c9def4435d1e8cf324be/init.el#L68

[lld2001]

It sometimes still hang after I set the kill-buffer-query-functions to nil and set the above two as yours. So strange.

[lld2001]

It can lead to hang , sometimes when I delete previous character, sometimes when I input. Maybe it make new process too often.
eg, I input "go"(mean goto but hang, continue random input "sdfjksdfklsjd"), When I kill the rg by hand, the query condition become:"gosdfjksdfklsjd". Emacs seems still accepting input after hang but cannot resume by C-g.

[basil-conto]

@kiennq delete-process kills the process with SIGKILL and immediately forgets about it and runs its sentinel. kill-process is not the right thing to do here and should be no better than delete-process.

Some options:

• delete-process misbehaves on Windows. Please try to M-x report-emacs-bug if this is the case, so that the issue can be fixed in a future Emacs version. Also try reproducing the issue in other versions of Emacs, like Emacs 26 or the latest development version from the Emacs sources to determine whether it is specific to Emacs 27.
• Counsel calls delete-process but either its sentinel function or some other persistent reference to the process hangs.
• Try substituting something like rgrep or ag in place of rg to see if the issue persists with those search tools as well.

[lld2001]

Thanks for your options.

• I can reproduc the issue with emacs-26.2-x86_64.
• I replace rg with ag win32 ag and the issue still exist. But after emacs hang, the process still in Task Manager is bash.exe, not ag.exe
• single query with rg.exe e.g. color-rg never hang emacs.
• The issue happened accidentally. It's hard to describe clearly. Maybe the gif screenshot animation is more clear than text describing.

[basil-conto]

Sounds like either shell commands on Windows, the way Counsel uses shell commands on Windows, or Bash on Windows specifically is misbehaving. I don't know whether the fault lies with Windows, Bash, Emacs, or Counsel, but perhaps the issue would be resolved by invoking rg & friends as subprocesses rather than shell commands. I've been advocating this for a while but it's an uphill battle that I don't have the time or patience for at the moment.

As an aside: I don't know what other Unix-like shells are available on Windows, but perhaps it would be worth testing whether the issue happens with shells other than Bash.

[kiennq]

Sounds like either shell commands on Windows, the way Counsel uses shell commands on Windows, or Bash on Windows specifically is misbehaving. I don't know whether the fault lies with Windows, Bash, Emacs, or Counsel, but perhaps the issue would be resolved by invoking rg & friends as subprocesses rather than shell commands. I've been advocating this for a while but it's an uphill battle that I don't have the time or patience for at the moment.

This is sad. Windows doesn't have a good command shell AFAIK, so using counsel-rg/ag/pt on Windows is quite unusable.
I can confirm that with using process without shell eliminate the problem of emacs hanging (mostly).
Well, it's reduced but still hang a lot.
Let's me see if I can whip up a hack for that

[kiennq]

I found an old thread that mention using delete-process is hanging Emacs https://lists.gnu.org/archive/html/emacs-devel/2007-08/msg00699.html.
It seems that it has already being patched (or partially ?) but using kill-process or quit-process can work around that.

[kiennq]

With not always spawning new sub process every key strokes, it seems that I can completely eliminate hanging when using counsel-rg. PR #2556

@lld2001 You can try with this https://github.com/kiennq/swiper, which are including creating sub process directly without shell and reducing number of new process creations.
The hanging problem seems gone to me now.

[lld2001]

@kiennq Thank you. It works for me by setting (setq counsel-async-command-delay 0.2). Never hang emacs by do my best to reproduce the "quick input" action. But the default (setq counsel-async-command-delay 0.1) can still hang.

[lld2001]

It does not have the side effect of ivy-dynamic-exhibit-delay-ms causing C-n and C-p slower.

[lld2001]

OMG, it accidentally hang. That's very confusing.

[kiennq]

OMG, it accidentally hang. That's very confusing.

Will increasing counsel-async-command-delay help? Also which rg did you use? Is it a shim from scoop or rg.exe by itself?

[kiennq]

@lld2001 You can also turn on using subprocess instead of shell command by setting counsel-rg-base-command to a list instead of string.
Here is my setting:

(setq counsel-rg-base-command `("rg" "-M" "1024" "-H" "-n" "--color" "never" "--no-heading"
                                "-S" "--hidden" "-L" "-P" "%s" "."))

[lld2001]

@kiennq By increasing counsel-async-command-delay, it can reduce the frequence of hang. My current rg.exe is official version 12.1.0 windows msvc. For me, your PR is more effective than setting ivy-dynamic-exhibit-delay-ms. I seldom suffer from hang by setting counsel-async-command-delay to 0.5. Thank you.

[kiennq]

Can this be close?

[basil-conto]

I guess so, at least until further notice. Thanks.