[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Adding support for xref jumping to headers/interfaces
From: |
Spencer Baugh |
Subject: |
Re: Adding support for xref jumping to headers/interfaces |
Date: |
Thu, 09 Nov 2023 12:07:00 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
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.)
- Re: Adding support for xref jumping to headers/interfaces, (continued)
- Re: Adding support for xref jumping to headers/interfaces, Spencer Baugh, 2023/11/08
- Re: Adding support for xref jumping to headers/interfaces, João Távora, 2023/11/08
- Re: Adding support for xref jumping to headers/interfaces, Spencer Baugh, 2023/11/08
- Re: Adding support for xref jumping to headers/interfaces, João Távora, 2023/11/08
- CCing thread participants through gnus+gmane, Spencer Baugh, 2023/11/09
- Re: CCing thread participants through gnus+gmane, Eric Abrahamsen, 2023/11/10
- Re: CCing thread participants through gnus+gmane, Visuwesh, 2023/11/10
- Re: Adding support for xref jumping to headers/interfaces,
Spencer Baugh <=
- Re: Adding support for xref jumping to headers/interfaces, Dmitry Gutov, 2023/11/10
- Re: Adding support for xref jumping to headers/interfaces, Spencer Baugh, 2023/11/11
- Re: Adding support for xref jumping to headers/interfaces, Dmitry Gutov, 2023/11/11
- Re: Adding support for xref jumping to headers/interfaces, Dmitry Gutov, 2023/11/08
Re: Adding support for xref jumping to headers/interfaces, Spencer Baugh, 2023/11/07
- Re: Adding support for xref jumping to headers/interfaces, Dmitry Gutov, 2023/11/07
- Re: Adding support for xref jumping to headers/interfaces, Spencer Baugh, 2023/11/08
- Re: Adding support for xref jumping to headers/interfaces, Dmitry Gutov, 2023/11/08
- Re: Adding support for xref jumping to headers/interfaces, Dmitry Gutov, 2023/11/08
- Re: Adding support for xref jumping to headers/interfaces, João Távora, 2023/11/08