Why Emacs Consult async searches feel slow and how to speed them up
This article explains how to optimize the performance of the Emacs Consult package by adjusting debounce and throttle variables. It clarifies that these settings control the feedback loop latency rather than the speed of the underlying search tools like ripgrep.
Why it matters
Improving developer tool responsiveness can significantly enhance productivity and user experience for power users of text editors.
Hacker News X Reddit LinkedIn Author: James Cherti The 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.
Get smarter about the news
Sign up free for a feed built around what you actually care about, Dive Deeper research on any story, and the full text of every article.
Create free accountAlready have an account? Sign in