Re: Adding support for xref jumping to headers/interfaces

[Eli Zaretskii]

> From: Spencer Baugh <sbaugh@janestreet.com>
> Date: Thu, 22 Jun 2023 15:22:25 -0400
> 
> João Távora <joaotavora@gmail.com> writes:
> > 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.
> 
> Do you envision that eglot-find-typeDefinition would also be covered by
> xref-find-definitions in this way?  The type defintion feels a bit
> different from others.
> 
> In any case, it seems to me that C-u M-. would be a good way to say
> "return all different kinds of definitions" to xref-find-definitions.
> Then the user could just switch to the one they want in the *xref*
> buffer.  This keeps the basic M-. operation fast, while making it easy
> to jump to other kinds of definitions.  Seems perfect.

Why does this need a separate key sequence?  M-. already knows how to
cope with more than a single candidate returned by the backend.  How
is this case different?