emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Adding support for xref jumping to headers/interfaces


From: Felician Nemeth
Subject: Re: Adding support for xref jumping to headers/interfaces
Date: Sun, 26 Nov 2023 17:08:06 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux)

Dmitry Gutov <dmitry@gutov.dev> writes:

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

I have a completing-read-function that creates a single keystroke
selection, so the two alternatives are almost the same to me.

However, in the past it made sense to find the first xref backend that
knew the definition of an identifier.  Now let's assume backend A
provides definitions with letter "d" and backend B provides
documentation locations also with letter "d".  I think it useful to
allow the user to select between the two when xref-find-all-definitions
is invoked.  And it is easier to create a flat list for completing-read
than for read-multiple-choice, for example: ("definition/A"
"documentation/B").

> 2. Whether Eglot should, in time, deprecate its corresponding three
> commands if Xref adds its own versions.

I think one of João's design goals of Eglot is to rely on existing Emacs
features as much as possible.

> 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 don't have a strong opinion about this.  In elisp-mode fetching all
kinds by default seems to be the most useful.  Usually there are no more
than a handful of items and it is easy to see their kind.

>> 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)?

If I'm the only one who'd be happy to have this, then a separate command
without a keybinding would be fine.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]