Re: Adding support for xref jumping to headers/interfaces

[João Távora]

On Fri, Jun 23, 2023 at 6:18 AM Spencer Baugh <sbaugh@janestreet.com> wrote:
>
> 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.


Depends on "the way" but yes, eglot-find-typeDefinition shouldn't exist.  Two
possibilities at least and we don't have to implement them all at once.

1. "type" should be one of the "extras" for the new xref-find-extra command.
   This is what I think is the current thinking here.

2. if we're willing to add another level of hierarchy to the current *xref*
   buffer and segregate results by file and category instead of just by file
   as is done currently.  Or make this configurable so the user can
   segregate just by category.  Or present the category as a tag.  Many
   ways to skin this cat.

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

That is not the SLIME way and C-u M-. already does something else.  But
I get your point.

> (Well, literally C-u M-. won't work, because prefix argument for
> xref-find-definitions already is used to cause it to prompt for an
> identifier.

Yup exactly.  SOmetimes this is solved by adding two C-u.  Sometimes
it makes sense.  Not sure here.


> But something close to that, perhaps.  Maybe this can be
> C-M-?)

That is xref-find-references.  Which curiously, in SLIME/SLY is "find
uses" and segregates results by category, hiding the file.