GNU bug report logs - #50067
Context menus

Previous Next

Full log

View this message in rfc822 format

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: alan <at> idiocy.org, mattiase <at> acm.org, juri <at> linkov.net, homeros.misasa <at> gmail.com, tkk <at> misasa.okayama-u.ac.jp, larsi <at> gnus.org, 50067 <at> debbugs.gnu.org
Subject: bug#50067: Context menus
Date: Mon, 30 Aug 2021 05:45:07 +0300

On 27.08.2021 09:26, Eli Zaretskii wrote:
>> Cc: juri <at> linkov.net, alan <at> idiocy.org, mattiase <at> acm.org,
>>   homeros.misasa <at> gmail.com, tkk <at> misasa.okayama-u.ac.jp, larsi <at> gnus.org,
>>   50067 <at> debbugs.gnu.org
>> From: Dmitry Gutov <dgutov <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.