Re: Adding support for xref jumping to headers/interfaces

[Spencer Baugh]

João Távora <joaotavora@gmail.com> writes:
> On Fri, Nov 10, 2023 at 5:36 PM Spencer Baugh <sbaugh@janestreet.com> wrote:
>> 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.

Oh, this is very convincing.  In fact, I am fully convinced.

Major modes should define their own commands for the functionality
supported by that language.  So e.g. c-ts-mode could define
c-find-signature, which has a clear meaning for C.  And likewise for
refactorings which only make sense in a given language.

And we could reserve single-character bindings under M-' (or something)
for the major mode.  For example:
(keymap-set emacs-lisp-mode-map "M-' g" emacs-lisp-find-generic)
(keymap-set c-mode-map "M-' s" c-find-signature)

Reliably using bindings under M-' even if those bindings point to
mode-specific commands is enough consistency for me.  Using literally
the same command in each major-mode is not necessary.

That's everything that I wanted from adding xref-find-declaration and so
on in the core, so I agree, actually, we don't need standard kinds in
the core or anything, as long as we actually do something to encourage
common bindings.

(And maybe we could use M-' M-r as a prefix for mode-specific
refactoring commands.  Perhaps if we use this M-' prefix it can be the
start of encouraging more binding consistency between programming
language major modes, which I find is something sadly lacking.  Maybe at
first there could be a customization which changes M-', and we could
hope to change it by default in a subsequent release.)