From: Eshel Yaron <me@eshelyaron.com>
To: Dmitry Gutov <dgutov@yandex.ru>
Cc: Spencer Baugh <sbaugh@janestreet.com>,
Eli Zaretskii <eliz@gnu.org>,
stephen_leake@stephe-leake.org, john@yates-sheets.org,
rms@gnu.org, fgunbin@fastmail.fm, casouri@gmail.com,
emacs-devel@gnu.org, azeng@janestreet.com
Subject: Re: Adding support for xref jumping to headers/interfaces
Date: Sun, 05 Nov 2023 09:16:40 +0100 [thread overview]
Message-ID: <m1r0l41uon.fsf@dazzs-mbp.home> (raw)
In-Reply-To: <f3f323fa-cf8d-dec6-52bb-38c591a833d9@yandex.ru> (Dmitry Gutov's message of "Sun, 5 Nov 2023 01:16:08 +0200")
Hi Dmitry,
Thanks for working on this feature. I'm looking forward to using it.
Dmitry Gutov <dgutov@yandex.ru> writes:
> Attached is the patch along the lines that we discussed: a new command
> xref-find-extra currently bound to M-' just for the sake of this
> experiment (eliminating the need to set up define-key to try out the
> "fast" workflow).
That's was indeed convenient for testing the patch, although in the long
run there should probably be a different binding since `M-'` is already
bound to `abbrev-prefix-mark`.
> It uses the symbol at point or asks for it, then
> polls the backend for available kinds,
So far so good.
> does completing-read and asks the backend for definitions of that
> kind. And shows the list or jumps to the unique one.
Personally, I would prefer a `read-multiple-choice` alternative to
`completing-read` here, that would allow me to select the "kind" with a
single key press. Since there are rarely more than a few kinds to
choose from, in many cases `completing-read` introduces unnecessary
friction. Ideally, the backend should be able to choose whether to do a
`completing-read` or a "quick" `read-multiple-choice` on a case-by-case
basis. The backend can also associate stable `read-multiple-choice`
keys to the different kinds it support. WDYT?
> To have something to test, I implemented this for Elisp. However, all
> known kinds are already printed by the regular xref-find-definitions
> output in that backend. So the result turned out interesting, but a
> little impractical: with Elisp, we already make the choice between the
> kinds in the Xref output buffer, when that buffer is shown at all (as
> Eli pointed out, actually). So... we could proceed in that direction
> and recommend that all kinds of definitions would be added there.
Yes, I've noticed that redundancy of sorts while testing this patch, but
I think that selecting the definition kind explicitly with this new
command still provides a distinct experience compared to the
`xref-find-definitions`.
> But let's try to answer the question: which workflows would the
> attached approach work better for?
My above suggestion to provide "quick kind selection" with something
like `read-multiple-choice` would also be a general advantage here.
> Or perhaps the main value would be in actually having separate
> commands which could be bound to a submap with faster key sequences
> and/or to the context menu (with context-menu-mode on).
That's indeed an added value IMO. In that spirit, it might be better for
`xref-find-extra` to take the "kind" as an argument, so we can define
`xref-find-foo` as `(apply-partially #'xref-find-extra 'foo)`.
Interactively, `xref-find-extra` would still pick up the identifier first
and then prompt for the kind.
> Please try out the attached (with implementation for Eglot hopefully
> coming soon) and let me know your thoughts (you all).
One issue I had was with selecting "feature" as the definition kind.
Basically it doesn't seem to work for some reason, so for example typing
`M-' isearch RET feature RET` says "No extra-defs found for: isearch".
Also, for minor mode names, we currently suggest both "function" and
"variable" kinds, but they both point to the same `define-minor-mode`.
Ideally, we'd unify the two and simply suggest "minor-mode" as the
definition kind.
Best,
Eshel
next prev parent reply other threads:[~2023-11-05 8:16 UTC|newest]
Thread overview: 204+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-24 19:56 Adding support for xref jumping to headers/interfaces Spencer Baugh
2023-02-24 20:04 ` Eli Zaretskii
2023-02-24 21:29 ` Dmitry Gutov
2023-02-27 23:12 ` Stephen Leake
2023-02-27 23:34 ` Dmitry Gutov
2023-02-28 0:18 ` Yuan Fu
2023-02-28 16:05 ` Filipp Gunbin
2023-03-01 4:33 ` Richard Stallman
2023-03-01 12:50 ` Eli Zaretskii
2023-03-01 17:51 ` John Yates
2023-03-04 18:54 ` Stephen Leake
2023-03-04 22:24 ` Dmitry Gutov
2023-03-05 6:11 ` Eli Zaretskii
2023-03-05 12:06 ` Dmitry Gutov
2023-03-07 22:41 ` Dmitry Gutov
2023-03-08 14:58 ` Eli Zaretskii
2023-03-08 18:23 ` Dmitry Gutov
2023-03-08 19:49 ` Eli Zaretskii
2023-03-08 20:15 ` Dmitry Gutov
2023-03-09 6:13 ` Eli Zaretskii
2023-03-09 13:04 ` Dmitry Gutov
2023-03-09 15:36 ` Eli Zaretskii
2023-03-09 16:53 ` Dmitry Gutov
2023-03-09 17:31 ` Eli Zaretskii
2023-03-09 17:37 ` Dmitry Gutov
2023-05-16 21:10 ` Spencer Baugh
2023-05-17 11:46 ` Eli Zaretskii
2023-06-17 1:53 ` Dmitry Gutov
2023-06-20 15:31 ` João Távora
2023-06-22 19:22 ` Spencer Baugh
2023-06-23 5:52 ` Eli Zaretskii
2023-06-23 14:37 ` Spencer Baugh
2023-06-23 14:53 ` Eli Zaretskii
2023-06-23 15:03 ` João Távora
2023-06-28 13:31 ` Spencer Baugh
2023-11-04 22:43 ` Dmitry Gutov
2023-11-04 22:00 ` Dmitry Gutov
2023-11-04 22:24 ` João Távora
2023-11-04 22:29 ` Dmitry Gutov
2023-11-04 22:36 ` João Távora
2023-11-04 23:20 ` Dmitry Gutov
2023-11-04 23:16 ` Dmitry Gutov
2023-11-04 23:21 ` Dmitry Gutov
2023-11-04 23:24 ` João Távora
2023-11-04 23:27 ` Dmitry Gutov
[not found] ` <CALDnm51sWvw4wiipYkJRB8za_8zpWg2-0jpoJDy_5urEa5okzQ@mail.gmail.com>
[not found] ` <2752892c-4d27-1249-ca0a-6c24abbf1078@yandex.ru>
[not found] ` <CALDnm51P5kfWNofybvxbzVZNnF9DwV5f2ZDGx9ziToBF7cJR6w@mail.gmail.com>
[not found] ` <e043f63b-e997-805b-7f9a-64dcc0a9062e@yandex.ru>
[not found] ` <87zfzrybl1.fsf@gmail.com>
[not found] ` <57e53aae-bef9-d267-f7da-d4936fc37153@yandex.ru>
2023-11-07 9:36 ` João Távora
2023-11-07 22:56 ` Dmitry Gutov
2023-11-08 0:14 ` João Távora
2023-11-05 8:16 ` Eshel Yaron [this message]
2023-11-07 2:12 ` Dmitry Gutov
2023-11-07 17:09 ` Spencer Baugh
2023-11-07 23:02 ` Dmitry Gutov
2023-11-07 21:30 ` Eshel Yaron
2023-11-07 23:17 ` Dmitry Gutov
2023-11-08 0:21 ` João Távora
2023-11-08 0:33 ` Dmitry Gutov
2023-11-08 1:19 ` João Távora
2023-11-08 22:58 ` Dmitry Gutov
2023-11-08 23:22 ` João Távora
2023-11-08 23:34 ` Dmitry Gutov
2023-11-09 0:50 ` João Távora
2023-11-09 16:59 ` Spencer Baugh
2023-11-09 20:44 ` João Távora
2023-11-09 21:11 ` Spencer Baugh
2023-11-10 10:06 ` João Távora
2023-11-10 12:02 ` Spencer Baugh
2023-11-10 13:59 ` João Távora
2023-11-10 17:36 ` Spencer Baugh
2023-11-11 10:45 ` Dmitry Gutov
2023-11-11 11:17 ` João Távora
2023-11-11 12:38 ` Spencer Baugh
2023-11-11 20:49 ` Dmitry Gutov
2023-11-15 21:32 ` Spencer Baugh
2023-11-24 1:37 ` Dmitry Gutov
2023-11-24 21:43 ` Felician Nemeth
2023-11-25 2:20 ` Dmitry Gutov
2023-11-26 16:08 ` Felician Nemeth
2023-11-26 20:15 ` Dmitry Gutov
2023-11-26 20:37 ` João Távora
2023-11-27 14:35 ` Dmitry Gutov
2023-11-27 15:03 ` João Távora
2023-11-27 15:45 ` Dmitry Gutov
2023-11-27 16:04 ` João Távora
2023-11-27 16:23 ` Dmitry Gutov
2023-11-27 16:41 ` João Távora
2023-11-27 17:05 ` Dmitry Gutov
2023-11-27 17:09 ` João Távora
2023-11-26 20:40 ` João Távora
2023-11-27 14:43 ` Dmitry Gutov
2023-11-27 14:49 ` João Távora
2023-11-27 15:01 ` Dmitry Gutov
2023-11-27 15:19 ` João Távora
2023-11-28 0:18 ` Dmitry Gutov
2023-11-28 9:51 ` João Távora
2023-11-28 12:45 ` Dmitry Gutov
2023-11-28 15:02 ` João Távora
2023-11-28 16:32 ` Dmitry Gutov
2023-11-28 17:16 ` João Távora
2023-11-28 17:25 ` Dmitry Gutov
2023-11-28 18:38 ` João Távora
2023-11-27 15:28 ` Eli Zaretskii
2023-11-27 16:37 ` Dmitry Gutov
2023-11-27 16:45 ` João Távora
2023-11-27 17:40 ` Eli Zaretskii
2023-11-27 18:26 ` Dmitry Gutov
2023-11-27 20:50 ` Eli Zaretskii
2023-11-27 20:53 ` Dmitry Gutov
2023-11-26 20:30 ` João Távora
2023-11-27 15:17 ` Dmitry Gutov
2023-11-27 15:45 ` João Távora
2023-11-27 16:04 ` Dmitry Gutov
2023-11-27 16:27 ` João Távora
2023-11-27 17:22 ` Dmitry Gutov
2023-11-27 17:46 ` João Távora
2023-11-27 18:12 ` Dmitry Gutov
2023-11-27 23:25 ` João Távora
2023-11-28 0:30 ` Dmitry Gutov
2023-11-28 0:43 ` João Távora
2023-11-11 1:01 ` Dmitry Gutov
2023-11-11 1:04 ` Dmitry Gutov
2023-11-11 11:30 ` João Távora
2023-11-11 21:01 ` Dmitry Gutov
2023-11-12 18:40 ` João Távora
2023-11-13 0:27 ` Dmitry Gutov
2023-11-13 1:03 ` João Távora
2023-11-13 1:05 ` Dmitry Gutov
2023-11-13 1:16 ` João Távora
2023-11-13 1:41 ` electric-pair-mode vs paredit, was: " Dmitry Gutov
2023-11-13 1:53 ` João Távora
2023-11-11 0:58 ` Dmitry Gutov
2023-11-11 11:44 ` João Távora
2023-11-11 21:37 ` Dmitry Gutov
2023-11-12 18:59 ` João Távora
2023-11-13 1:37 ` Dmitry Gutov
2023-11-11 1:08 ` Dmitry Gutov
2023-11-11 11:22 ` João Távora
2023-11-11 20:54 ` Dmitry Gutov
2023-11-08 16:11 ` Spencer Baugh
2023-11-08 17:20 ` João Távora
2023-11-08 17:40 ` Spencer Baugh
2023-11-08 23:08 ` João Távora
2023-11-09 16:52 ` CCing thread participants through gnus+gmane Spencer Baugh
2023-11-10 15:51 ` Eric Abrahamsen
2023-11-10 16:18 ` Visuwesh
2023-11-09 17:07 ` Adding support for xref jumping to headers/interfaces Spencer Baugh
2023-11-11 0:07 ` Dmitry Gutov
2023-11-11 12:39 ` Spencer Baugh
2023-11-11 20:45 ` Dmitry Gutov
2023-11-08 23:06 ` Dmitry Gutov
2023-11-07 16:51 ` Spencer Baugh
2023-11-07 23:30 ` Dmitry Gutov
2023-11-08 17:25 ` Spencer Baugh
2023-11-09 0:08 ` Dmitry Gutov
2023-11-09 0:26 ` Dmitry Gutov
2023-11-09 1:06 ` João Távora
2023-11-11 0:16 ` Dmitry Gutov
2023-11-09 17:57 ` Spencer Baugh
2023-11-11 0:42 ` Dmitry Gutov
2023-11-11 13:00 ` Spencer Baugh
2023-11-12 1:50 ` Dmitry Gutov
2023-11-12 2:08 ` João Távora
2023-11-12 2:09 ` Dmitry Gutov
2023-11-12 2:25 ` João Távora
2023-11-13 1:02 ` Dmitry Gutov
2023-11-13 1:24 ` João Távora
2023-03-01 15:00 ` [External] : " Drew Adams
2023-02-28 21:40 ` John Yates
2023-02-28 21:53 ` Dmitry Gutov
2023-02-28 22:44 ` Konstantin Kharlamov
2023-03-05 9:59 ` Helmut Eller
2023-03-05 12:03 ` Dmitry Gutov
2023-03-05 15:57 ` Helmut Eller
2023-03-05 16:33 ` Dmitry Gutov
2023-03-05 17:19 ` Stephen Leake
2023-03-05 20:10 ` João Távora
2023-03-05 20:32 ` João Távora
2023-03-05 20:40 ` Dmitry Gutov
2023-03-05 21:04 ` João Távora
2023-03-05 21:21 ` Dmitry Gutov
2023-03-05 21:48 ` João Távora
2023-03-05 22:08 ` Dmitry Gutov
2023-03-05 23:00 ` João Távora
2023-03-05 23:40 ` John Yates
2023-03-06 12:22 ` Felician Nemeth
2023-03-06 13:15 ` João Távora
2023-03-06 13:23 ` Dmitry Gutov
2023-03-06 13:38 ` João Távora
2023-03-06 13:46 ` Dmitry Gutov
2023-03-06 13:52 ` João Távora
2023-03-06 13:50 ` Dmitry Gutov
2023-03-07 7:15 ` Yuan Fu
2023-03-07 19:58 ` Felician Nemeth
2023-03-07 20:44 ` Yuan Fu
2023-03-07 21:03 ` Dmitry Gutov
2023-03-06 14:09 ` Dmitry Gutov
2023-03-06 14:15 ` John Yates
2023-03-06 14:23 ` Dmitry Gutov
2023-03-06 14:43 ` John Yates
2023-03-10 0:57 ` Ergus
2023-03-10 21:55 ` Dmitry Gutov
2023-03-10 22:18 ` João Távora
2023-03-10 22:25 ` Dmitry Gutov
2023-03-11 11:50 ` João Távora
2023-03-10 23:45 ` Ergus
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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m1r0l41uon.fsf@dazzs-mbp.home \
--to=me@eshelyaron.com \
--cc=azeng@janestreet.com \
--cc=casouri@gmail.com \
--cc=dgutov@yandex.ru \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=fgunbin@fastmail.fm \
--cc=john@yates-sheets.org \
--cc=rms@gnu.org \
--cc=sbaugh@janestreet.com \
--cc=stephen_leake@stephe-leake.org \
/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 public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).