bug#50067: Context menus

[Eli Zaretskii <eliz@gnu.org>]

> Cc: juri@linkov.net, alan@idiocy.org, mattiase@acm.org,
>  homeros.misasa@gmail.com, tkk@misasa.okayama-u.ac.jp, larsi@gnus.org,
>  50067@debbugs.gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Fri, 27 Aug 2021 00:05:39 +0300
> 
> I think I remember now why it didn't make sense to me to have this 
> behavior OOTB: I think the main goal of the user who calls 
> xref-find-definitions is, usually, to pick one definition they wanted to 
> visit. Which also means having the xref buffer dismissed at the end.

That's one use case.  Another use case is when the candidates are all
related to some issue the user is working on, and therefore leaving
the xref buffer displayed for a long time is what they want.

> With the patch under discussion we automatically jump to the first 
> location. We can even iterate through locations with 
> next-error/previous-error (M-g M-n/M-g M-p). But to close 
> (quit/kill/etc) the list of locations, you have to switch back to its 
> window and press 'q'. Didn't that look like a bother to you?

No.  In my case, I just never bother to dismiss the xref buffer.  The
window showing it is a small one, and sooner or later the xref buffer
gets replaced by *Help* or ChangeLog or one of the other buffers I
display at the bottom of the frame.

> Here's how it could look instead:
> 
> 1. When you press M-., the first location is "shown", but not jumped to. 
> The focus remains on the Xref window, with point on its first item (the 
> arrow beside it is visible, like you wanted). Location is visible in the 
> other window, and we can either visit it and dismiss the Xref buffer 
> (with 'C-u RET'), simply visit it with 'RET', or look at the other 
> locations with 'n'/'p'.

This AFAIU corresponds to the situation where the user is not certain
which of the candidates is the one he/she wants.  I don't see how it
fundamentally differs from the original patch, since "M-g M-n" (or
"C-x `", which is what I use) isn't less convenient than 'n' followed
by "C-x o".  It might be more convenient to those who like to dismiss
the xref buffer, but (a) I'm not one of them, and (b) one can dismiss
it without going into it with "C-x 4 C-o".

> And you could also use a "transient" show-definitions-function like:
> 
> (setq xref-show-definitions-function
>        #'xref-show-definitions-buffer-at-bottom)
> 
> Then you'd only need to press RET in the results buffer to jump and 
> dismiss the results buffer.

Do a lot of people really like to dismiss the xref buffer?

In any case, I think questions about this aspect are better answered
by someone who does like to dismiss the buffer, because the issue
simply doesn't bother me enough to give you any useful input.

> 2. Simply have point move to the first location in the list (rather than 
> remain on the group name). From there, the user can press 'C-o' to show 
> the location without visiting, or 'RET', or 'C-u RET' like described 
> above. I understand this does not fit your prior workflows, but it does 
> require the least number of button presses in the scenario "go to the 
> first location and dismiss the Xref buffer", especially in combination 
> with the (setq xref-show-definitions-function ...) form above.

That's just a minor change in what we have now.  I don't object to
such a change, not even by default, but it isn't what we were
discussing until now.

> >> 1. Does the new behavior work okay window management-wise (it does
> >> occupy +1 window, after all)?
> > 
> > Not sure I understand the question: we pop up an additional window
> > when there are more than one candidate even without this option, so
> > why do you say "+1 window"?  Maybe you had some recipe in mind that I
> > didn't try?
> 
> It's "+1 window" compared to how 'find-tag' worked/works, which I assume 
> is the target.

No, I think xref is actually an improvement in this department,
because it shows the list of candidates instead of letting the user
guess how many are there.

> >> 2. Should this setting also extend to other commands like
> >> xref-find-references?
> > 
> > Not necessarily.  Perhaps xref-auto-jump-to-first-definition should be
> > tri-state, to allow users to request the same with
> > xref-find-references as well?
> 
> Sure. Or we can have two variables, especially if we end up cramming 
> different variations of behavior into them.
> 
> We can do a lot of things. What would help, is better knowledge about 
> what people *want* to do.

If we don't want to take a guess, I'd suggest leaving the option as it
is, affecting only xref-find-definitions, and extend it to other
commands as user requests arrive.