bug#81624: New command: xref-find-by-kind

Dmitry Gutov <[email protected]> writes:

> On 16/08/2026 14:55, João Távora wrote:
>> Dmitry Gutov <[email protected]> writes:
>> 
>>> X-Debbugs-Cc: [email protected], [email protected]
>>> See the branch 'xref-find-by-kind', feedback welcome!
>> I've skimmed the diff (on my mobile) and my overall feedback is
>> positive.
>
> Hey, thanks for the feedback.
>
>> One thing I'd like to see address: what to do about
>>     (defun eglot-find-declaration...
>>     (defun eglot-find-implementation...
>>     (defun eglot-find-typeDefinition...
>> ?
>> I'd like to see them rewritten using new xref.el entry points, but
>> xref-backend-xrefs-by-kind is just a "get information" entry point
>> (which is fine).
>
> I would expect these commands to stay around for a while, but
> delegating them to the current xref backend seems wrong?

I see, but not sure aout that.  Not sure other backends would have the
particulra LSP kinds.  If they did, it was probably intentional setup by
the user (who setup up eglot-stay-out to leave xref alone).  And in that
case, probably fine to use the non-LSP versio.  Probably fine either
way.  There's nothing of the kind I've heard off, so a moot problem for
now.

> are several of them available in a buffer, and eglot is not the
> current #1, I would expect the commands eglot-find-* to still use
> Eglot, as a user. In some configurations I would take advantage of
> that.
>
> So practically speaking I might update these definitions with the new
> feature of completion from workspace, but not make them overly
> generic.
>
> If they *were* made generic, we might want them renamed to proper
> xref-find-*, and IIRC you argued against having built-in commands
> encoding the list of kinds in xref core. So for the below examples
> with 'xref-define-finder', do you envision them living in the user
> init scripts?

Except for "definition" and "reference" I don't think,
xref-find-<lsp-specific-thing> or xref-find-<language-x-specific-thing>
should exist, no :-).

> to define them early. Here's what these definitions would look like,
> in all their plan function glory:

> (defun eglot-find-declaration (identifier)
>   "Find declarations for IDENTIFIER."
>   (interactive (list (xref--read-identifier "Find declarations of: ")))
>   (xref-find-by-kind identifier '(:kind declaration :name "declaration")))

That works perfectly, and I can do the macro in Eglot if useful.  Except
for the use of the '--' function.  Can you export it?  I can bend the
rules a little bit and use your private function anyway, wouldn't be the
first time.

> A bit longer. But if the list of kinds does not grow, and stays at
> three elements for years for the vast majority of people (I've checked
> out updates to LSP and new servers, and no new kinds have appeared in
> the last 3 years), then maybe the saving won't be large.

It's fine.  And if the list does grow, I'll make the macro myself.

> Happy to discuss the options in both directions.
>
> My personal feeling though is that the command xref-find-by-kind can
> serve as a good replacement for a submap, with dispatch taking the
> same number of keys, so the need for additional commands would be
> limited to exceptional cases. Or would many users not group them in a
> submap anyway?

I haven't tried it but it looks fine in general. It seems to be backward
compatible to everything Eglot does and adds a resonable small amount of
code to it, and that code is legible.

>> :format key entry in the kind
>>     (:kind declaration :name "declaration" :key ?d :prompt-format
>> "Find %s of")
>> Not sure it's worth it, but not very hard to do either, I suppose.
> That should work, thanks! I'm not sure about the tradeoffs, but it's a
> good solution if the problem really bites.

Probably no drawbacks other than a small amount of complexity.  But no
gigantic gain either.  I don't think anyone will ever complain, if you
do it it'll just read a little nicer.

João