GNU bug report logs -
#50733
28.0.1; project-find-regexp can block Emacs for a long time
Previous Next
Full log
View this message in rfc822 format
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.
This bug report was last modified 3 years and 261 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.