bug#50067: Context menus

[Dmitry Gutov]

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.