Re: Adding support for xref jumping to headers/interfaces

[João Távora]

On Wed, Nov 8, 2023 at 10:59 PM Dmitry Gutov <dgutov@yandex.ru> wrote:
>
> On 08/11/2023 03:19, João Távora wrote:
> > On Wed, Nov 8, 2023 at 12:33 AM Dmitry Gutov <dgutov@yandex.ru> wrote:
> >>
> >> On 08/11/2023 02:21, João Távora wrote:
> >>> On Tue, Nov 7, 2023 at 11:18 PM Dmitry Gutov<dgutov@yandex.ru>  wrote:
> >>>
> >>>> Joao didn't want to have such definitions in Xref. I'm still on the
> >>>> fence, personally.
> >>> What don't I want?  I haven't read this wordy subthread but it seems
> >>> Eshel is proposing exactly what I changed in xref-find-extra: take "kind"
> >>> as argument.
> >>
> >> Sorry: you didn't want those definitions in _Eglot_. Not in Xref, that
> >> was a mistype.
> >
> > Ah. Well, first, it a fact that I _have_ them in Eglot, and I'll
> > keep having them, because they've been there a long time.
>
> The normal practice is to wait a little while until the new "core"
> feature is available for a lot of users (perhaps skipping a few Emacs
> versions, or - more bravely - wait for the next one and then just raise
> the minimum xref version required), and then declare the built-in
> versions obsolete in favor of the upstream.
>
> The period before obsoletion is not as important as the agreement to do
> that - because then we will be talking whether the "proper"
> functionality should be shaped as a number of new commands (one per
> kind), or a dispatching command, or both. Or something else.
>
> For the purpose of such design discussion, simply using Eglot's commands
> is not a good choice.

I don't get this talk of obsoletion.  I don't want to obsolete anything.
The Eglot commands are there because they fulfill a need that
generic xref.el commands will never be able to fulfill.

> > And it's not really relevant that I didn't _want_ them.  If I had
> > the choice back then between recommending existing xref commands
> > and adding new commands to Eglot, of course I wouldn't have added
> > them.  But I hadn't, so I did. Pretty simple.  So I don't understand
> > the argument you're making against Eshel's and my suggestion.
>
> Since you didn't want them and argued that they shouldn't be in Eglot,
> it seems natural to assume that you would be happy to obsolete them in
> favor of built-in functionality.

You assume wrong, or at least it is not something really relevant
to this discussion.  If xref-find-extras had been around at the time, I
would have argued that users could use that or simply that xref
command-defining macro to make their own johndoe/find-thingy commads.
Or major modes could do it, perhaps even better.

But neither was available at the time, so I did those commands and they won't
be obsoleted any time soon.

> >>>> Or it would be nice to hear from someone who have tried out Eglot's
> >>>> integration and found more upsides there.
> >>> If you want that to happen, the only realistic way to have good
> >>> feedback from anyone else other than emacs-devel nerds like me and you
> >>> is to release an Eglot version with  this feature, which we can change
> >>> later (even non-backward-compatibly, within a reasonable time frame).
> >> That seems like a last-resort type of approach, for this particular
> >> discussion.
> >
> > Not really, just being pragmatic and suggesting a way for you to
> > get the opinions from Eglot users that you wrote you wanted.  There
> > isn't a significant amount of engaged Eglot users in this discussion
> > that are going to try the patch.
>
> Feedback is good, but I prefer to arrive at some sound design first,
> even if it doesn't do everything anyone might want. And then test it on
> a wider audience.

The base of the current design, the xref-backend-extra-defs and
xref-backend-extra-kinds, is more than sound enough. IMO could
some micro-enhancements like better names and support for non-string
kinds, but that's completely secondary.

I also think the xref-find-extra you created and I tweaked is pretty
good.  completing-read is definitely the correct choice to select
the kind.  Not clumsy at all IMHO.  But the ideas you've been offered
(by Spencer?) about enhancing it via a prefix argument or extra variable to
ask for all kinds all at once are pretty good too.  And you can do this
later, probably even backward-compatibly.

João Távora