Re: Adding support for xref jumping to headers/interfaces

[Dmitry Gutov <dgutov@yandex.ru>]

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

If Eglot keeps its commands (which I don't mind that much), then any 
comparable package should also be allowed and even encouraged to define 
its own commands. And we should document that somewhere, too.

But that design ends up far from the original "Eglot shouldn't do this" 
sentiment that I have read before.

And also, Eglot keeping its commands seems incompatible with (or at 
least counter to) the approach where is an existing set of "extra" 
commands that is bound to some prefix map (e.g. one assigned to M-'). 
Because if there are many different commands called *-find-declarations, 
it seems difficult to put them all on the same key.

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

Reasons being..?

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

It's not secondary if people will start adapting their backends to it.

E.g. the term "extra" seems more like a misnomer now, given that people 
seem to want that command to include the kinds already present in 
"definitions". And they might constitute the majority of those "kinds".