bug#50067: Context menus

[Dmitry Gutov <dgutov@yandex.ru>]

On 27.08.2021 09:26, Eli Zaretskii wrote:
>> 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.

Fair enough.

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

I see.

This does not correspond to my usage and expectations, but, fingers 
crossed, this addition will satisfy the needs of other former users of 
'find-tag' as well.

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

All right. You still prefer the original patch, then?

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

Cool.

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

All right.