Re: Adding support for xref jumping to headers/interfaces

[Spencer Baugh <sbaugh@catern.com>]

João Távora <joaotavora@gmail.com> writes:
> 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.

None of those make sense for Elisp, and "declarations" and
"implementations" do make sense for Elisp (as I'll describe below).
That's the difference.

I think we should be somewhat "selfish", and let our design here be
guided by "Things which make sense for Elisp, and also many other
languages".  Declarations and implementations, I think, are an instance
of that.

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

Absolutely, of course, but just because LSP has "declarations" and
"implementations" doesn't mean it's not good for Emacs.

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

Eh?  You'll only get an error if backend B doesn't support one of the
core kinds.

I also get errors today if the backend doesn't support
xref-find-references.  That doesn't make M-? (xref-find-references) any
less of a consistent UI for modes that support it.

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

That is fine and exactly what I want.  I see an area where a degree of
consistency is possible, so I see no reason not to get that degree of
consistency.

"This other thing can't be consistent" doesn't make sense to me as an
argument against making this somewhat consistent.

>    Unless you enshrine them into xref.el.  Then you'll get more of
>    problem 1.

Definitely not.  Let's keep it minimal.

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

Sure, that sounds good.  But do you hope to eventually add a standard
keybinding for accessing refactor.el?  I hope so.  And I'd like the same
for these xref commands.  (but not for Eglot and LSP's sake!  My
inspiration for making this thread is not Eglot and LSP, it's my own
xref backend which also has these concepts)

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

That's not what I'm suggesting.  I suggest that find-declarations when
run on a generic should give the cl-defgeneric, and find-implementations
should give the cl-defmethods.

I think that would be a really helpful new feature, apart from all the
rest of this.

If the term "declarations" and "implementations" are a problem, we could
totally give them another name.

How about "find-generic" and "find-methods"?  Just literally copying
what Elisp calls them.  Then we can set aside all this worry about
sharing terms with LSP.

So let me restate my proposal in those terms:

I'd like an xref-find-generic which in Elisp jumps to the cl-defgeneric,
and an xref-find-methods which in Elisp jumps to the cl-defmethods.
When run on regular functions, both will just jump to the defun.  And I
would like default keybindings for those, ideally under M-'.  I think
this is useful independent of anything else.  I want this purely for
programming in Emacs Lisp.

If and when we added those, I think it would be reasonable for some
language modes (but not others) to connect xref-find-generic to LSP
declarations, and to connect xref-find-methods to LSP implementations.
Since in some languages those concepts match up decently well.