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

[Dmitry Gutov]

On 25.12.2020 13:44, Eli Zaretskii wrote:

> > Big corporations don't afraid making much more fundamental changes
> > that affect billions of users.  For example, on smartphone OS
> > they can do such a change that on the Task list the same gesture
> > will remove the wrong task than on older versions.  Also major sites
> > with billions of users often change their UI completely without hesitation.
> >
> > So I don't understand such extreme precautions.
>
> Do you think that what "big corporations" do is okay?  If you do, then
> I understand why you consider it OK for us to do something similar.
> But if you don't, then why do you suggest that we follow bad examples?

There are different pieces of software coming from "big corporations", 
and there.

All I know that, say, authors of editors like VS Code, Sublime, etc, are 
not afraid to change things from time to time, if their search says it 
results in a better experience. And I haven't seen many user complaints 
about that.

OTOH, it might very well be a part of their recipe for success.

> I don't think frequent changes in the UI and the defaults are a Good
> Thing.  Each time I upgrade some software which comes from those big
> corporations, I have to waste some significant time to get many of my
> previous defaults back, disable or reconfigure annoying new features
> etc.  Moreover, no matter how conservative we are in Emacs with
> breaking backward compatibility, we are still being occasionally
> accused of not being conservative enough.  So evidently, veteran users
> don't like such changes to happen too frequently.  Looking at NEWS for
> past releases, I conclude that we indeed didn't make such changes.

We are accused either way: we're both not conservative enough on one 
side, and too conservative on the other. Which judgment to give 
preference to, is basically a personal choice at this point. Or a 
strategic one.

It's an old disagreement, but I think it should be fairly obvious that 
if we fear to cause discomfort to even one veteran user, we won't be 
able to achieve much progress.

And it's not like the question here it to change a lot or bindings, or a 
significant/popular one.

> > Unlike the above examples,
> > in Emacs everything is configurable, so you can easily add to the init file:
> >
> >    (define-key xref--xref-buffer-mode-map (kbd "TAB") #'xref-quit-and-goto-xref)
>
> This works both ways: if you want TAB to do something other than its
> default, you can rebind it for you, right?

It is a question of which is a better/more consistent behavior.

> > > And why C-j?  That's LFD, a key more suitable for acting on something
> > > at point, not quitting the buffer.
> >
> > The initial xref UI was closer to completion UI, so C-j makes it consistent
> > with icomplete mode for users who still perceive xref as completion UI.
>
> That contradicts what Dmitry said: that the current Xref UI moves away
> of the completion UI, and towards compilation-mode and grep-mode.

Just like that TAB binding was a bit alien to the state of the Xref UI 
as it was 4 years ago, that binding will probably be as well.

But you can also interpret it like "complete the current action". 
Icomplete has that binding, but lisp-interaction-mode has 
eval-print-last-sexp, which is vaguely relevant too.

It's not a perfect parallel, but I think 'C-j' is better for this 
purpose than TAB, and also better than 'q' or 'b'.

On the subject of grep-mode, it could have a similar command introduced 
too, for situations when you only needed to find one occurrence, to jump 
to it and quit the window.

> There, deleting the window with C-j will look odd, I think.
>
> > > Why not 'q' (for "quit") or 'b' (for "bury")?
> >
> > 'xref-quit-and-goto-xref' also jumps to xref, not only quits,
> > but 'q' and 'b' should only quit.
>
> That's not a catastrophe, but if you want, we could use "C-c C-c"
> instead, as that is used in some other modes for similar effect.

'C-c C-c' usually acts on the whole buffer contents and does not depend 
on point, I think.

It might also conflict with the potential "inline editing" feature 
if/when we get that into Xref. Though it could use 'C-x C-s', *shrug*.

To be clear, I'm not wedded to 'C-j', and open to other options. We 
could even make xref-quit-and-goto-xref unbound, except in 
xref--transient-buffer-mode-map. Which is the most "completion-like" 
version of Xref UI we currently have anyway.