Re: Adding support for xref jumping to headers/interfaces

[Dmitry Gutov]

On 05/03/2023 23:48, João Távora wrote:
> On Sun, Mar 5, 2023, 21:21 Dmitry Gutov <dgutov@yandex.ru 
> <mailto:dgutov@yandex.ru>> wrote:
>
>      > Which modes? The ones where "declaration" is a thing.
>
>     So we'll have a dozen different commands called 'xxx-find-declarations'
>     which will be implemented the same (?) way? Bound to the same key
>     sequence?
>
>     If there a particular point to doing that? Do we expect other modes to
>     reuse the same binding to do something else? That will reduce UI
>     consistency, at the very least.
>
>
> Implementation could be trivial, xref could even provide a 
> command-defining macro.

Right. So we'll have a dozen commands with the same two-line definition, 
different names, but the same binding.

> Consistency should be evaluated considering the two approaches. Is it 
> more consistent to have an xref command that doesn't really make sense 
> in a another dozen languages?

Having a common binding and a common xref backend method to dispatch to 
simplifies things. The major modes which don't have the notion of 
'declaration' will have options: do nothing (and simply have the command 
return an error), or rebind the keys to a different command.

Note that whether the command works will also depend on the current Xref 
backend. etags will likely support declarations in a smaller set of 
languages than LSP clients. And yet some specialized packages can cover 
some of the remaining languages that LSP doesn't reach.

A major mode author won't necessarily be able to tell in advance whether 
an Xref backend will exist that would cover their language with this 
particular feature.

>      > Mind you the same point made for xref can be made about LSP,
>      > language-agnostic on paper, but many a language-specific concept
>     poorly
>      > disguised in there. But I see no reason to copy that flaw.
>
>     I don't mind the idea of extensibility (and packages like lsp-mode do
>     this already: IIRC they have commands called lsp-find-declarations and
>     lsp-find-implementations).
>
>
> As commands, this would be bloat in Eglot. But Eglot can give access to 
> these LSP interfaces.

If we don't want to extend xref.el with such commands, packages like 
Eglot seem like the natural alternative, though. Because they can know 
which commands the LSP protocol can support. Eglot could even query for 
that support at runtime for a particular language, I think.

>     But insofar as languages do have shared syntactic concepts, I don't see
>     why we wouldn't want to include more common ones.
>
>
> "Definition" and "references" are universal enough. "Declaration", 
> "class" and others, not so much. But that's just my 2c.

declarations/implementations are definitely less universal than the 
first two. But I don't see how they will hurt: if we decide to extend 
the list, the main difficulty will just be choosing the bindings, I think.