Re: Adding support for xref jumping to headers/interfaces

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

On Fri, Nov 10, 2023 at 5:36 PM Spencer Baugh <sbaugh@janestreet.com> wrote:
>
> João Távora <joaotavora@gmail.com> writes:
> > On Fri, Nov 10, 2023 at 12:15 PM Spencer Baugh <sbaugh@catern.com> wrote:
> >> > 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.
>
> And refactor-code-actions will behave like the current
> eglot-code-actions, and prompt for code actions iff there are multiple
> possible actions that can be taken?  I know you prefer that workflow
> personally, but some people like keybindings to do common tasks
> directly.

Yes, and there will be eglot-* commands for those common LSP-specific
tasks yet, just like there are these commands today.

eglot-code-action-quickfix
eglot-code-action-organize-imports

etc.  The only difference is not user visibile and is that they
are to be defined internally with a macro from refactor.el.

> For example, do you expect to support symbol renaming in refactor.el?
> That if anything seems like something which deserves its own binding.

Yes, it will have its own command, and you can discuss with the
bindings people to bind it to some key, I won't oppose it.
refactor-rename is analogous xref-find-definition, it's a concept
that we're very confident that we can provide in all refactoring
backends, LSP or not.

> That being said, maybe we could have mode-specific commands and bindings
> for these things.  So if something is supported in a language, a major
> mode could make a binding for that.  And then, just, we might encourage
> using the same bindings in each mode that binds something.

Aha!  Yes, of course.  That's the Emacs way.  The advent of LSP sometimes
makes us forget that LSP's tradeoffs are there because LSP doesn't have
the concept of mode or any kind of programming language.  That's why
it is so stiff sometimes.  But we do, we have a existing abstraction
for dealing with languages, the major mode, a pretty flexible one.  And
we have a mature programming language.


This is why indiscriminately borrowing stuff from LSP should really
be frowned upon.  Doesn't mean flat-out reject it, but scrutinized
because tying ourselves down to LSP's inherent impotence is not
something we want to do in an editor with our time-proven strengths.

Instead, what we should do is lobby LSP to become more powerful.
We won't get it to run Elisp, but a lot of things could be done to
make Emacs/LSP integration even better.  Just one example, be able
to pass an arbitrary identifier to LSP's `textDocument/findFoo`.

But I'm the first one who should be doing that, and I'm not, because
I just don't have time, and the sad truth is that Emacs doesn't
carry that much weight  over there, unfortunately.

So what we should do in the long IMO is take advantage of Emacs
inherent advantage for language integrations so undeniably good
that more users come use it and then we have more negotiating
power.

So yes, c++-ts-mode can and should define, and possibly bind,  all those
xref.el and refactor.el  things that make sense for C++.  And if binding
consistency is a goal, then major mode authors should coordinate.  And we
can even have Elisp constructs that help this coordination and make
uncoordination difficult.

- Putting any talk about common xref APIs aside... Just to be clear, my
> understanding is that you have no problem with the idea of:
>
> - Teaching the elisp--xref-backend about separate 'cl-defgeneric and
>   'cl-defmethods kinds, which return the obvious things

Yes, no problem I think.  Didn't think much about this, but bear in mind
defgeneric forms can also have specific methods inside them.  So there
are at least to ways to put methods on generic function, not just
cl-defmethod.

Then macros come along.  I'm not sure the Elisp backend is good enough
to know that a macro expanding to cl-defmethod is a method-defining macro.
SLIME and SLY can most definitely do it.  But that's another problem.

> - Adding commands elisp-find-cl-{defgeneric,defmethods} which use those
>   kinds (and which fall back to the regular definitions)

No problem.  But have a look at how SLY and SLIME do this.  It's been
tested for a very long time today there.

I hope I can update SLY to use xref.el .  I tried once many years ago,
but failed, not really because of xref.el but because SLY's code is
very convoluted.>

> - Adding bindings in emacs-lisp-mode for calling those commands
> I'd like to do that independent of whatever we end up with, so just
> making sure you're not opposed to that, even though you might not be
> interested in using it.

No, not opposed at all to doing it.  Whether I'm interested in
using it it varies in time greatly.  My personal workflow changes
slowly over time, and of course it is influenced by the design
decisions, it is not set in stone.  But it does stick, to tell you
the truth, I'm still using C-h f foo RET C-x o TAB RET to go to
functions definitions when I don't have the symbol name under point.
I know there's C-u M-. but I'm so used to that other workflow that
I've used for 20 years, that I just can't let go.  Plus I
like that it makes me gloss over the docstring briefly.  When
programing C++ with Eglot, I do use C-u M-. of course.


João