Re: Adding support for xref jumping to headers/interfaces

[Dmitry Gutov <dmitry@gutov.dev>]

On 27/11/2023 18:04, João Távora wrote:
> On Mon, Nov 27, 2023 at 3:45 PM Dmitry Gutov <dmitry@gutov.dev> wrote:
> 
>> That didn't answer the above question. To signal "what kind of
>> cross-references it can find", it would define
>> xref-backend-definition-kinds with corresponding return value.
> 
> The answer was in the first two words.  "Of course", and the reason
> is in the words following that.
> 
> So to be clear, yes, c++-ts-mode, if it ever gets such capabilities
> should define c++-ts-find-declaration, c++-ts-find-partial-specializations
> and so forth, but probably no c++-ts-find-implementation (fuzzy concept
> in C++).  It should (or rather, it may) bind them in a given xref-provided
> prefix map and they should become active when c++-ts-mode is active.
> 
> For "references" and "definitions" the existing xref commands will do,
> but the phrases "references" and "definitions" should well be in the
> "prompt for kind" list as options.

We in the end we'll have dozens of similarly-named commands with the 
same implementation, right? Some of them in the core, others in 
third-party addons.

> And no, it doesn't take much imagination to do this for CC-mode as
> well, if the backend supports both C++ modes.
> 
>>> The major modes could do that, for example.  They could do it by
>>> linking the backend-created "one key/command" keymap into a special
>>> prefix created by xref.el, doing so by calling a load-time xref.el helper.
>>
>> Okay, so we would create and occupy a new common prefix. But without any
>> commands in it? How do you suggest we advocate for that around here?
> 
> What's the difference between no commands and useless commands that return
> errors?

Existing binding that one could [remap]. Or an opportinity for an Xref 
backend to extend itself into corresponding types.

> But you could put the existing xref-find-definition and xref-find-references
> commands in it.  Even the "find-all" could be there.

That... doesn't sound very convincing, TBH.

 > Also, as far as I can
 > see, you are already ogling the M-' binding in your branch anyway.

M-' has an existing binding, and the contents of the branch could help 
make a case to change it. And then, if we don't add other new commands, 
why force people to use "M-' M-'" if they could just use the "M-'" for 
the only new command.

>> And I didn't just invent the need for faster interaction by myself -
>> just look at the first responses to the prototype. Okay, perhaps some
>> power users in this thread don't mind adding personal tweaks to their
>> config to speed things up. But that means the OOtB experience will be
>> lacking.
> 
> I'm not saying the bindings issue isn't important, I'm saying it's
> (1) secondary to the communication mechanism and the functionality
> which is already pretty useful in your original patch in this
> 20-years+ Emacs user's experience (and I don't keybind things).
> (2) not something we should rush to solve by copying an awkward
> categorization that doesn't fit the needs of languages.
> (3) solvable in all practical aspects by judicious coordination
> with backends and major modes.

True. Aside from the issues of 1) naming, 2) presence of "references" in 
the set, 3) interface to "fetch all" which we still haven't come to 
accord on.

>>> It's much more pressing to decide if/why you want a command named
>>> xref-find-all-definitions to return things that aren't "definitions"
>>> by any measure or what is pressuring us to enshrine
>>> "declaration/implementation/typeDefinition" in one of our
>>> most generic libraries.
>>
>> It's a framework, not so much a library. Although it has the latter's
>> capabilities too. As a framework, we should consider what the end user
>> experience would look like.
> 
> Sure, of course.  And it already does that it excellently in so many
> good ways (IMHO the decision to copy SLIME's UI was excellent). But
> don't try to make it the uberframework for finding things to the point
> of making Emacs-wide commands copied from LSP that don't fit a bunch
> of the vast amount of Emacs use cases.  It's too heavy handed,
> a step too far, not elegant.

We don't have to copy LSP, or follow any of its subsequent additions, or 
even copy the 3 "kinds" already mentioned. But any tentative plan for 
making user experience across backends faster and more unified would be 
good to have. Even if we don't act on it yet, code-wise.