Re: Adding support for xref jumping to headers/interfaces

[Eli Zaretskii <eliz@gnu.org>]

> From: Spencer Baugh <sbaugh@janestreet.com>
> Date: Fri, 23 Jun 2023 10:37:30 -0400
> Cc: emacs-devel@gnu.org
> 
> On Fri, Jun 23, 2023 at 1:52 AM Eli Zaretskii <eliz@gnu.org> wrote:
> >
> > > 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?
> 
> Merely that M-. currently usually returns only one candidate, and when
> it returns multiple candidates it pops up a buffer, which is annoying
> if you only ever want one of the candidates.

Isn't that what you wanted when you said "return all different kinds
of definitions"?

M-. shows a buffer with several candidates when it cannot find only
one that fits the name you typed.  That is rare, but it does happen.
AFAIU, you have described one situation where this will happen.  So I
think the behavior of M-. is exactly right in that case, and we don't
need any new key sequences or commands.  Or what am I missing?