Re: Adding support for xref jumping to headers/interfaces

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

On Mon, Nov 27, 2023 at 4:23 PM Dmitry Gutov <dmitry@gutov.dev> wrote:
>
> On 27/11/2023 18:04, João Távora wrote:
> > On Mon, Nov 27, 2023 at 3:45 PM Dmitry Gutov <dmitry@gutov.dev> wrote:
> >
> >> That didn't answer the above question. To signal "what kind of
> >> cross-references it can find", it would define
> >> xref-backend-definition-kinds with corresponding return value.
> >
> > The answer was in the first two words.  "Of course", and the reason
> > is in the words following that.
> >
> > So to be clear, yes, c++-ts-mode, if it ever gets such capabilities
> > should define c++-ts-find-declaration, c++-ts-find-partial-specializations
> > and so forth, but probably no c++-ts-find-implementation (fuzzy concept
> > in C++).  It should (or rather, it may) bind them in a given xref-provided
> > prefix map and they should become active when c++-ts-mode is active.
> >
> > For "references" and "definitions" the existing xref commands will do,
> > but the phrases "references" and "definitions" should well be in the
> > "prompt for kind" list as options.
>
> We in the end we'll have dozens of similarly-named commands with the
> same implementation, right? Some of them in the core, others in
> third-party addons.

What same implementation?? They only common part is is literally just
the string "xref-define-finder", the opening and the closing parenthesis.
Then comes the backend specifics.  A JSONRPC-based transport with a specific
protocol, an HTTP transport with another protocol, a ask the oracle of Delphos
protocol, etc.

Realistically, most people will be using Eglot anyway, so the existing
eglot-find-* commands are what they're going to see and use.

> > But you could put the existing xref-find-definition and xref-find-references
> > commands in it.  Even the "find-all" could be there.
>
> That... doesn't sound very convincing, TBH.

That's obvious.  It's clear to me that you are already convinced
of whatever you want and all this discussion leads nowhere.

So do what you want.  If I like it, Eglot will use it.  Else I will
do my own commands in eglot.el.  It'd be nice to reuse as much
of Emacs as possible, but when it's not suitable (like many parts)
or takes years to bikeshed to an agreement, I don't have to.

I think I've given this discussion enough energy argument, etc.
You're familiar with all the technical limitations of Eglot, etc.

So, to summarize,  I will branch from `feature/xref-find-extra` in
that well-known point, polish some things there to a mergeable
point.  If you come around and want to merge what is basically your
own patch of a month ago, great!

João