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.
For example, do you expect to support symbol renaming in refactor.el?
That if anything seems like something which deserves its own binding.
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.
But I think we have made both our positions clear. I understand what
you want to do and I am completely against it, but this is not just
up for me to decide. The only thing that is, is that if I like the
new interfaces in xref.el I will implement them in eglot.el. The
UI that xref.el provides I can't control. Of course I recommend
keeping at least the current UI of xref-find-extra, not least because
it's something that has actually been implemented and I have
spent time integrating. And I also like your idea of KIND=nil to
make it show a sectioned listing using whatever kinds the backend
declares as section headings.
OK, fair enough, and I can see your point. I think we're both clear.
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
- Adding commands elisp-find-cl-{defgeneric,defmethods} which use those
kinds (and which fall back to the regular definitions)
- 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.