Subject: Re: bug#50733: 28.0.1; project-find-regexp can block Emacs for a long time

From: Dmitry Gutov <[email-masked]>
Date: Fri, 24 Sep 2021 01:40:58 +0300

On 24.09.2021 00:17, Daniel Martín wrote:
> Dmitry Gutov <[email-masked]> writes:
> 
>>
>> Thanks for testing. Did the switch to ripgrep help much?
>>
>> I wonder if we should advertise this setting and recommendation more
>> prominently, at least until we get auto-detection.
>>
> 
> When I set xref-search-program to 'grep, the search is almost 10x slower.

I wonder if we could do more about this problem.

Perhaps on a platform like macOS we should consider bundling some 
up-to-date search program, be it GNU Grep or Ripgrep.

Eli, have there ever been a similar proposal under discussion? IIRC 
having to install external tools has been an issue on MS Windows as well 
for a long time. We give recommendations, but Grep has never been 
distributed together with Emacs. Any particular reason?

For comparison, VS Code bundles ripgrep. Or at least its macOS releases do.

>> Another thing you can do is set up the additional ignores for the
>> project. If those big binary files are not something you are
>> interested in searching and touching, you could add ignore entries for
>> them. When the vc project backend is in use (default), it is currently
>> done via .dir-locals.el: the variable is project-vc-ignores, it's a
>> list of strings that should be globs. See its docstring and the
>> explanation in project-ignores's docstring.
>>
> 
> I sometimes do C-u C-x p g so that I can limit the search to certain
> file extensions.  That helps a little bit.

Ignore entries are a bit more flexible: you don't need to repeat the 
preference every time. But they don't really work when you need to 
ignore only some files some of the time.

> So far, the command that offers me the best performance for this kind of
> project grepping is `vc-git-grep`.

'ripgrep' might be even faster, and there are Emacs interfaces for it 
like deadgrep (https://github.com/Wilfred/deadgrep).

But with Xref we're trying to create a consistent abstract UI that 
honors user's settings and can be used across commands, with extra 
features that can act on search results. There is no reason why it can't 
be snappy, but it's definitely more work.

(I haven't forgotten about bug#49731, BTW.)