Re: Adding support for xref jumping to headers/interfaces

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

On Mon, Nov 27, 2023 at 2:35 PM Dmitry Gutov <dmitry@gutov.dev> wrote:

> But one of the latest emails mentioned a separate Xref backend for c/c++
> -- should I assume that every such backend would define its own set of
> *-find-* commands suitable for its languages?

Of course, a cross-referencing backend should know what kind of
cross-references it can find.  Eglot knows how to find 3 or 4 different
kinds, language server permitting of course.  Eglot will never know how
to find "documentation", and I believe the Elisp backend should
never purport to know how to find "declaration", since that's a very
fuzzy concept in Lisp with no accepted meaning.  As is
"typeDefinition", doesn't make much sense in dinamically typed
languages (but "declaration" is worse).

> Would such backends each come with an automatically-enabled keymap? Or
> would the user have to set up key bindings for every such command, for
> every special backend like that?

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

But however this works, I think the bindings issue is completely
secondary.  Secondary not in the sense that it's less important,
but in the sense that we don't have to commit to something right
now, so I don't understand the tortuous route this feature is taking into
what-if territory.

So whatever solution we find to the bindings issue (if it is indeed
an issue)

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.

João