Re: Adding support for xref jumping to headers/interfaces

["João Távora" <joaotavora@gmail.com>]

On Mon, Nov 27, 2023 at 3:17 PM Dmitry Gutov <dmitry@gutov.dev> wrote:

> > In my view, again, we should not limit ourselves to a triad
> > of kinds clumsily inherited from LSP.  We should limit that LSP
> > concept to Eglot.  It is not flexible enough, because it can't
> > be.  But Xref is for much more than LSP.
>
> What it seems you are saying is that we never should try to extend the
> set of definition-finding commands above what's already in xref.el.

Not necessarily.  I'm saying we shouldn't make that a priority
or the rest of this useful feature contingent on that.  If we
someday come to the blissful epiphany that every language ever to
be and to have been has the fundamental concept of a watermelon in it,
then we can think about xref-find-watermelon.

> Because it seems clear that we're unlikely to find a more
> widely-supported set of additional kinds that the aforementioned triad,
> in any medium-term future.

They're not particularly well supported, they won't age well.  LSP
uses that trio for two reasons: it doesn't have major modes or a
programming language, and it's driven in part by commercial vendors of
specific large language implementations.  But Editors like VSCode still
have "plugins" akin to our major modes.

I wouldn't be surprised if these plugins don't have total freedom over
what part of LSP they expose to the user.

Opening VSCode on a C++ file for example, I see "find definitions" and
"find references" have dedicated bindings, but "declaration" and
"typeDefinition" do NOT. And "implementation" isn't even there as it
doesn't make much sense in C++.

> >> Like now, for example, many will likely stay with CC Mode for a while
> >> because of it more lax behavior in macro-heavy codebases, where
> >> c-ts-mode chokes and shows syntax errors.
> >
> > Whatever you are suggesting, I don't understand.  Whatever xref backend
> > is written for c++-mode with its special-purpose commands for finding
> > C++ things can be used for both c++-mode and c++-ts-mode.  Just put that
> > code in a special file.
>
> What about default key bindings?

I've already answered that in a nearby email.

> > I think this is a mistake and a regression from xref-find-extra.
> > The command should be called xref-find-all, xref-find, or simply
> > xref, since definition is a category that doesn't span a lot of
> > useful cross-referenceable constructs in many languages. In C++,
> > for one, a declaration is absolutely _not_ a definition.
>
> It's a "definition" in at least one Xref-related sense: it should be
> dispatched through xref-show-definitions-function.

So it's a "definition" because the xref.el author called an
implementation detail a "definition"?  What does the user possibly
care about that?

> Further, I'm not sure that when a user looks up all definition-related
> things for a symbol, they wouldn't want to see the "declaration". In
> fact, if we classify 'defgeneric' as declarations and 'defmethod' as
> implementations, I'm pretty sure I would want to see the former in the list.

Of course, if the world is painted in the three LSP primary colors,
every other color will have to be truncated to that.  But it doesn't
mean the world gets any prettier.

> And you yourself mentioned that "type definitions" might be suitable for
> that list (which I found surprising at first). So it seems clear that
> there is no single red line.

Precisely.  So don't go making those lines.

> o show me "references" as one of the kinds of thing to search for.
>
> Then the list of results would drown in "references", wouldn't it?

But if I want to see references to the given symbol at point, that's what
I want!  I press M-? xref-find-references all the time in Eglot.

> For experimentation.

Then perhaps we could cut another less contentious branch off
279203199a2d10677e42747476b39394a4184a78

Over that branch we can rename Eglot kinds to strings and "extra"
to "all".  I'm sure that's less contentious, a good candidate
for master and not incompatible with evolving into whatever
results of your experimentation.

> > If you are proposing this is brought to master for experimentation,
> > and if you are wary of this step, then may I suggest we push the older
> > more conservative version, perhaps with some naming changes?
>
> I'm not yet seeing a common basic version for which there would be
> agreement. You just called a renaming a mistake and disagreed with the
> principle of what "definition kinds" should be.
>
> > This new version isn't something we can roll back easily, while the
> > more conservative approach could eventually be enhanced with the three
> > "popular kinds" later on.
>
> I'm not proposing any merge to master yet.

Well I am, but not of that code, at least not yet of that code.
Merge to master something useful that doesn't compromise us.

> >> What does everyone think?
> >
> >> xref-find-all-definitions is an interactive native-compiled Lisp
> >> function in `xref.el'.
> >
> >> at point, prompt for the identifier.  Interactively, show matches
> >> for all supported kinds.  When invoked with prefix argument,
> >> prompt for KIND.
> >
> > I can't get this to work btw.   If I add a prefx argument, it
> > prompts me for the identifier, which I don't want.
>
> What's what the docstring says, and it's what Felician brought up as a
> problem. Do you want two separate commands? And one of them would always
> prompt for the kind to use?

No, it's not.  It starts prompting me for identifiers which for LSP
is useless.  Eglot has no way to know which kinds of reference it has
for arbitrary identifiers not at point.

The only useful way for this to work in Eglot would be to prompt
for KIND and _then_ show the results, which may be empty.

Anything else doesn't make sense for Eglot, for LSP-specific
reasons beyond my control which I've already explained.

João