Re: Adding support for xref jumping to headers/interfaces

[Dmitry Gutov]

On 24/11/2023 23:43, Felician Nemeth wrote:
> Dmitry Gutov <dmitry@gutov.dev> writes:
>
> > Anyway, I've pushed an update to the same branch
> > (feature/xref-find-extra).
> >
> > What does everyone think?
>
> I haven't followed the discussion, but the extensibility of it is just
> great.

Here's a refresher on the points of contention, in case you'll have 
something to add:

1. Whether Xref should have separate commands for 
declarations/implementations/type-definitions. With default global 
bindings (probably -- if we manage to get agreement on taking M-', for 
example). Or e.g. have a registry for kinds and letters, for quick 
selection between kinds (alternative for completing-read). Or just use 
completing-read and leave the definitions of all new commands (including 
the counterparts to declarations/implementations/type-definitions, of 
which then there will be multiple copies of) to the Xref backends.
2. Whether Eglot should, in time, deprecate its corresponding three 
commands if Xref adds its own versions.
3. How the new command (currently named xref-find-all-definitions) 
should behave: should it always ask for the kind, or have a default one 
(determined how?), or fetch all kinds by default and show them together, 
like the latest version does.

> I think it is a minor inconvenience that it is not possible to use
> directly the symbol-at-point as identifier while asking the user for the
> kind.  That is a prefix argument causes xref-find-all-definitions to ask
> the user for both.

I'm open to suggestions. Using 'C-u C-u' for one of the choices? Adding 
a separate command with different behavior (and different binding)?

> eglot-find-declaration, eglot-find-implementation,
> eglot-find-typeDefinition still use the now non-existent
> xref-find-extra.

Now fixed, thanks (with a rebase).