Re: Adding support for xref jumping to headers/interfaces

[João Távora]

On Thu, Nov 9, 2023 at 12:27 AM Dmitry Gutov <dmitry@gutov.dev> wrote:
>
> On 09/11/2023 02:08, Dmitry Gutov wrote:
> > Do you know which category does "eglot-find-typeDefinition" falls into,
> > and why? Aside from the fact that it, historically, uses a separate
> > endpoint.
>
> Hm, according to
> https://github.com/rust-lang/rust-analyzer/issues/2541#issuecomment-565166660,
> "find-typeDefinition" goes to the definition of the type of the current
> variable (at point).

That's rust-analyzer interpretation.  In practice, servers can do what they
want.  This is the LSP description

    The go to type definition request is sent from the client to the server
    to resolve the type definition location of a symbol at a given text
    document position.

For example, an Elisp language server could use that to go to the place
where the  `typeDefinition` of a given symbol is set on that symbol.

> That probably means it doesn't really fit with the rest of the commands
> we're discussing, e.g. because the identifier it works on is actually a
> type name

Not in rust-analyzer, at least judging by what you described.  Seems
like the identifier it works on is a variable name, which rust-analyzer
then associates with the type (being a strongly typed language it knows
that) and then you get to the place where that type is defined.
Super-reasonable, for rust.

> (so the completion should be across types? ideally, at least,
> if LSP supported that). Anyway, it shouldn't be mixed into "find
> definition", at least if we go by rust-analyzer's meaning of it.

Actually, no.   Precisely in rust-analyzer's case it could be mixed.
I see somewhere a reference to a variable, I do that command you're thinking
of and get the definition of the variable and the definition of the type of the
variable, both useful things.

But you're right that it won't make sense for every possible
conceivable language or server.  But just don't worry.  Leave that
concern to server developers and LSP users.  You're not going to
magically fix LSP with the xref.el feature.  The Emacs-LSP marriage
is never quite perfect, but it gets a lot of love.

Exactly like any good marriage should :-)

João