bug#44611: Prefix arg for xref-goto-xref

[Dmitry Gutov <dgutov@yandex.ru>]

On 25.12.2020 09:37, Eli Zaretskii wrote:

>>> Why does project-find-regexp need to use Xref for displaying the hits?
>>> why not use Grep-like display we use in *grep* buffers?
>>
>> These days the default Xref buffer is pretty much Grep-like. Certainly
>> much closer to grep-mode than it had been in the first versions. That
>> old UI was a lot more completion-like in its behavior.
>>
>> This happened gradually, after we have addressed feedback from you and
>> other users, so that xref-find-references and project-find-regexp behave
>>    more in a fashion that you would expect from it. And those
>> expectations were surely informed by Grep and other built-in modes.
> 
> Then why do we need to have 2 separate modes?

Well, Grep (and similar major modes people wrote in third-part packages) 
do have a certain advantage: its execution is asynchronous, and the user 
sees the results as soon as they arrive, even during a search over a 
huge number of files. This can be implemented for xref, with certain 
changes in the API, and with some use of threads, but that's still a 
research problem.

Grep also has less computational overhead. I have spent quite some 
effort to reduce the gap, and xref works fine for me in that regard, but 
with the amount of user feedback I/we generally receive for improvements 
in core features (i.e. close to none) I can't be sure whether there are 
people who avoid 'M-x project-find-regexp' because Grep feels faster 
anyway.

> Are there any plans for
> replacing grep-mode with xref-mode in all the commands that use the
> former?

I think we'd need a more concerted effort for something like that, 
rather than just myself. To get such volunteers, making the current Grep 
users even more satisfied with the current state of 
xref--xref-buffer-mode is a good step, with much upside and really no 
downside (at least to a point where we'd have to compromise on the design).

I can outline a possible roadmap for improving xref, making its code 
structure and data more logical (which includes moving some of them 
out), but I don't think we'll throw out 'M-x grep' away anytime soon.

Changing the latter to use the xref UI (which will have to be renamed 
and become a separate package, BTW) is also likely to encounter much 
bigger resistance than anything we've done in this area before: people 
don't have the same expectations for new commands as they have for 
existing ones, so I'm surprised you asked this (given your overall 
backward compatibility stance, much stronger than mine). But we can try.

Up until now, we've been using xref mostly in places where there its 
programmatic interface is a strong advantage.

> Do we also want to replace compilation-mode with xref-mode?

That wouldn't work. It's possible to write a similar alternative for 
compilation-mode, but that would be a different project. It could reuse 
some ideas, though.

> If the plan is to make such replacements, that could be a good idea,
> and we can discuss the roadmap towards that goal.  Such a roadmap
> should include a transition plan that will help people migrate as
> painlessly as possible, including the key bindings and the somewhat
> different looks.

It's a big change, one I'm not at all confident we could manage before 
Emacs 28 is released.

Do you really want this to happen, though? I never got the impression 
that you enjoy using xref.

> And perhaps _then_ we will have a good enough reason
> we don't have now to rebind xref-mode's TAB in Emacs 28.

Let me get back to that in another subthread.