Re: Adding support for xref jumping to headers/interfaces

[João Távora]

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.

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.

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?

João