Re: Adding support for xref jumping to headers/interfaces

[Dmitry Gutov <dgutov@yandex.ru>]

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.

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

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