Re: Adding support for xref jumping to headers/interfaces

[Dmitry Gutov <dmitry@gutov.dev>]

On 09/11/2023 03:06, João Távora wrote:
> 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.

Perhaps. But that's still not the definition of the symbol. It would 
more-or-less align with rust-analyzer's interpretation, as I see it.

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

Okay. That's an interesting indirection, and indeed it might be 
difficult to make it work otherwise via LSP.

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

It's less useful if one considers that in the resulting interface you 
never just jump to the definition of the said variable, even if it's 
found unambiguously. You would always have to choose between the 
variable and its type to jump to.

In that context, an additional command which would collect "everything 
to show about a symbol", including type definition, makes sense. For the 
less frequent cases when you want a more through overview. It could 
default to that behavior (asking for individual kinds otherwise), or 
have some kind called 'all' which would do this. I'd probably choose the 
former.

> 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 :-)

That's poetic.

Still, this change needs to work well for both LSP (an important backend 
these days) and for others. If we find ways to make switching between 
backends more seamless, it's an improvement.