bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#50067: Context menus


From: Dmitry Gutov
Subject: bug#50067: Context menus
Date: Fri, 27 Aug 2021 00:05:39 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0

On 26.08.2021 16:01, Eli Zaretskii wrote:
Cc: 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: Tue, 24 Aug 2021 20:59:40 +0300

An option to display the first match right away will be most
appreciated, thanks.
Like compilation-auto-jump-to-first-error.

So we even have a precedent, very good.

Could you both check out the attached patch?

Together with (setq xref-auto-jump-to-first-definition t)

Thanks, this looks very handy, I will definitely use it.

Very good. Let's now discuss a couple of minor alterations. We can always go back to this patch if we don't decide on anything better.

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.

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?

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

For this to work, the patch will need to change xref--auto-jump-first, swapping

+  (xref-next-line-no-show)
+  (xref-goto-xref))

for

+  (xref-next-line)

The new option's name would probably be different too.

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.

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.

Questions for feedback:

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.

So it's still not the same behavior.

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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]