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

[Gregory Heytings <gregory@heytings.org>]

>
> We are talking about project.el, so the focus should be on looking for 
> strings that are meaningful in the programming-language context, because 
> that is what we need when programming.  Not looking for arbitrary 
> strings.
>

As Dmitry said, this isn't true.  But let's assume that it is.  The latter 
(arbitrary strings) is a superset of the former (identifiers).  In 
practice if you search for some identifier, it's not a real problem to see 
a few more matches in, say, the README or a ChangeLog file.

IMO, the one and only case where a specialized tool beats ripgrep (or just 
plain grep) is when you just want the place(s) where the identifier is 
defined.

>
> If someone wants to look for arbitrary strings, they want "M-x grep" 
> (with or without ripgrep), not project-find-regexp.  The meaning of 
> "word" or "symbol" is different in different PLs; a tool like Grep can 
> only approximate that, whereas ID Utils uses the correct definition for 
> each language.
>

That's not correct, mkid only supports a limited number of programming 
languages.  And it's not even precise: rg O_CREAT on the Emacs trunk for 
example returns 45 matches, gid O_CREAT returns 33 matches.

>> Moreover, incremental updates are not implemented in mkid.
>
> It doesn't matter, as it's fast enough, and putting it on some kind of 
> cron job is more than enough to allow forgetting that this step exists.
>

Five seconds to scan the whole Emacs trunk is IMO not fast enough (ripgrep 
does it in < 0.2 seconds).  And without incremental updates, updating the 
database would be necessary before each invocation of gid, because what 
users expect when they search for something are accurate results 
corresponding to the current state of the project, not results from, say, 
an hour ago.