GNU bug report logs - #78250
31.0.50; Eglot: eglot-show-call-hierarchy

Previous Next

Full log

Message #14 received at 78250 <at> debbugs.gnu.org (full text, mbox):

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: João Távora <joaotavora <at> gmail.com>
Cc: 78250 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#78250: 31.0.50; Eglot: eglot-show-call-hierarchy
Date: Thu, 08 May 2025 14:27:16 +0200

João Távora <joaotavora <at> gmail.com> writes:

> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>>> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
>
> Hi Gerd,
>
>>> 1. Wishlist: Expanding/collapsing nodes and jumping to call sites is not
>>> easily reachable with the "usual" keys like TAG, RET, and so on that are
>>> used by the profiler, Magit etc. It would be very nice if that could be
>>> added.
>
> As far as I can see, TAB (I think you meant this) already invokes
> widget-forward when point is on a "widget".  It invokes button-forward
> when point is on a button.  So while there are no bindings in
> eglot-hierarchy-mode-map, you should be able to use those keys.  Also
> afaics, RET "does what you mean": it expands a node or or brings you to
> the locus of a call, depending where you hit it.

Yes, that's right. When on the [+] or the name behind that, things work.
Or when clicking with the mouse of course.

What I meant is, for example, when I C-n down to an interesting line and
press TAB or RET. I would have naively expected that to do something but
it only complains "buffer is read-only".

> Anyway, patches welcome.  However, I would favor the development of
> tree-widget-mode (or widget mode) where these bindings and UI is in
> effect.  Eglot is already using tree-widget.el.
>
> Alternatively, if you realy want to improve things, patches welcome to
> completely remove the dependency on tree-widget.el and replace it with a
> dependency on a new graph-representation library.  Perhaps you could
> lift the bespoke one that profiler.el uses into a new library?  Call it
> hierarchy2.el.  Then make a :core ELPA package out of that so that
> call/type hierarchies remain functional for ELPA-downloaded Eglot and
> backward compatible to Emacs 26/27/28/29/30 (maybe 26 could be ditched,
> I guess).

Well, what can I say :-). I don't feel that's something for me, sorry.

> Just a note that I've experimented with hierarchy.el (which uses
> tree-widget.el) and found it brings no benefit at all over directly
> calling tree-widget.el.

Just looked at eglot-supplements - it's using its own tree
implementation 'toggletree.el', AFAICT.

>
>>> 2. Bug: Clicking on "chars_in_text" in the tree above takes me here:
>
> Thanks, this is definitely a bug.  Pressing a button for a call site
> should take you to the site, not the definition of caller/callee.  There
> was a thinko here which made it only work for defininitions within the
> same LSP document.
>
> Note that there could be a separate binding to go to the definition of
> the caller/callee, as that information is also readily available.
> Perhaps Eglot could have an additional (small)
> eglot-hierarchy-xref-backend so that the normal M-. does what the user
> would expect from it (go to definition at point). Patches welcome here, too.
>
> Anyway, please try the patch after my sig.  It fixes the mis-navigations
> you reported.

Yes, that works. Thanks for the fix!

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.