Re: Adding support for xref jumping to headers/interfaces

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

On Sat, Jun 17, 2023 at 2:54 AM Dmitry Gutov <dgutov@yandex.ru> wrote:

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

I see no problem with that, but it might be interesting to keep the
backend plug-in mechanisms generic enough to eventually enable
different types of UI.

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

If I remember correctly, SLIME (and SLY) have at least two types of
"reference" searches: "who calls" and "who expands".  They create the
typical ((file -> list of matches)...) listing in an SLIME xref buffer.

In connection to the earlier comment, SLIME uses M-? to
slime-edit-uses, which is similar, but not equivalent to our
xref-find-references.  Here, if I remember correctly, the xref
buffer is built like this:

who-calls
   file-less-function-that-calls-1
   file-less-function-that-calls-2
other-type-of-reference
   file-less-function-that-expands-3
   file-less-function-that-expands-4

of course who-calls and who-expands never share an xref buffer.

João