GoKawiilThe consult Emacs package provides asynchronous search commands such as consult-fd , consult-find , consult-grep , consult-git-grep , and consult-ripgrep . For these commands, Consult does not necessarily start a new search for every change to the minibuffer input. Instead, it uses configurable debounce and throttle delays to control when asynchronous processes start, while a separate refresh delay controls how frequently asynchronous results are pushed to the completion UI.
The first time I tried Consult, I thought to myself: this feels slow compared to Counsel (I had a similar feeling about Emacs settings such as show-paren-delay ). With Counsel, results updated immediately on every keystroke, while Consult seemed to hesitate for a fraction of a second before updating the list.
As it turns out, this behavior is entirely intentional. The current Consult defaults are conservative by design.
Aggressive asynchronous search
If you prefer lower latency and speed, these variables can be made more aggressive:
( setq consult-async-input-debounce 0.05 consult-async-input-throttle 0.1 consult-async-refresh-delay 0.05 )
These values reduce the amount of time Consult waits before starting another asynchronous search and allow the completion UI to refresh much more frequently.
These values do not make the underlying search programs execute faster. External tools like ripgrep already use highly optimized, multi-threaded algorithms to scan files across multiple CPU cores. Instead, these variables speed up the feedback loop inside Emacs itself. They reduce the waiting period before Consult spawns the external process, and causing the Emacs UI to pull in new asynchronous data and redraw the screen at a much faster rate.
Variable: consult-async-input-debounce
( setq consult-async-input-debounce 0.05 )
... continue reading