Re: Adding support for xref jumping to headers/interfaces

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

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

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

<eyeroll> First, who does that?  I thought you were concerned about
the OOtB experience for non-powerusers.  Secondly, if something called
"definitions" is used for things that are patently not "definitions"
that thing is incorrectly named, period.  It's not because that editor
thing was misnamed by its creator that magically my C++ declaration is
now a definition, too.

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

They're absolutely NOT semantically similar, only very superficially,
like, yes, most users of this list are vertebrates. I don't mean to
be pedantic about languages but there's really a world of difference
between a C declaration and the things you can say with a DEFGENERIC
call, or what their specific intended purposes are for the language
designer. Any user of these two languages (C and Common Lisp) languages
will know this very well.  In my 15 years CL experience I've known exactly
0 people calling defgeneric forms "declarations".

But I presume you're talking about completing-read?  I would type 'dec'
in the first and 'gene' in the second and so would probably the masses.
But the list is so small, I'd probably just scroll down one or two
positions.

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

No, not pointless at all.  My main use case for this is to
first invoke the command on a given place of interest and _then_
ask myself what I want to see of that symbol. "All references",
"definitions", "declarations"?

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

So, awright.  Do you really really want to rename "extra" to
"definitions"??  is that the blocker?   Makes 0 sense, but if
there's no talking you out of it then I guess users like me
can swallow  the awkwardness and translate "definition" to
"thing" in their  minds.  And we have strategies for renaming
things anyway.

> > 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 exactly is compromised by that patch?  And do you not agree
it is minimally useful?  You wrote the thing! Noone forced you to.

> What about showing the combined set?

Sure, that can be done.  Just have xref invoke the generic function
for as many kinds as the backend reports.