Re: Adding support for xref jumping to headers/interfaces

[João Távora]

On Wed, Nov 8, 2023 at 5:45 PM Spencer Baugh <sbaugh@janestreet.com> wrote:
>
> João Távora <joaotavora@gmail.com> writes:
>
> > On Wed, Nov 8, 2023, 16:40 Spencer Baugh <sbaugh@janestreet.com> wrote:
> >
> >  João Távora <joaotavora@gmail.com> writes:
> >  > On Tue, Nov 7, 2023 at 11:18 PM Dmitry Gutov <dgutov@yandex.ru> wrote:
> >  >> What I meant is, using it with the Elisp implementation didn't
> >  >> convince me of the usefulness of the feature. Perhaps you disagree?
> >  >>
> >  >> Or it would be nice to hear from someone who have tried out Eglot's
> >  >> integration and found more upsides there.
> >  >
> >  > If you want that to happen, the only realistic way to have good
> >  > feedback from anyone else other than emacs-devel nerds like me and you
> >  > is to release an Eglot version with  this feature, which we can change
> >  > later (even non-backward-compatibly, within a reasonable time frame).
> >
> >  I tried the Eglot integration, my comments elsewhere are inspired by
> >  that.
> >
> > Can you point me to this "elsewhere"?
>
> Elsewhere in this thread - my message on Tue, 07 Nov 2023 11:51:49 -0500

OK, I found it.  It's useful, and very commonly done, if you CC the
participants in this discussion, particularly when addressing their
contributions.
Your emails are sent only to emacs-devel and it's easier for me to
miss them.

> >  I found it rather clumsy out of the box.
> >
> > What exactly is clumsy? Please state the command you used and what the 
> > clumsy effects were.
>
> Specifically xref-find-extras is clumsy, because it's annoying to have
> to type the full "kind" in to request a specific "kind" of definition.

I don't find it annoying.  But since we settled long ago that there can
be no standard set of all kinds that makes sense for all languages, then
I don't see a better way than what the current xref patch does now: asking
the backend for kinds and then having one command with an additional selection
step.  The little change I did to Dmitry's xref.el allows particular modes
such as Eglot to implement their own "quick-access" commands for a particular
kind more easily.

> eglot-find-{declaration,implementation,typeDefinition} is good as
> always.

Right.  And they're not going away anytime soon.
>
> >  However, it works well with an
> >  approach of adding bindings for individual kinds, as is currently how I
> >  (and other Eglot users at Jane Street, and presumably most other Eglot
> >  users everywhere) use Eglot.  So that compatibility with an
> >  already-common approach is an upside of this integration.
> >
> > Bindings to what commands exactly?
>
> eglot-find-{declaration,implementation,typeDefinition}
>
> >  However, the alternative UI which shows all kinds of definitions in a
> >  single buffer does not exist for Eglot in the same way it exists for
> >  Elisp.  So... I can't really compare it to that.
> >
> > What "alternative UI" are you talking about exactly? How can I trigger it 
> > for Elisp? Please give a full example as I don't know what
> > you are taking about.
>
> In Elisp, M-. (xref-find-definitions) already shows all the kinds of
> definitions that are requestable through xref-find-extras.  But there's
> no similar way to show all kinds of definitions for Eglot - M-. only
> includes the proper definition, not the declaration and typeDefinition
> and so on.

As it always did.  And you yourself wrote

 > 90% of the time, in 90%
 > of languages, there's a clear meaning of "definition" and I want M-. to
 > take me there directly rather than prompting in any way.

And I fully agree, btw.  So I don't understand why you sometimes want
prompting and sometimes no prompting.

But you can discuss that with Dmitry about the UI parts. I'm just
really interested
in the xref.el <-> eglot.el API.  I want it to be as simple and
versatile as possible,
much like it is now.

> I know you would prefer not to implement such a thing, I'm just
> explaining for Dmitry that since this kind of UI doesn't exist, I can't
> compare xref-find-extras against that kind of UI for Eglot in the same
> way that I can with Elisp.

It's not really about not wanting.  It's an incompatible change.  Users
used to M-. on an identifier and going to the definition would now
see an *xref* buffer to click on.  And it would break the only command
where C-u M-. to prompt for the identifier first can possibly work in LSP.

But, I think your idea that passing nil (or 't' or 'all') as KIND
to xref-find-extra makes it ask xref-backend-extra-defs (which should
be renamed to not have that misleading "defs") for all kinds previously
reported by the backend in xref-backend-extra-kinds.

Then the UI can organize the results as it sees fit, and I don't have
any strong opinions on how it should do that, nor any strong opinions
as to how many C-u or variables should modify the new command behaviour.

That's not to say I don't have opinions, just not opinions strong enough to
justify not pushing a draft version of the current patch into master.

João