Re: Adding support for xref jumping to headers/interfaces

[Dmitry Gutov]

On 17/05/2023 00:10, Spencer Baugh wrote:
> An option I didn't mention originally: Perhaps xref-find-definitions
> could just show both implementation and interface.  That would remove
> the need for any new keybindings.  The UI might be worse but perhaps
> it could be improved.
>
> This is inspired by this comment:
> https://github.com/joaotavora/eglot/issues/302#issuecomment-534202561
>
> The relevant excerpt:
> > By the way, on a tangent, I think it's a mistake on LSP's part to
> > import C++/Java's ecosystem of possible symbol loci. In Common Lisp,
> > there are many different types of construct associated with a symbol
> > and they are all "definitions". A good IDE like SLIME will use
> > something akin to xref-find-definitions (indeed xref is modelled after
> > SLIME) and categorize them properly in the result buffer if there is
> > more than one. So the command should have been textDocument/definition
> > with some kind of subtype parameter, or at least this is where xref
> > should evolve to, i.e. xref should keep the single command
> > xref-find-definitions and maybe augment it with some "definition-type"
> > parameter.

It is of course the prerogative of the backend to choose which locations 
to return as the list of definitions. Some backends/languages might as 
well include interfaces in the list.

One problem with that, though, is that we're doing some things 
differently from SLIME. In particular, we try to make it easy to jump to 
a specific definition as quickly as possible. If there is just one 
definition found with a given name, we don't even prompt to choose. We 
also have an option for xref-show-definitions-function like 
xref-show-definitions-completing-read which also tries to make things 
faster using completing-read. If other kinds of locations are added to 
the list, the odds of getting duplicates get higher, slowing down the 
interaction. So it's probably a good idea to hide some location kinds 
behind prefix argument, or a separate binding.

That brings me to another question, though. Can we assume that all 
"extra" searches should be of the "definition" type? Meaning that the 
results display should go through xref-show-definitions-function and not 
through xref-show-xrefs-function. If yes (and the ones that have been 
brought up in this discussion -- "implementations", "declarations", 
"type definitions" -- seem to fit that pattern), then good.