Re: Adding support for xref jumping to headers/interfaces

[Spencer Baugh <sbaugh@janestreet.com>]

João Távora <joaotavora@gmail.com> writes:
> On Thu, Nov 9, 2023 at 7:23 PM Spencer Baugh <sbaugh@janestreet.com> wrote:
>>
>> João Távora <joaotavora@gmail.com> writes:
>> > On Wed, Nov 8, 2023 at 11:34 PM Dmitry Gutov <dgutov@yandex.ru> wrote:
>> >> > But neither was available at the time, so I did those commands and they won't
>> >> > be obsoleted any time soon.
>> >>
>> >> Reasons being..?
>> >
>> > That we can't come up with alternatives to exactly that interface,
>> > obviously.  When you do, I'll obsolete them.  But do you want to hardcode
>> > things like LSP "typeDefinition" and Sly's "who-macroexpands" somewhere
>> > in xref.el?  How would that work?
>>
>> Right, so if we have kinds defined in the core for "declaration",
>> "implementation", and "type-definition" (maybe not with those exact
>> names), then we can have xref-find-declaration,
>> xref-find-implementation, and xref-find-type-definition (again maybe not
>> with those exact names), and just do
>>
>> (define-obsolete-function-alias 'eglot-find-declaration 'xref-find-declaration)
>> (define-obsolete-function-alias 'eglot-find-implementation 'xref-find-implementation)
>> (define-obsolete-function-alias 'eglot-find-typeDefinition 'xref-find-type-definition)
>>
>> Is that possible?
>
> For Dmitry to answer, but I think we had established that is a
> slippery slope.  Many languages have different exotic concepts, like
> Lisp and macroexpansion, C++ template instantiations, or annotations.
>
> And conversely many other languages don't even have the distinction
> between the three you mention.

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.

> And i'm only talking about the handful of languages I'm
> more of less familiar with, there are many many more.  And many
> more can be invented with different types of manifestation, there's
> no shortage of imagination is language designer-land.
>
> Not to mention Xref can in theory be used to provide
> cross-referencing support in any type of work, not just
> programming.
>
> 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.

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.  Likewise other backends
which support something they want to call an "implementation" can
support 'implementation.  We don't have to say what an "implementation"
is, any more than we currently specify what a "definition" or a
"reference" is.

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.

> Has everyone changed their mind?  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.
>
> What practical problem are you trying to solve?

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.
Which I think is most languages - including Elisp.

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.