Re: Adding support for xref jumping to headers/interfaces

[Dmitry Gutov <dmitry@gutov.dev>]

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

It doesn't take a power user to use the Customize interface to set 
xref-show-definitions-function to xref-show-definitions-completing-read.

Who uses that? I do, for example. And the people who asked for it (see 
https://lists.gnu.org/archive/html/emacs-devel/2020-11/msg00824.html). 
There are also third-party packages which provide alternative UIs 
through these options (e.g. ivy-xref and helm-xref).

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

It's about "set of things where I usually want to pick only one and jump 
to it" versus "set of things which I usually want to see the full list 
of, which stays around".

You can say that "definition" is perhaps not an ideal term for the 
former. But the distinction is useful, and if you have better naming 
suggestions, go ahead.

Until now the only built-in commands which went through that dispatcher 
were the variations of xref-find-definitions, so the name wasn't a problem.

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

The combined view, as implemented in the current 
xref-find-all-definitions by default, will then just show references.

Why would you want to also be able to reach "references" through that 
interface anyway?

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

Like I said, they are not "extra" because they will on most cases 
include the kinds already shown by xref-find-definitions. I'm open to 
other names, but please keep the intended semantics in mind (see above).

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

I voiced my doubts in the very first message that patch was attached to. 
And that it's experimental. It's also like 20 lines total. Let's keep a 
perspective.