Re: Adding support for xref jumping to headers/interfaces

[João Távora]

Dmitry Gutov <dgutov@yandex.ru> writes:

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

Lisp macros are great for cutting down repetition.  If all we want to
say is "this mode for language foo supports finding xref finding of
'declaration' it could even be as simple as

   (xref-define-find-command :declaration foo-mode-map)

at the top-level of foo-mode.el.

An Eglot xref backend would pick up on this ':declaration and hook it up
to LSP's 'textDocument/declaration' (if it makes sense).  Other xref
backends would do whatever.  A default binding in foo-mode-map could be
chosen by xref.el, answering your other objection.  Finding these lines
in major-modes be as common as say, easy-menu-define.

Additionally, if the Foo language additionally has "interfaces", and
"macros" and "gremlins" and the FooLS server supports those (via LSP
extensions which are somewhat common), then foo-mode.el can use some
similar xref.el macro for definiting specific commands for those.  Their
implementation would use jsonrpc-request for the custom
'x/foo-find-gremlins' JSONRPC request, eglot-current-server for finding
the server, and xref-make-match for making the objects.

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

"This command is not supported" errors or commands with same bindings
that do something else are perfectly possible and pretty common in
Emacs.  But they are not the best examples of UI consistency.

> 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 doesn't know about languages, nor should it.  It's also not
"natural" for Eglot to provide commands and UI: its job is to hook up
Emacs' facilities with LSP interfaces.  The first bullet in eglot.el's
commentary explains this.

Anyway, if you have like your approach, don't mind me.  I'm just
suggesting alternatives in hopes they can be useful, not standing in
your way.  If you want add things to Eglot's xref backend, that's fine
in principle, but it's better coordinate first.

João