emacs-devel
[Top][All Lists]
Advanced

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]