Re: Adding support for xref jumping to headers/interfaces

["João Távora" <joaotavora@gmail.com>]

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.

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?

But you could put the existing xref-find-definition and xref-find-references
commands in it.  Even the "find-all" could be there.  Also, as far as I can
see, you are already ogling the M-' binding in your branch anyway.

> > So maybe some backends would have d for  "documentation" and others would
> > have d for definitions, so what? Maybe that's precisely what a user working
> > on a documentation heavy system expects "d" to do. And if these two backends
> > happen to be enabled simultaneously,  even this conflict could be
> > resolved, by adjusting the keymap during the linking process.
>
> That's easily solvable in other ways.

OK.  I just suggested one, keep it in your catalog maybe.

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

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

João