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

[Eli Zaretskii]

> Cc: juri@linkov.net, joaotavora@gmail.com, 44611@debbugs.gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Fri, 25 Dec 2020 14:14:30 +0200
> 
> > 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.

I'm probably missing something: why cannot we display the Grep hits
received asynchronously in the Xref format?  That would "just" mean
changes in the filter function, right?  IOW, I'm confused by your
reference to asynchronous execution, which AFAIU has nothing to do
with the form in which we present the results, nor with the major mode
in which we put the buffer where the results are displayed.

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

We don't need to throw out Grep, not right away anyway.  We just need
a plan and a roadmap, and a decision that this is the long-term goal.
And even when we have "M-x grep" showing results in Xref mode, it will
still need at first be an optional feature, so people who are too used
to the old presentation could have it.

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

An optional feature cannot hurt, even if and when it becomes the
default.  Thus, there's no need for me to object to such long-term
plans, if they are announced and proceed at a controlled pace
(including the decision when it becomes the default).

> > Do we also want to replace compilation-mode with xref-mode?
> 
> That wouldn't work.

I don't understand why.  Can you explain?

To clarify, all I'm talking about is a possibility to present compiler
messages in Xref format.  They are similar enough and show the same
information, so why won't that work?

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

It doesn't all have to happen in Emacs 28.

> Do you really want this to happen, though?

I don't know, I just had this thought and wanted to see what others
think.  However, if that isn't the plan, then I really don't
understand the urge to make Xref be like Grep mode.  If they are
indeed different beasts, why make them similar?

> I never got the impression that you enjoy using xref.

Aside of the fact that I use it every hour of every day, you mean?