bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier and faster)

[Juri Linkov]

>>> project-find-regexp is both faster in most situations, works remotely, and
>>> provides a decent UI.
>> project-find-regexp is not asynchronous whereas vc-git-grep is.
>
> There's no project-agnostic asynchronous option on the table now.

Only getting project file names should be synchronous and blocking,
everything else (including grepping) could be asynchronous.

>> UI of project-find-regexp is non-standard.  A more familiar UI
>> would be like in occur, for example, as used by noccur-project.
>
> It is standard enough, Xref commands use it. And they have both default key
> bindings and menu items.
>
> noccur-project like this naive implementation?
> https://nicolas.petton.fr/blog/mutli-occur-on-projects.html

It works fine as a proof of concept.

> How long does it take to search the Emacs project for an arbitrary string
> on your machine?

The result is almost instantaneous: 1 sec on Emacs repo.

> Not to mention the unfortunate side-effect of having to visit 4000 buffers.

It visits only matched buffers.

>>> BTW, I wonder how such project-isearch using multi-isearch-files would work
>>> in a non-toy project with a sufficiently-rare input.
>>>
>>> Even if we take the Emacs project itself, loading all 4000 files into
>>> Emacs's memory to search through them all is likely to take a lot of time.
>> No problem at all - trying on the Emacs project:
>>    (multi-isearch-files (project-files (project-current t)))
>> is like project-search, but with more convenient UI:
>> it's easier to type C-s to go to the next occurrence than
>> to invoke the command M-x fileloop-continue that has no keybinding.
>
> "like project-search" also implies "to take a lot of time", that's where
> I made that conclusion from. How long does it take for the UI to say "no
> matches"?

Depends on the search string.

> The UI is probably better (the main thing I like about this idea), but the
> downside is opening several buffers with intermediate matches for
> incomplete input (while you're still typing the search string). Though I
> don't know how serious of a problem that is.

Probably multi-isearch-files could be useful for projects
with small number of files.

> And when I try this, I'm getting messages about uncompressing files, and
> prompts about local variables, which I can't answer.

OT1H, an ability to search in compressed files is an advantage -
even grep can't search in compressed files.  OTOH, it had to visit
all files - this is its downside.