Re: Adding support for xref jumping to headers/interfaces

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

On Fri, Nov 10, 2023 at 6:23 AM Spencer Baugh <sbaugh@janestreet.com> wrote:

> Well, Elisp for example has "declarations" and "implementations":
> cl-defgeneric and cl-defmethod.  I'd like, in Elisp, a command which
> jumps to the cl-defgeneric, and another command which shows the
> cl-defmethods.  This doesn't have anything to do with LSP, it's a
> feature purely for Elisp.
>
> I think we can support this without going down any slippery slopes.

Really, what if the language du jour sometime in the future becomes
something like C++ again? Will you add 'type-instantiation,
'type-specialization,  'partial-specialization,  'concept, and so on?
Or the C++ backend somehow manages to index the loci of memory
allocation to a given arena names at point.  Will 'memory-allocations'
also appear in xref.el?

These are all things a C++ backend may legitimately want to organize
much more than those 3 extra compartments, just like Lisp users
like to see who-macroexpands and who-calls.

So yes, quite slippery.

LSP, the protocol has the same problem, and their 5 categories
(definitions, references, implementation, declaration, typeDefinition)
are awkward as heck and don't make any sense for many languages.
They're probably coming from large commercial languages such as Java
and C#,  Typescript, etc not suprising given it's all a Microso$t
gig. But it's just poor design that I'd rather not have bleed into
Emacs xref.el.

Emacs is older than LSP and my bet is that it will outlive LSP.

Of course Dmitry is the person to convince here, not me.

> We don't have to include the concepts in xref.el per-se.  All I suggest
> is that instead of supporting 'eglot--xref-implementation as a kind,
> eglot should support 'implementation as a kind.

By the the symbol you quoted is an internal implementation detail.
The fact that it can't be represented well under the current
patch is under discussion with Dmitry and it's super-easy to fix
whatever the outcome of that discussion is.  IOW that prompt should
show "Implementation".

> If a backend doesn't support 'implementation, that works fine with the
> current patch - the backend just errors when kind=implementation is
> passed to xref-find-extra.  No awkward structure, no hacks.

Oh, big awkward:

1. You lose the consistency you wanted so much.  I can't
   take my muscle memory from backend A to backend B.  I'll just get
   errors.

2. If backend C supports many more things other than implementation
   typeDefinition, etc, they're either going to be awkwardly
   organized into those drawers or available as backend-specific
   commands you wanted to avoid in the first place.  Unless
   you enshrine them into xref.el.  Then you'll get more of
   problem 1.

The only clean solution to this is to go knock on language
designer doors ;-).  But I thought we had reached this conclusion
already, why are we rehashing it?

And if you didn't catch it, the current eglot-find-* commands
can be cleanly implemented with no hacks and with a common UI
between them.

Just like the Eglot code-action commands for common actions such
as "organizeImports", "quickfix".

When I get around to finishing refactor.el which will inherit most of
Eglot's UI for doing refactorings, I don't plan to burn the concepts of
"organizeImports" and "quickfix" into it.  They are LSP things.

> Practically, I don't want to have a different UI for these commands in
> every individual language and mode, I'd like a common set of bindings
> which are usable for every language which supports these concepts.

And I'd like speakers of foreign languages to understand Portuguese
"go there go!".  And I yet I fail, and it's impossible to  explain.


> Which I think is most languages - including Elisp.

"declarations" really?  Sure you could cram declare-function into there,
and it kind of emulates the forward-declaration meaning of it in C/C++
which is clearly LSP got the idea from.  Fine.  But then what about
compiler-macro declarations and edebug declarations, etc, the ones you use
with `(declare (debug...))` in the beginning of functions (sometimes not)?
They're an entirely different concept and yet known as "declarations" for
any Elisp  (or Common Lisp) user. It's awkward to find both mixed when
you're thinking of just one.

> There's also bug#64714 - I have to pick bindings for these commands for
> my hundreds of users, and I don't want to pick ones which will conflict
> with later changes upstream.  I expect there will eventually be bindings
> for these commands in Emacs.  So I'd like to just do it now.

This isn't an Eglot/Xref, etc problem.  It's a problem of whatever you
are trying to do.  Eglot uses no keybindings and plans to keep that
promise.  Then, there are keybindings reserved for users, major modes,
specialized modes, etc.  I don't know the rules by heart, you can consult
them.

João Távora