Re: Adding support for xref jumping to headers/interfaces

[Dmitry Gutov <dmitry@gutov.dev>]

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

So that's what your argument comes down to in practical sense -- keep 
the commands in Eglot, and not worry much about other Xref backends. 
Whether they are alternative LSP clients or not.

Setting aside the issue of us binding ourselves to Eglot too closely, 
that *would* mean keeping those commands unbound for the foreseeable 
future. And I do remember users asking about the default bindings.

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

I'm saying it doesn't look good as an argument that I could make to 
convince the current head maintainers of Emacs to free up the "M-'" 
binding. Or any other short key sequence, probably.