Re: Adding support for xref jumping to headers/interfaces

[João Távora]

On Mon, Nov 27, 2023 at 3:02 PM Dmitry Gutov <dmitry@gutov.dev> wrote:
>
> On 27/11/2023 16:49, João Távora wrote:
> > On Mon, Nov 27, 2023 at 2:43 PM Dmitry Gutov <dmitry@gutov.dev> wrote:
> >
> >> (that's what the completing-read approach is for), and whenever we find
> >> out that particular kinds get supported by many backends (or by most of
> >> the available/popular ones), we could "pull them into the core", adding
> >> a global command with one binding which would work across languages.
> >
> > Alright, so since this is contentious (who else but you is pushing
> > this idea?)
>
> Indeed, I wonder if nobody else is interested in having the additional
> commands have pre-defined bindings, or having the same bindings across
> languages.

Of course if you put it like that then EVERYBODY is interested in that.
Everybody likes consistency, but this consistency you're proposing
is a mirage.  An naive Xref user would be very proud to use
"xref-find-declaration" in 3 different languages but then would
start to doubt xref that the things he and the backend author meant
by declaration are entirely different.

Again, leave this to major modes, which is what we always do (or to backend
which in 95% of cases would live in the major mode when they are
language-specific).

> > what about we start with 0 in xref.el.  We can always
> > add to 0, no problem, but taking away  from some other number
> > isn't so easy.
>
> We could indeed start with 0, but then I already see the same set of
> extra commands supported in Eglot, Elisp, lsp-mode

They only exist in Eglot and LSP-mode because these are LSP things,
it makes full sense they would exist in any Emacs/LSP interface.

Elisp?  What commands are you talking about, only if you force them.
I see no elisp-find-{declaration,type-definition,implementation}
or anything of the sort.

The 7 Elisp cross-reference kinds you defined in your original
patch are

  "defalias"
  "face"
  "function"
  "constructor"
  "generic"
  "variable"
  "feature'"

This is exactly what a language-specific kind list should look like by
the way.  These are the interesting things to cross-reference to in Elisp,
not "implementation", "declaration" and "typeDefinition".  Sure we
can squint very hard and try put those into those three drawers, but
it's such a meaningless exercise with no practical value.

> >>   and to allow frictionless extensions for special capabilities.
> >
> > As to frictionless extension, the macro I proposed already
> > xref-define-finder seems the easiest way by far.
>
> Sorry, I can't find it.
>
> But the definition of xref-find-declarations takes about 3 lines. There
> is not much potential for making it even shorter.

It's very similar and analogous to:

(defmacro eglot--code-action (name kind)
  "Define NAME to execute KIND code action."
  `(defun ,name (beg &optional end)
     ,(format "Execute `%s' code actions between BEG and END." kind)
     (interactive (eglot--code-action-bounds))
     (eglot-code-actions beg end ,kind t)))

And allows us to control exactly the 'interactive' spec of such
commands to give us consistency among them.

João