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

[Dmitry Gutov]

On 24.09.2021 16:06, Eli Zaretskii wrote:

> > > > What is the concern about the presence of the current maintainer? Would
> > > > we do something different if he leaves? We'd probably need to find
> > > > another maintainer, no?
> > >
> > > Yes, and the question is: will we succeed, and how quickly?  We
> > > already had a period of time without one, which means having no one is
> > > not a theoretical danger.
> >
> > I'm not sure how that affects our opinion on bundling, though.
>
> It might mean that bundling won't happen for mundane reasons.

All right. But we can ask.

Before we do that,

Daniel, could you do a couple of benchmarks specifically with GNU Grep?

There are instructions for installing it here: 
https://apple.stackexchange.com/a/193300

Ripgrep might be faster (at least on some inputs), but even if we 
supported it for all kinds of searches (which we currently don't), we 
really won't get auto-detection into Emacs 28, so if GNU Grep's 
performance is within ~20%, we should focus on it first.

To improve OOTB performance across the board.

> > id-tools (or alternatives) could help avoid the "fetch all project
> > files" step, though. At the cost of extra manual management, which I
> > personally don't like much.
>
> Why is that a problem?  We have midnight.el which could be part of the
> solution.

As Gregory mentioned, users often expect the results to be up-to-date, 
especially when it concerns a command as common as "find regexp". Doing 
it on cron is not ideal.

But of course we're free to add extra knobs for particular power users.