From: Dmitry Gutov <dmitry@gutov.dev>
To: "João Távora" <joaotavora@gmail.com>
Cc: Felician Nemeth <felician.nemeth@gmail.com>,
Spencer Baugh <sbaugh@janestreet.com>,
emacs-devel@gnu.org, Eshel Yaron <me@eshelyaron.com>,
John Yates <john@yates-sheets.org>, Ergus <spacibba@aol.com>,
Filipp Gunbin <fgunbin@fastmail.fm>
Subject: Re: Adding support for xref jumping to headers/interfaces
Date: Tue, 28 Nov 2023 02:18:19 +0200 [thread overview]
Message-ID: <ef741584-651b-e6ff-edcb-526bbdef782c@gutov.dev> (raw)
In-Reply-To: <CALDnm511xC7qDTv+s=Fmf-hSfQv+qVes5KSFHZEz5RywNmF6hQ@mail.gmail.com>
On 27/11/2023 17:19, João Távora wrote:
>>> Alright, so since this is contentious (who else but you is pushing
>>> this idea?)
>>
>> Indeed, I wonder if nobody else is interested in having the additional
>> commands have pre-defined bindings, or having the same bindings across
>> languages.
>
> Of course if you put it like that then EVERYBODY is interested in that.
> Everybody likes consistency, but this consistency you're proposing
> is a mirage. An naive Xref user would be very proud to use
> "xref-find-declaration" in 3 different languages but then would
> start to doubt xref that the things he and the backend author meant
> by declaration are entirely different.
It's not like things are very different now: a backend might fail to
implement "references", or the new "kinds" thingy, leaving the most
recent addition not working anyway.
Or, again, different languages might have different notions for what a
"definition" is. E.g. C vs. TeX.
> Again, leave this to major modes, which is what we always do (or to backend
> which in 95% of cases would live in the major mode when they are
> language-specific).
I wonder where you're getting this statistic from: advanced language
analysis features don't usually live in major modes, not in the current
state of the Emacs ecosystem.
>>> what about we start with 0 in xref.el. We can always
>>> add to 0, no problem, but taking away from some other number
>>> isn't so easy.
>>
>> We could indeed start with 0, but then I already see the same set of
>> extra commands supported in Eglot, Elisp, lsp-mode
>
> They only exist in Eglot and LSP-mode because these are LSP things,
> it makes full sense they would exist in any Emacs/LSP interface.
Before LSP, they would similarly make sense for eclim, or omnisharp, or
rtags/irony-mode, and etc. And that would be the case after LSP, unless
the current crop of popular languages is simply washed away. We might
have taken the names from LSP where they're nicely categorized, but they
correspond to existing navigation features in IDEs that's been there for
years.
> Elisp? What commands are you talking about, only if you force them.
> I see no elisp-find-{declaration,type-definition,implementation}
> or anything of the sort.
>
> The 7 Elisp cross-reference kinds you defined in your original
> patch are
>
> "defalias"
> "face"
> "function"
> "constructor"
> "generic"
> "variable"
> "feature'"
That's a good critique. But the list above is a different ontology than
the declaration/implementation/type-definition "drawers" we were talking
about. I wonder how much of it really language-specific.
E.g., a C++/Java/Ruby program also has symbols like
modules/namespaces/classes/methods/functions... Variables, too. Some
have global ones, some allow one local variables.
What makes the drawers called
declaration/definition/implementation/type-definition different? I think
that these ones, in many cases, apply several at once to the same
symbol, and not just the same name, but the same entity in the code,
such as for example a method -- one method can have a declaration and an
implementation (which is these are the "definition" -- perhaps both --
is up to interpretation). Or a variable can have a definition (or
declaration -- for variables they're usually the same) -- and a type
definition. Point is, there is no way for the Xref backend to decide
which of these you want to see when invoking "M-.", that's why there are
separate actions for them in the protocol.
Whereas for Elisp's
defalias/face/function/constructor/generic/variable/feature, 95% of the
time the choice is easy to detect from the usage context. Same for
modules/classes/methods for Ruby or C++. That's actually the reason why
I felt my implementation for Elisp's "kinds" was useless -- it's simply
slower and more awkward to work with than the existing 'M-.' (which has
the automatic "infer namespace" functionality since 2021 courtesy of
Mattias).
So we could also say that
declaration/definition/implementation/type-definition are the names of
"search actions" whereas namespace/class/face/function are "symbol
namespaces". And to make interaction with "symbol namespaces" more
useful, I'm guessing we would need something more - e.g.
namespace-specific symbol completion. For xref-find-all-definitions (or
whatever new name it has) to prompt for the namespace first and then
fetch its specific identifier completion table (all functions or all
faces, etc). And that, by the way, could also work in different
languages, with very similar nomenclature (I think only "face" in the
above list is really Elisp-specific).
I concede that the "search actions" such as
find-declaration/implementation (and especially type-definition) are
less useful in Elisp than in OO languages where inheritance (or at least
traits/mixins) are used more widely. Maybe just for the cl-generic code,
which is a minority. OTOH, perhaps they would be more relevant in CL?
>>>> and to allow frictionless extensions for special capabilities.
>>>
>>> As to frictionless extension, the macro I proposed already
>>> xref-define-finder seems the easiest way by far.
>>
>> Sorry, I can't find it.
>>
>> But the definition of xref-find-declarations takes about 3 lines. There
>> is not much potential for making it even shorter.
>
> It's very similar and analogous to:
>
> (defmacro eglot--code-action (name kind)
> "Define NAME to execute KIND code action."
> `(defun ,name (beg &optional end)
> ,(format "Execute `%s' code actions between BEG and END." kind)
> (interactive (eglot--code-action-bounds))
> (eglot-code-actions beg end ,kind t)))
>
> And allows us to control exactly the 'interactive' spec of such
> commands to give us consistency among them.
I'm wary of using macros as framework/library interface in Elisp because
unless they are very stable, they can cause versioning problems when
upgrading or reverting to an earlier version. You change a macro, but a
dependent package is already installed and byte-compiled, and there
won't be a recompilation until its next update. We might not even intend
to change them much, but then you don't always anticipate a bugfix.
next prev parent reply other threads:[~2023-11-28 0:18 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
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 [this message]
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=ef741584-651b-e6ff-edcb-526bbdef782c@gutov.dev \
--to=dmitry@gutov.dev \
--cc=emacs-devel@gnu.org \
--cc=felician.nemeth@gmail.com \
--cc=fgunbin@fastmail.fm \
--cc=joaotavora@gmail.com \
--cc=john@yates-sheets.org \
--cc=me@eshelyaron.com \
--cc=sbaugh@janestreet.com \
--cc=spacibba@aol.com \
/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).