GNU bug report logs -
#76142
[PATCH] Eglot: do not activate unsupported menu items
Previous Next
Full log
View this message in rfc822 format
Felician Nemeth <felician.nemeth <at> gmail.com> 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
This bug report was last modified 100 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.