Re: Adding support for xref jumping to headers/interfaces

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

On Sat, Nov 11, 2023 at 9:37 PM Dmitry Gutov <dmitry@gutov.dev> wrote:
>
> On 11/11/2023 13:44, João Távora wrote:
> > On Sat, Nov 11, 2023 at 12:58 AM Dmitry Gutov <dmitry@gutov.dev> wrote:
> >>
> >> On 09/11/2023 22:44, João Távora wrote:
> >>> So I thought, that about 6 months ago we had established that
> >>> "definition" and "reference" are two relatively safe concept to
> >>> keep in xref.el, but other concepts should not be in there,
> >>> because this doesn't scale well and could imposes awkward
> >>> structure and hacks into an unknown number of backends.
> >>>
> >>> Has everyone changed their mind?
> >>
> >> My impression is that the first feedback from our patches actually made
> >> people excited about things that _weren't_ included in the
> >> previously-discussed plan, so it seems like a good idea to re-evaluate
> >> it. Though not necessarily redo it all.
> >>
> >> Though I guess this particular mailing list might be biased in favor of
> >> particular type of users (keyboard-driven, faster interaction as a
> >> priority).
> >
> > yeah, the sample size is so small that's it's more than certainly
> > biased.
>
> Most likely. It's too bad our actual audience here is quite small, and
> we don't have other reliable ways to collect feedback to prototypes.
>
> Dropping an implementation into master is one way to test out a
> hypothesis, but it has inherent problems: the feedback comes late
> anyway, and quite often we'd end up having to maintain half-bakes
> features or unfortunate capabilities this way simply because they had
> been added and time had passed.

Maybe.  Well Eglot has a fair enough audience, though not sure for
this specific feature.  And I don't see any better alternatives if
collecting feedback is what we want.  IOW, we shouldn't fall prey
to "analysis-paralysis".

> >>> What exactly bothers you
> >>> about eglot-find-declaration/implementation/typeDefinition?
> >>> In LSP-land these concepts_do_  make sense, because the
> >>> LSP standard prescribes what servers should do with them.
> >>
> >> I think we've actually discovered that these kind of make sense for
> >> Elisp too. They might not match the current implementation, but
> >> conceptually, in some future, they might.
> >
> > Yeah, they "kind of" make sense, but not very well and IMHO that's
> > not a detail, but a big red flag.  It's clear, and I understand
> > your point, that if we were to squint to contort to them we could
> > have xref provide a consistent "works everywhere" UI.  But as
> > Spencer noted it would be "works _mostly_ everywhere".  And, as I
> > noted, the contortion might lead us up awkward alley, such as
> > finding a list mixing `declare-function` and `declare (compiler-macro`
> > in the bag of xref-find-declarations.
>
> Why contort? From where I'm standing,
> declarations/implementations/typeDefinitions apply to almost any
> object-oriented language (C++/Java/Ruby/Python/JS), and even some
> functional ones.

What are "declarations" in JS, Java or Ruby and Python?  Perhaps
nothing perhaps entirely different things. Also, there  are a lot of
sub-kinds of declaration in C++.  Is a forward declaration of a
type in C++ also a "declaration" here?  What about a C++20 concept,
is it a type definition?  No right?  Or maybe, depends on who you ask
some say it's a type for types.  Not to mention I think in Elisp we
have at least 3 completely different kinds of "declaration": forward
declarations, (declare ...) forms and defgeneric.  It's odd to mix
them.

Anyway, this is LSP's taxonomy so it's LSP's problem (or rather,
the problem of the poor servers that have to invent ways to shove
things in these categories.  But not our problem by and large if we
don't let  it spread any further than Eglot.  IMO Eglot is where
LSP ends and Emacs starts.

> What's the alternative? To have many similar commands
>
>    ruby-find-implementation
>    c++-find-implementations
>    python-find-implementations
>    js-find-implementations

Depends.  If you are using Eglot/LSP as a backend, you don't need to.
Eglot already gives you the LSP trio.

If you are using a non Eglot backend, then yes.  If you are using
specific backend based on Eglot but with more servers, then yes too,
but only for the extra types you support.

> that all do the same thing inside: call the Xref backend's "find
> implementations" mechanism? It will be especially great to use if some
> major mode authors bind that command to one key, and others to another.

I don't think it'll happen that often, and xref can define a good prefix
map to use.  It's unlikely we or major modes would find keybinding space
outside such a map anyway.

> > And Spencer even wanted to put cl-defgeneric in that bag, which I
> > can fully understand, as cl-defgeneric can also be viewed as a
> > declaration.  But its a completely different concept from those
> > two.
>
> If Elisp doesn't have any other kind of declarations, what is the worry?
> Let's put the ones it has.

But it does, at least for some understandings of "declaration".  And it
could get even more.  A declaration is of course a reference to a thing
that characterizes a part, but not the main part or totality of the thing.
Besides the other two I mentioned already, any source code locus
setting a property on a symbol could be viewed as that.  Are we prepared
to handle this?  We could be.  If we are, do we really want to put this all
in a one-size-fits-all "declarations" bag?

João