Re: Adding support for xref jumping to headers/interfaces

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

On Fri, Nov 10, 2023 at 12:15 PM Spencer Baugh <sbaugh@catern.com> wrote:

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

Not really.  "Declarations" don't make much sense in Elisp. I'll
explain below.

And I don't think we should code xref.el with "selfishness" in mind
at least if we're serious about making it reusable.  elisp-mode.el
should have things that make sense fo Elisp.  Vast amounts of Emacs
users couldn't care less for Elisp, and that's fine.

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

Doesn't mean it's any good either.  Emacs precedes LSP by many
years in being flexible enough to support many languages.
And it absolutely trounces LSP in that respect.  LSP's main point
here is that it supports many editors, and so reusable language servers
appear for many languages not motivated by Emacs, and Emacs,
using Eglot, profits from that.  But LSP makes tremendous tradeoffs
in flexibility, tradeoff that we don't have to make or even consider,
because we support only one editor, ourselves.

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

Exactly, and you wrote "the backend just errors when kind=implemetation"
So you admit it's going to happen.

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

Yes, the notion of definition and reference are much less
controversial.

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

But incomplete consistency contains, by definition, inconsistency!  IOW
"degree of consistency" is a fine example of an oxymoron.

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

Sure, for refactor-code-actions, which will work much like xref-find-extras,
aka xref-find-by-kind (or maybe it should be named only xref-find, or
why not only
xref).

But there won't be a command refactor-quickfix or refactor-organizeImports
because not all potential refactor.el backends support those LSP concepts.

It's exactly the same here.

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

Doesn't make sense to me, sorry.  In Elisp you work with symbols.  So
a given symbol has many possible meanings (a so-called lisp-2 has two
standard ones: variable and function bindings).  But you can add your
own, class definition, generic function, setf expander, autoload-function,
docstring, whatever crosses your mind.  In current Elisp-- but not
necessarily future Elisp--you alreadyhave two completely different concepts
of "declaration".   One is declaring functions early so the byte-compiler
doesn't complain about them and another is optional `declare` forms you find
in the first form of a function's body.  Completely different concepts,
miles apart.  Now you want to add a symbol's generic function definition
to the "declaration" family. Even more miles apart. So one day I find
a symbol, I press your desired xref-find-declarations on it and I get
this awkward salad of totally unrelated things.

I'd certainly like to be able to use xref to find the source code
loci for all these different things that a symbol might mean, of course
I do.  But xref-find-declaration is a awful way to do it.

Mind you that xref-find-references is much less problematic.
A "reference" is in essence any manifestation of a given
symbol/name/identifier in the source material, _regardless_ of
the specific kind of manifestation.

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

So what would xref-find-generic do in C++ code?  It has no generics.
Most languages have no generics.  Most programmers I know have never
even heard of "generics".  "generic functions" even less so.  Why do
you want to burden these non-Lisp people with this new concept
from Common Lisp that they'll have to map to their own favourite
language they want to do their work on?  And no, never will "generic"
map clearly to the fundamental C/C++  concept of a declaration, for
example.  Not to mention Java has templates called "generics".
And C++ has templates called templates. Completely different concepts.

So IMO this is just a very bad idea, I'm afraid.

But I think we have made both our positions clear.  I understand what
you want to do and I am completely against it, but this is not just
up for me to decide.  The only thing that is, is that if I like the
new interfaces in xref.el I will implement them in eglot.el.  The
UI that xref.el provides I can't control.  Of course I recommend
keeping at least the current UI of xref-find-extra, not least because
it's something that has actually been implemented and I have
spent time integrating.  And I also like your idea of KIND=nil to
make it show a sectioned listing using whatever kinds the backend
declares as section headings.

In the end, people will be able to continue using LSP and xref.el
without any problems, with eglot-find-declaration, etc, that's a
given.

Joao