Re: Adding support for xref jumping to headers/interfaces

[Spencer Baugh <sbaugh@janestreet.com>]

João Távora <joaotavora@gmail.com> writes:

> On Wed, Nov 8, 2023 at 5:45 PM Spencer Baugh <sbaugh@janestreet.com> wrote:
>> João Távora <joaotavora@gmail.com> writes:
>> > On Wed, Nov 8, 2023, 16:40 Spencer Baugh <sbaugh@janestreet.com> wrote:
>> >  I found it rather clumsy out of the box.
>> >
>> > What exactly is clumsy? Please state the command you used and what the clumsy effects were.
>>
>> Specifically xref-find-extras is clumsy, because it's annoying to have
>> to type the full "kind" in to request a specific "kind" of definition.
>
> I don't find it annoying.  But since we settled long ago that there can
> be no standard set of all kinds that makes sense for all languages, then
> I don't see a better way than what the current xref patch does now: asking
> the backend for kinds and then having one command with an additional selection
> step.  The little change I did to Dmitry's xref.el allows particular modes
> such as Eglot to implement their own "quick-access" commands for a particular
> kind more easily.

Here is the better way: have both a standard set of kinds, and the
ability for a given backend to make their own custom kinds.

A "standard set of kinds" would just be standard kind symbols.  Instead
of Eglot returning 'eglot--xref-declaration as a supported kind, it
would return 'declaration.  And we could have a standard command with a
standard binding which requests definitions of kind 'declaration.

The only change to the current patch would be changing
'eglot--xref-declaration to 'declaration, and adding an
xref-find-declaration.

Custom kinds would still require you to type in the kind symbol.  (Or a
backend or mode can make a "quick-access" command specific to that kind,
if they want.)