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

[Dmitry Gutov]

On 03.03.2020 1:05, Juri Linkov wrote:
> > > > > > > C-x p g - project grep
> > > > > >
> > > > > > Bind project-find-regexp to it?
> > > > >
> > > > > Not sure since project-find-regexp is not asynchronous as grep.
> > > >
> > > > All the more reason for someone to work on that. And the former has
> > > > other benefits.
> > > ‘C-x p s g’ could be bound to a new command ‘M-x project-grep’ that could
> > > run:
> > >     git --no-pager grep --color -inH -p -e "search_string"
> >
> > And then we'll have three very similar commands side-by-side in the same
> > menu, or on the same prefix?
>
> Yes, in the new Project menu.

I think that would be silly.

> But what about vc-grep?
> Should it use xargs on ls-files, or the existing command vc-git-grep
> should be generalized with a new backend operation e.g. "vc-grep pattern"
> that could be implemented by more vc backends?

If it can be generalized, it can be generalized. But it seems unrelated 
to the current discussion.

> > > Then ‘C-x p C-s’ could be bound to ‘project-search’
> >
> > People are welcome to use it, but it's implementation and UI are suboptimal
> > in several respects.
>
> Maybe a better option is to implement project-isearch,
> i.e. multi-file isearch on all project files?
> This is trivial to do with just a call to (multi-isearch-files files)

https://pics.me.me/thumb_why-mermegenerator-net-but-why-jackie-chan-meme-meme-50686141.png

project-find-regexp is both faster in most situations, works remotely, 
and provides a decent UI.

You're free to implement any variations of existing commands, and they 
can be good in certain situations, but we shouldn't prefer them over the 
primary command (which has had quite some work put into) for the menu 
placement.

> > > and ‘C-x p M-%’ to ‘project-query-replace-regexp’.
> > > BTW, why current project commands are not documented
> > > in the Emacs Info manual?  Should they?
> >
> > I don't know. What are the criteria?
>
> Maybe when is becomes popular enough?

That doesn't sound right. We put info into the manual to popularize it, 
not vice versa.