From: Dmitry Gutov <dgutov@yandex.ru>
To: Eli Zaretskii <eliz@gnu.org>
Cc: alan@idiocy.org, mattiase@acm.org, juri@linkov.net,
homeros.misasa@gmail.com, tkk@misasa.okayama-u.ac.jp,
larsi@gnus.org, 50067@debbugs.gnu.org
Subject: bug#50067: Context menus
Date: Mon, 30 Aug 2021 05:45:07 +0300 [thread overview]
Message-ID: <fa0e47a2-fafb-0c3b-b693-be1acca58c34@yandex.ru> (raw)
In-Reply-To: <8335qvs8re.fsf@gnu.org>
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.
next prev parent reply other threads:[~2021-08-30 2:45 UTC|newest]
Thread overview: 101+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <74BC00E9-2509-47DA-9428-1523FF7F3B33@acm.org>
2021-08-18 16:42 ` bug#50067: Context menus Juri Linkov
2021-08-18 17:46 ` Mattias Engdegård
2021-08-18 17:53 ` Eli Zaretskii
2021-08-19 14:22 ` Mattias Engdegård
2021-08-20 7:31 ` Juri Linkov
2021-08-20 17:06 ` Mattias Engdegård
2021-08-20 23:31 ` Dmitry Gutov
2021-08-21 4:43 ` Tak Kunihiro
2021-08-21 6:33 ` Tak Kunihiro
2021-08-22 8:28 ` Juri Linkov
2021-08-23 3:11 ` Tak Kunihiro
2021-08-23 7:24 ` Juri Linkov
2021-08-24 10:12 ` Tak Kunihiro
2021-08-24 17:23 ` Juri Linkov
2021-08-24 23:43 ` Tak Kunihiro
2021-08-25 17:45 ` Juri Linkov
2021-08-26 6:13 ` Juri Linkov
2021-08-27 6:24 ` Juri Linkov
2021-08-28 5:18 ` Tak Kunihiro
2021-08-31 17:37 ` Juri Linkov
2021-08-31 17:43 ` Juri Linkov
2021-08-31 18:58 ` Eli Zaretskii
2021-09-01 7:12 ` Juri Linkov
2021-08-18 17:46 ` Eli Zaretskii
2021-08-18 18:01 ` Mattias Engdegård
2021-08-18 18:11 ` Eli Zaretskii
2021-08-18 18:06 ` Juri Linkov
2021-08-18 18:12 ` Eli Zaretskii
2021-08-18 18:39 ` Eli Zaretskii
2021-08-19 1:31 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-08-19 6:44 ` Eli Zaretskii
2021-08-18 18:40 ` Juri Linkov
2021-08-18 18:59 ` Eli Zaretskii
2021-08-19 7:12 ` Juri Linkov
2021-08-19 7:57 ` Eli Zaretskii
2021-08-20 7:29 ` Juri Linkov
2021-08-20 10:29 ` Mattias Engdegård
2021-08-20 10:53 ` Eli Zaretskii
2021-08-20 11:32 ` Mattias Engdegård
2021-08-20 16:50 ` Juri Linkov
2021-08-20 17:11 ` Mattias Engdegård
2021-08-20 11:32 ` Eli Zaretskii
2021-08-20 16:36 ` Juri Linkov
2021-08-20 17:59 ` Eli Zaretskii
2021-08-20 19:29 ` Mattias Engdegård
2021-08-21 9:42 ` Alan Third
2021-08-21 10:57 ` Mattias Engdegård
2021-08-21 11:17 ` Eli Zaretskii
2021-08-21 11:45 ` Mattias Engdegård
2021-08-21 12:16 ` Eli Zaretskii
2021-08-22 19:11 ` Dmitry Gutov
2021-08-22 19:22 ` Eli Zaretskii
2021-08-22 19:54 ` Dmitry Gutov
2021-08-23 2:21 ` Eli Zaretskii
2021-08-23 11:18 ` Dmitry Gutov
2021-08-23 11:40 ` Eli Zaretskii
2021-08-23 16:02 ` Juri Linkov
2021-08-24 17:59 ` Dmitry Gutov
2021-08-25 14:15 ` Dmitry Gutov
2021-08-25 15:59 ` Eli Zaretskii
2021-08-26 13:01 ` Eli Zaretskii
2021-08-26 21:05 ` Dmitry Gutov
2021-08-26 21:07 ` Dmitry Gutov
2021-08-27 6:13 ` Juri Linkov
2021-08-27 6:26 ` Eli Zaretskii
2021-08-30 2:45 ` Dmitry Gutov [this message]
2021-08-30 11:57 ` Eli Zaretskii
2021-08-31 7:05 ` Juri Linkov
2021-08-31 12:24 ` Dmitry Gutov
2021-08-31 16:56 ` Juri Linkov
2021-08-31 20:23 ` Dmitry Gutov
2021-09-01 7:08 ` Juri Linkov
2021-09-01 19:03 ` Dmitry Gutov
2021-09-05 0:55 ` Dmitry Gutov
2021-09-05 8:37 ` Juri Linkov
2021-09-05 19:25 ` Dmitry Gutov
2021-08-22 8:46 ` Juri Linkov
2021-08-15 8:48 Juri Linkov
2021-08-15 11:56 ` Lars Ingebrigtsen
2021-08-15 16:12 ` Juri Linkov
2021-08-16 11:31 ` Lars Ingebrigtsen
2021-08-17 8:12 ` Juri Linkov
2021-08-18 4:38 ` Tak Kunihiro
2021-08-18 7:47 ` Juri Linkov
2021-08-28 9:08 ` Naoya Yamashita
2021-08-28 18:50 ` Juri Linkov
2021-09-27 15:30 ` Juri Linkov
2021-09-27 15:50 ` Lars Ingebrigtsen
2021-09-28 18:49 ` Juri Linkov
2021-09-29 7:00 ` Juri Linkov
2021-09-27 18:41 ` Eli Zaretskii
2021-09-28 18:54 ` Juri Linkov
2021-09-28 19:31 ` Eli Zaretskii
2021-09-27 15:33 ` Juri Linkov
2021-10-20 16:59 ` Juri Linkov
2021-11-08 20:05 ` Juri Linkov
2021-11-18 18:38 ` Juri Linkov
2021-11-25 7:50 ` Juri Linkov
2021-11-25 8:38 ` Eli Zaretskii
2021-11-25 19:28 ` Juri Linkov
2021-11-30 18:12 ` Juri Linkov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=fa0e47a2-fafb-0c3b-b693-be1acca58c34@yandex.ru \
--to=dgutov@yandex.ru \
--cc=50067@debbugs.gnu.org \
--cc=alan@idiocy.org \
--cc=eliz@gnu.org \
--cc=homeros.misasa@gmail.com \
--cc=juri@linkov.net \
--cc=larsi@gnus.org \
--cc=mattiase@acm.org \
--cc=tkk@misasa.okayama-u.ac.jp \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.