Re: Adding support for xref jumping to headers/interfaces

[Dmitry Gutov <dmitry@gutov.dev>]

On 26/11/2023 18:08, Felician Nemeth wrote:
> 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.

I think the first question is what will be best for the default UI. And 
the follow-up will be, if needed, is whether anything else is needed to 
make it more easily customizable.

A completing-read-function, or simply a UI which does what you describe, 
is not out of the question for this built-in command too. But if we 
tried to add it, then it's a question for how to choose the letters, and 
whether we expect them to be more-or-less stable over different 
languages and backends. If no, that's a bit of a bummer, given that one 
would often want to input their choice quickly, even without reading. If 
yes, then I suppose that means that the global set of "kinds" is 
actually stable, and it's either possible to create a mapping registry 
(characters to kinds), or choose a very stable dynamic algorithm (given 
that we know most of the inputs).

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

Eglot's integration shows that we don't in advance know whether a 
backend actually supports a specific kind. At least, we cannot know 
whether that kind is supported for a specific symbol at a given position 
(my tests with Eglot in the Emacs repo and clangd more than often ended 
up in "nothing found"). So to provide a list like ("definition/A"
"documentation/B" ...) we'd have to first query all available backends 
about all kinds for the symbol at point. I think somebody said that this 
can be slow at least for some kind/backend/ls combinations.

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

That was my expectation indeed, but lately he said that since the 
commands are already in Eglot, they will remain there. Among other 
things, it will likely mean that they won't be getting key bindings 
(aside from those assigned by the users manually).

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

In Elisp, though, the whole addition doesn't make much sense. At least I 
don't see the benefit: xref-find-definition in Elisp already shows all 
kinds together, and it's rare than one needs to choose between them. And 
together with Mattias E.'s work for detecting the symbol-at-point's 
context ('elisp--xref-infer-namespace', etc) this works faster 
automatically 99% of the time.

My testing with the Elisp backend is what prompted me to try to 
re-evaluate how this addition should work, anyway.

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

It could also be an automatically generated kind called "all" in the 
list to choose from.