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

Previous Next

Full log

Message #195 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: Wed, 4 Mar 2020 14:05:27 +0200

On 04.03.2020 1:19, 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.

> 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

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

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

If you have a better implementation in mind, I will certainly try it.

>> 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"?

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.

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

Previous Next

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