Subject: Re: bug#76142: [PATCH] Eglot: do not activate unsupported menu items

From: João Távora <[email-masked]>
Date: Sun, 09 Feb 2025 00:22:25 +0000

Felician Nemeth <[email-masked]> writes:

>> I also don't know what other LSP extensions do with this graph.  If you have
>> more ideas to make it more interactive, pretty, etc, feel free to let me know
>> or push patches.  
>
> It seems the current implementation ignores the tags, the detail, and
> the data fields of a CallHierarchyItem.

What would you do with the tags and detail?  For example, graphically,
where would you put it?

> The detail is probably useful to show.  I don't like the language of
> the LSP specification, but the way I understand it, the client MUST
> return the data field to the server.

It does that -- else it wouldn't work -- check the logs.

> Another approach to handle hierarchies is not to show the hierarchy
> itself, but to provide xref-like commands based on it:
> eglot-find-incoming-calls, eglot-find-outgoing-calls.  Eglot-x has a
> command named eglot-x-find-refs that dispatches additional
> reference-finding commands based on eglot-x--extra-refs-alist.  The
> alist is defined here:
> https://github.com/nemethf/eglot-x/blob/82c315c052e5a08c5307df4a4624049ee0e219e8/eglot-x.el#L564
>
> Since Eglot currently has five xref commands, maybe it is a good idea to
> provide a single-key dispatcher similar to eglot-x-find-refs in Eglot
> itself.

Maybe, but anything that interacts with xref is usually more complexity
and UI to think about.  I don't personally see a lot of use in this
though, iow, the hierarchy API is really good for showing the hierarchy.
And M-? for incoming calls is already sufficient, IMO.

João