Re: Adding support for xref jumping to headers/interfaces

[Dmitry Gutov]

On 27/11/2023 17:45, João Távora wrote:
> 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.

In 20-30 years or so?

> > 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 don't know about aging well: most of the aforementioned ones have had 
meaning for the whole 15 years of my career (that's not too long, but 
still), and typeDefinitions is apparently something more helpful in 
newer popular languages which rely on type inference (so there's rarely 
a type annotation nearby to 'M-.' on).

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

Ultimately, we could also show-hide definitions depending on which kinds 
the current backend(s) expose. I.e. a set of commands might be 
dynamically generated via dispatch (like project-switch-project does), 
or they indeed can be traditional commands. The latter has advantages: 
the users can examine and rebind them using the traditional methods.

Indeed, some commands will be "unsupported" in some languages. I don't 
see much issue with it: if the language mode (major or minor) has a 
better command to use instead, they can [remap ...] it. And they will 
have a common prefix to add their own additional commands too.

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

Why don't you read up on the difference between 
xref-show-definitions-function and xref-show-xrefs-function. Those are 
not implementation details but something that affects user experience. 
And users can customize one or the other, which correspondingly affects 
dispatches which go through one or the other.

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

Would it be better if the user has to type 'dec' in C mode but 'defg' in 
emacs-lisp-mode to get to a semantically similar set of results?

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

And that's great -- please continue to press M-? for that purpose.

But if 'references' joins the "definition kinds", then the command to 
"find all definition kinds" will become pointless. And we already have 
command to "find all references".

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

See above.

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

We're yet finding that.

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

I said that it matches the docstring, not that it's ideal for Eglot.

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

What about showing the combined set?