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.