[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Adding support for xref jumping to headers/interfaces
From: |
Spencer Baugh |
Subject: |
Re: Adding support for xref jumping to headers/interfaces |
Date: |
Fri, 23 Jun 2023 10:37:30 -0400 |
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. Most of the time, for
most users, a user will only want the single candidate which is
currently returned by M-. (which is the implementation/definition of
the identifier), so we should avoid adding multiple candidates by
default.