GNU bug report logs - #12492
24.2.50; Open vc-dir buffer easier and faster

Previous Next

Full log

Message #204 received at 12492 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Juri Linkov <juri <at> linkov.net>
Cc: 12492 <at> debbugs.gnu.org, Lars Ingebrigtsen <larsi <at> gnus.org>
Subject: Re: bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier
 and faster)
Date: Fri, 6 Mar 2020 01:15:10 +0200

On 05.03.2020 2:04, Juri Linkov wrote:
>>>> 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.

The API indeed allows it, but there are no good UIs with that support 
that we can use. But you're welcome to fix/improve/write one.

>>> 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.

Not if I have to wait for >1 minute for the UI to show up. Or I don't 
know how long, I never managed to muster enough patience to get past all 
the 'local variables' prompts.

>> 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.

I don't understand how that's possible: it's much longer than that on my 
machine, and I have a fast laptop manufactured last year, with NVMe and 
stuff.

>> Not to mention the unfortunate side-effect of having to visit 4000 buffers.
> 
> It visits only matched buffers.

No. It looks through all project files and calls 'find-file' on each of 
them. Which is obviously inevitable since multi-occur only accepts a 
list of buffers, not files.

>>>     (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.

To sum up: project-isearch could be a fine addition, but not the "main" 
search command to recommend to our users.

>> 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.

zgrep can probably do that. Much faster, too.

Anyway, if you want to continue this chat, could you file a relevant 
bug, or post to emacs-devel?

All of this is certainly not about vc-dir anymore.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.