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

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? E.g. if there 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?

> IIRC I suggested a 'xref-define-finder' macro
> 
>     (defmacro xref-define-finder (command kind) ...)
> 
> And then that trio of definitions could become
> 
>     (xref-define-finder eglot-find-declaration declaration)
>     (xref-define-finder eglot-find-implementation implementation)
>     (xref-define-finder eglot-find-typeDefinition type-definition)
> 
> And go almost exclusively through the same xref code paths as the other
> non-eglot-specific entry points and I we could bin that hacky
> eglot--lsp-xref-helper, offsetting some of the new complexity addition.

eglot--lsp-xref-helper is indeed hacky (having it go though 
xref-find-references particularly stands out) - we can improve it of course.

We could do a macro indeed, but with other things equal I prefer not 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")))

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

(defun eglot-find-typeDefinition (identifier)
   "Find type definitions for IDENTIFIER."
   (interactive (list (xref--read-identifier "Find type definitions of: ")))
   (xref-find-by-kind identifier '(:kind type-definition :name "type 
definition")))

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.

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?

> On a less important note
> 
>>     * lisp/progmodes/xref.el (xref-find-by-kind): Delete " of" from
>>     the identifier prompt.  I've gone back and forth on this - it
>>     reads a bit better with Eglot (LSP kinds) but does not fit the
>>     Elisp backend.
> 
> Heh, if you really wanted to go heroic/ocd you could make new optional
> :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.