Re: Adding support for xref jumping to headers/interfaces

["João Távora" <joaotavora@gmail.com>]

On Wed, Nov 8, 2023 at 11:34 PM Dmitry Gutov <dgutov@yandex.ru> wrote:

> >> For the purpose of such design discussion, simply using Eglot's commands
> >> is not a good choice.
> >
> > I don't get this talk of obsoletion.  I don't want to obsolete anything.
> > The Eglot commands are there because they fulfill a need that
> > generic xref.el commands will never be able to fulfill.
>
> If Eglot keeps its commands (which I don't mind that much), then any
> comparable package should also be allowed and even encouraged to define
> its own commands. And we should document that somewhere, too.

Not necessarily encouraged OR discouraged.  Just possible.  Why
complicate things?

> But that design ends up far from the original "Eglot shouldn't do this"
> sentiment that I have read before.

It might be useful to check this code in eglot.el.  Code actions are
very similar to what we have with definition finding.  Look:

  (eglot--code-action eglot-code-action-organize-imports
"source.organizeImports")
  (eglot--code-action eglot-code-action-extract "refactor.extract")
  (eglot--code-action eglot-code-action-inline "refactor.inline")
  (eglot--code-action eglot-code-action-rewrite "refactor.rewrite")
  (eglot--code-action eglot-code-action-quickfix "quickfix")

This is exactly the same, with the exception that refactor.el doesn't
yet exist (working on it) and 'eglot--code-action' is thus not
refactor-define-code-action

Now, I don't use those commands, I use eglot-code-actions directly or
Flymake clicky diagnostics, but users requested those commands, so I put
them in eglot.el.  They could be in some eglot-ui.el.  But it doesn't
mean eglot-code-action (soon to be refactor-code-action and which, like
xref-find-extras, uses completing-read) is any less useful or
incompatible with the commands created by these one-liners.

To make myself clear: when I say I don't like to add UI to eglot.el,
it means I don't like to do it when a clean abstraction for a similar
concept can be cleanly implemented, or even already exists, elsewhere
for other non-LSP things.  But sometimes those two conditions simply
aren't true and can't easily be made true, like here.  So instead
of endless soul-searching about what I would like a zillion language
servers and an Microsoft-owoned VScodish couldnt-care-less-for-Emacs
protocol to look like, I create the simplest possible Eglot UI and
reuse as much code of non-Eglot UI libraries as possible.

> And also, Eglot keeping its commands seems incompatible with (or at
> least counter to) the approach where is an existing set of "extra"
> commands that is bound to some prefix map (e.g. one assigned to M-').
> Because if there are many different commands called *-find-declarations,
> it seems difficult to put them all on the same key.

Eglot doesn't put any commands in any keymap.  It just offers them.

> > But neither was available at the time, so I did those commands and they won't
> > be obsoleted any time soon.
>
> Reasons being..?

That we can't come up with alternatives to exactly that interface,
obviously.  When you do, I'll obsolete them.  But do you want to hardcode
things like LSP "typeDefinition" and Sly's "who-macroexpands" somewhere
in xref.el?  How would that work?

> > The base of the current design, the xref-backend-extra-defs and
> > xref-backend-extra-kinds, is more than sound enough. IMO could
> > some micro-enhancements like better names and support for non-string
> > kinds, but that's completely secondary.
>
> It's not secondary if people will start adapting their backends to it.

If that's even a problem -- like there's going to be a plethora
of backends doing that (how many third party xref backends are there?)
-- strings-for-kinds can still be supported and  you have obsolete alias.
So yes, completely secondary.

> E.g. the term "extra" seems more like a misnomer now, given that people
> seem to want that command to include the kinds already present in
> "definitions". And they might constitute the majority of those "kinds".

Yeah, "extra" should be or "by-kind".

João