Re: Adding support for xref jumping to headers/interfaces

[Spencer Baugh <sbaugh@janestreet.com>]

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.

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.

>> I think that would be a really helpful new feature, apart from all the
>> rest of this.
>>
>> If the term "declarations" and "implementations" are a problem, we could
>> totally give them another name.
>>
>> How about "find-generic" and "find-methods"?  Just literally copying
>> what Elisp calls them.  Then we can set aside all this worry about
>> sharing terms with LSP.
>>
>> So let me restate my proposal in those terms:
>>
>> I'd like an xref-find-generic which in Elisp jumps to the cl-defgeneric,
>
> So what would xref-find-generic do in C++ code?  It has no generics.
> Most languages have no generics.  Most programmers I know have never
> even heard of "generics".  "generic functions" even less so.  Why do
> you want to burden these non-Lisp people with this new concept
> from Common Lisp that they'll have to map to their own favourite
> language they want to do their work on?  And no, never will "generic"
> map clearly to the fundamental C/C++  concept of a declaration, for
> example.  Not to mention Java has templates called "generics".
> And C++ has templates called templates. Completely different concepts.
>
> So IMO this is just a very bad idea, I'm afraid.
>
> 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.