Re: bug#12492: vc-dir vs. vc-root-dir

Re: bug#12492: vc-dir vs. vc-root-dir

[Ivan Shmakov]

>>>>> Dmitry Gutov <dgutov@yandex.ru> writes:

[…]

 > 2) For almost all backends we can easily deduce the repository root
 > directory (exceptions: cvs, rcs, sccs), and I believe that in almost
 > all cases the user wants to see the status of this directory, not of
 > some subdirectory or any directory unrelated to the current buffer.
 > Hence the function vc-root-dir, which I think should be bound to 'C-x
 > v d' and the respective menu item.  In the rare case when the user
 > need to do something unusual, they can do M-x vc-dir.

	We already have at least two pairs of commands (C-x v l vs.
	C-x v L /and/ C-x v = vs. C-x v D), of which one operates on the
	current file /and/ the other on the repository as a whole.

	Is there any good reason we can’t have a similar arrangement for
	vc-dir (C-x v d) and the proposed vc-root-dir command (say,
	C-x v /, – where ‘/’ is a kind of obvious mnemonic for “root”)?

	I find it way better than f302475471df, as it both keeps the
	current behavior for C-x v d for those who may still want it
	/and/ it offers a /prompt-free/ shortcut for those who’d always
	want to use vc-dir on the root.

 > When the backend doesn't have the function vc-xx-root, vc-root-dir
 > interactively delegates to vc-dir, so for CVS, for example, the
 > behavior will not change.

	That’s certainly sensible, too.

[…]

-- 
FSF associate member #7257  http://boycottsystemd.org/  … 3013 B6A0 230E 334A

"Non-standard UI", was: Re: bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier and faster)

[Dmitry Gutov]

On 06.03.2020 1:59, Juri Linkov wrote:
> rgrep/vc-git-grep provides good UI.

No, it doesn't. It's the bare-bone-est UI possible, and it wastes a lot 
of horizontal space. It doesn't provide a means to search-and-replace. 
And it's not fit for programmatic construction, so Xref can't use it.

So we can't standardize on it, no matter how much you are used to it.

>>>> 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.
> No, it doesn't call 'find-file' on each file, noccur-project
> calls 'find-file' only on files with matches found by grep.

I asked where that command is defined, linked a webpage, you said yes.

But apparently you instead meant the newer version that's only on Github.

Okay then. Only visiting files that have matches is better. But not good 
enough when a string I entered ends up in having an arbitrary number of 
buffers visited, even if that's less than 4000.

It is one of "quality of life" things I have spent quite some effort on 
improving, and to be frank I don't appreciate you handwaving all that 
away by simply saying "non-standard".

None of the "standard" UIs you mentioned provide the functionality we 
need. Grep is async, but cumbersome and has no provision of doing 
anything with the matches: Wgrep is not in Emacs, not even in GNU ELPA, 
and there's no quick "replace matching string with xxx" feature in it 
anyway. Occur only works with buffers, it's not async either, and the 
overhead of visiting who knows how many buffers is basically unlimited 
(Grep is way faster at finding matches than Emacs at visiting files). 
It's objectively *worse* for the purpose at hand, which will be 
especially evident in bigger projects.

Re: "Non-standard UI",

[Juri Linkov]

>> rgrep/vc-git-grep provides good UI.
>
> No, it doesn't. It's the bare-bone-est UI possible, and it wastes a lot of
> horizontal space. It doesn't provide a means to search-and-replace. And
> it's not fit for programmatic construction, so Xref can't use it.

If you don't like the grep output format, you can replace 'grep-filter'
with your own process filter that would transform it to any other format.

> So we can't standardize on it, no matter how much you are used to it.

> It is one of "quality of life" things I have spent quite some effort on
> improving, and to be frank I don't appreciate you handwaving all that 
> away by simply saying "non-standard".

We already had 2 different formats: grep and occur, and now came a new
3rd format: xref.  I think any attempt to standardize on the output format
should be welcome.  Of course, a general UI should be customizable enough
to provide look and feel of any of the current formats.

> None of the "standard" UIs you mentioned provide the functionality we
> need. Grep is async, but cumbersome and has no provision of doing 
> anything with the matches: Wgrep is not in Emacs, not even in GNU ELPA, and
> there's no quick "replace matching string with xxx" feature in it
> anyway. Occur only works with buffers, it's not async either, and the 
> overhead of visiting who knows how many buffers is basically unlimited
> (Grep is way faster at finding matches than Emacs at visiting files). 
> It's objectively *worse* for the purpose at hand, which will be especially
> evident in bigger projects.

Why not take the best parts from these contenders?
Take async part of finding matches from grep and
transform its output to any format you like.

Re: "Non-standard UI"

[Dmitry Gutov]

On 08.03.2020 2:53, Juri Linkov wrote:
>>> rgrep/vc-git-grep provides good UI.
>>
>> No, it doesn't. It's the bare-bone-est UI possible, and it wastes a lot of
>> horizontal space. It doesn't provide a means to search-and-replace. And
>> it's not fit for programmatic construction, so Xref can't use it.
> 
> If you don't like the grep output format, you can replace 'grep-filter'
> with your own process filter that would transform it to any other format.

Or I can reuse the existing code.

The suggestion is not bad, but the grep-filter approach isn't going to 
work for Xref, at least, because the data format is a list of values.

And there's not much point in writing code to re-create Xref's UI in yet 
another way, if it can't replace the existing builder.

Overall, grep itself is fast, and we've done enough optimization on the 
way its results are processed that it being synchronous shouldn't be a 
significant problem on modern systems with small-to-medium projects, at 
least. But, of course, we could do better.

> We already had 2 different formats: grep and occur, and now came a new
> 3rd format: xref.  I think any attempt to standardize on the output format
> should be welcome.

Of course. But that would take some concerted effort, and not a 
dismissive attitude.

All three have some valuable features (Occur's inline editing feature 
comes to mind), but they also have each own domain of application thus 
far. So it would require work to make the features work everywhere (e.g. 
have Occur's inline editing work without visiting all files in advance).

> Of course, a general UI should be customizable enough
> to provide look and feel of any of the current formats.

So far, Xref provides variables xref-show-xrefs-function and 
xref-show-definitions-function, and I know for a fact that there are 
third-party packages out there that take advantage of these variables.

> Why not take the best parts from these contenders?
> Take async part of finding matches from grep and
> transform its output to any format you like.

I surely wouldn't refuse an extension of Xref API to asynchronous 
fetching of results. It's unlikely to work though grep-filter, though.