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

Previous Next

To reply to this bug, email your comments to 78250 AT debbugs.gnu.org.
There is no need to reopen the bug first.

Toggle the display of automated, internal messages from the tracker.

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 31.0.50; Eglot: eglot-show-call-hierarchy
Date: Mon, 05 May 2025 05:36:39 +0200

In GNU Emacs 31.0.50 (build 1, aarch64-apple-darwin24.4.0) of 2025-05-04

This is in an Emacs repository, with clangd 20.1 installed via Homebrew
on macOS.

In insdel.c, navigate to function insert_and_inherit, then, on the
function name, C-u M-x eglot-show-call-hierarchy RET and choose
outgoing.

The resulting buffer looks like this:

  [-]  ∘ insert_and_inherit
   |-[+]  → chars_in_text
   |-[+]  → insert_1_both
   |-[+]  → signal_after_change
   `-[+]  → update_compositions

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.

2. Bug: Clicking on "chars_in_text" in the tree above takes me here:

character.c:
  586 ptrdiff_t
  587 str_as_multibyte (unsigned char *str, ptrdiff_t len, ptrdiff_t nbytes,
  588                   ptrdiff_t *nchars)
  589 {

Clicking on "insert_1_both" OTOH takes me here which is correct

insdel.c:
  581 void
  582 insert_and_inherit (const char *string, ptrdiff_t nbytes)
  583 {
  584   if (nbytes > 0)
  585     {
  586       ptrdiff_t len = chars_in_text ((unsigned char *) string, nbytes), opoint;
  587       insert_1_both (string, len, nbytes, 1, 1, 0);

Clicking on "signal_after_change" is also correct, and clicking on
update_compositions is incorrect again.

The outgoing call tree I get from eglot-supplements does all correctly.

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

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

> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> Date: Mon, 05 May 2025 05:36:39 +0200
> 
> In GNU Emacs 31.0.50 (build 1, aarch64-apple-darwin24.4.0) of 2025-05-04
> 
> This is in an Emacs repository, with clangd 20.1 installed via Homebrew
> on macOS.
> 
> In insdel.c, navigate to function insert_and_inherit, then, on the
> function name, C-u M-x eglot-show-call-hierarchy RET and choose
> outgoing.
> 
> The resulting buffer looks like this:
> 
>   [-]  ∘ insert_and_inherit
>    |-[+]  → chars_in_text
>    |-[+]  → insert_1_both
>    |-[+]  → signal_after_change
>    `-[+]  → update_compositions
> 
> 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.
> 
> 2. Bug: Clicking on "chars_in_text" in the tree above takes me here:
> 
> character.c:
>   586 ptrdiff_t
>   587 str_as_multibyte (unsigned char *str, ptrdiff_t len, ptrdiff_t nbytes,
>   588                   ptrdiff_t *nchars)
>   589 {
> 
> Clicking on "insert_1_both" OTOH takes me here which is correct
> 
> insdel.c:
>   581 void
>   582 insert_and_inherit (const char *string, ptrdiff_t nbytes)
>   583 {
>   584   if (nbytes > 0)
>   585     {
>   586       ptrdiff_t len = chars_in_text ((unsigned char *) string, nbytes), opoint;
>   587       insert_1_both (string, len, nbytes, 1, 1, 0);
> 
> Clicking on "signal_after_change" is also correct, and clicking on
> update_compositions is incorrect again.
> 
> The outgoing call tree I get from eglot-supplements does all correctly.

João, any suggestions or comments?

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

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

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.

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).

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. 

>> 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.

João

diff --git a/lisp/progmodes/eglot.el b/lisp/progmodes/eglot.el
index d33b0b05fd4..e666389596d 100644
--- a/lisp/progmodes/eglot.el
+++ b/lisp/progmodes/eglot.el
@@ -4601,7 +4601,7 @@ eglot-hierarchy-label-map
     map)
   "Keymap active in labels Eglot hierarchy buffers.")
 
-(defun eglot--hierarchy-label (node)
+(defun eglot--hierarchy-label (node parent-uri)
   (eglot--dbind ((HierarchyItem) name uri _detail ((:range item-range))) node
     (with-temp-buffer
       (insert (propertize
@@ -4617,7 +4617,7 @@ eglot--hierarchy-label
        'keymap eglot-hierarchy-label-map
        'action
        (lambda (_btn)
-         (pop-to-buffer (find-file-noselect (eglot-uri-to-path uri)))
+         (pop-to-buffer (find-file-noselect (eglot-uri-to-path (or parent-uri uri))))
          (eglot--goto
           (or
            (elt
@@ -4657,12 +4657,13 @@ eglot--hierarchy-2
   (cl-labels ((expander-for (node)
                 (lambda (_widget)
                   (mapcar
-                   #'convert
+                   (lambda (n)
+                     (convert n (plist-get node :uri)))
                    (eglot--hierarchy-children node))))
-              (convert (node)
+              (convert (node parent-uri)
                 (let ((w (widget-convert
                           'tree-widget
-                          :tag (eglot--hierarchy-label node)
+                          :tag (eglot--hierarchy-label node parent-uri)
                           :expander (expander-for node))))
                   (widget-put w :empty-icon
                               (widget-get w :leaf-icon))
@@ -4670,7 +4671,7 @@ eglot--hierarchy-2
     (let ((inhibit-read-only t))
       (erase-buffer)
       (mapc (lambda (r)
-              (let ((w (widget-create (convert r))))
+              (let ((w (widget-create (convert r nil))))
                 (widget-apply-action w)))
             eglot--hierarchy-roots)
       (goto-char (point-min))))

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!

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

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

Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:

> 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".

Why not go to that line with TAB, instead of mixing C-n and TAB?

>> dependency on a new graph-representation library.  Perhaps you could
>> lift the bespoke one that profiler.el uses into a new library?  Call it
> Well, what can I say :-). I don't feel that's something for me, sorry.

What can _I_ say, except "it's your itch" :-)".  Well if you don't want
to work on a better solution you can always bind keys to whatever you
like in eglot-hierarchy-mode-map.

>> 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.

Haven't looked, but if it's good, ask the author to bring it into Emacs.

>> Anyway, please try the patch after my sig.  It fixes the mis-navigations
>> you reported.
>
> Yes, that works. Thanks for the fix!

I'll push it as soon as savannah recovers (seems to be down now).

João

PS: if you use clangd on Emacs' repo, here's a patch to .clangd you
might like. 

diff --git a/.clangd b/.clangd
index 469d33dfd03..5c7308d64ae 100644
--- a/.clangd
+++ b/.clangd
@@ -2,4 +2,5 @@
 If:
     PathMatch: "src/*.c"
 CompileFlags:
-    Add: [-Wno-unused-macros, -include=config.h]
+    Add: [-Wno-unused-macros, -include=config.h, -fstrict-flex-arrays=3]
+    Remove: [-fstrict-flex-arrays]

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

From: João Távora <joaotavora <at> gmail.com>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 78250-done <at> debbugs.gnu.org
Subject: Re: bug#78250: 31.0.50; Eglot: eglot-show-call-hierarchy
Date: Fri, 9 May 2025 01:13:42 +0100

On Thu, May 8, 2025 at 9:42 PM João Távora <joaotavora <at> gmail.com> wrote:

> > Yes, that works. Thanks for the fix!
>
> I'll push it as soon as savannah recovers (seems to be down now).

Done.

Message #25 received at 78250-done <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: Eli Zaretskii <eliz <at> gnu.org>, 78250-done <at> debbugs.gnu.org
Subject: Re: bug#78250: 31.0.50; Eglot: eglot-show-call-hierarchy
Date: Fri, 09 May 2025 05:45:05 +0200

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

> PS: if you use clangd on Emacs' repo, here's a patch to .clangd you
> might like. 
>
> diff --git a/.clangd b/.clangd
> index 469d33dfd03..5c7308d64ae 100644
> --- a/.clangd
> +++ b/.clangd
> @@ -2,4 +2,5 @@
>  If:
>      PathMatch: "src/*.c"
>  CompileFlags:
> -    Add: [-Wno-unused-macros, -include=config.h]
> +    Add: [-Wno-unused-macros, -include=config.h, -fstrict-flex-arrays=3]
> +    Remove: [-fstrict-flex-arrays]

Hm, is there something wrong with the flexible array members in Emacs?

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

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

Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:

> João Távora <joaotavora <at> gmail.com> writes:
>
>> diff --git a/.clangd b/.clangd
>> index 469d33dfd03..5c7308d64ae 100644
>> --- a/.clangd
>> +++ b/.clangd
>> @@ -2,4 +2,5 @@
>>  If:
>>      PathMatch: "src/*.c"
>>  CompileFlags:
>> -    Add: [-Wno-unused-macros, -include=config.h]
>> +    Add: [-Wno-unused-macros, -include=config.h, -fstrict-flex-arrays=3]
>> +    Remove: [-fstrict-flex-arrays]
>
> Hm, is there something wrong with the flexible array members in Emacs?

No reason to think so, but I get a "unknown flag -fstrict-flex-arrays"
diagnostic from clangd (both versions 19 and 21git), which I presume
comes from that flag being mentioned in compile_commands.json but not
understood by the clang compiler that lives in clangd.  These are
relatively common in projects with very specific flags.  The patch above
fixes the situation while also telling clangd that we are using strict
flex arrays (in case that influences its analysis).

If you don't get that diagonstic, perhaps you're using a hand-rolled
compile_commands.json.  I used simply `bear -- make` to create mine
after deleting src/*.o.

João

Message #31 received at 78250-done <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: Eli Zaretskii <eliz <at> gnu.org>, 78250-done <at> debbugs.gnu.org
Subject: Re: bug#78250: 31.0.50; Eglot: eglot-show-call-hierarchy
Date: Fri, 09 May 2025 10:38:24 +0200

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

> Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
>
>> João Távora <joaotavora <at> gmail.com> writes:
>>
>>> diff --git a/.clangd b/.clangd
>>> index 469d33dfd03..5c7308d64ae 100644
>>> --- a/.clangd
>>> +++ b/.clangd
>>> @@ -2,4 +2,5 @@
>>>  If:
>>>      PathMatch: "src/*.c"
>>>  CompileFlags:
>>> -    Add: [-Wno-unused-macros, -include=config.h]
>>> +    Add: [-Wno-unused-macros, -include=config.h, -fstrict-flex-arrays=3]
>>> +    Remove: [-fstrict-flex-arrays]
>>
>> Hm, is there something wrong with the flexible array members in Emacs?
>
> No reason to think so, but I get a "unknown flag -fstrict-flex-arrays"
> diagnostic from clangd (both versions 19 and 21git), which I presume
> comes from that flag being mentioned in compile_commands.json but not
> understood by the clang compiler that lives in clangd.  These are
> relatively common in projects with very specific flags.  The patch above
> fixes the situation while also telling clangd that we are using strict
> flex arrays (in case that influences its analysis).
>
> If you don't get that diagonstic, perhaps you're using a hand-rolled
> compile_commands.json.  I used simply `bear -- make` to create mine
> after deleting src/*.o.

I don't have that flag in compile-commands.json, but maybe the
difference is that I also build with clang (macOS/arm64). The
compilation database is also from bear -- gmake.

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

From: João Távora <joaotavora <at> gmail.com>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 78250-done <at> debbugs.gnu.org
Subject: Re: bug#78250: 31.0.50; Eglot: eglot-show-call-hierarchy
Date: Fri, 9 May 2025 09:51:43 +0100

On Fri, May 9, 2025 at 9:38 AM Gerd Möllmann <gerd.moellmann <at> gmail.com> wrote:

> I don't have that flag in compile-commands.json, but maybe the
> difference is that I also build with clang (macOS/arm64). The
> compilation database is also from bear -- gmake.

That's likely the reason. I'm on GNU/Linux and using gcc.  I'll let
Eli decide if the patch is useful.  FWIW it's helpful here and doesn't
hurt any other case.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: João Távora <joaotavora <at> gmail.com>
Cc: gerd.moellmann <at> gmail.com, 78250 <at> debbugs.gnu.org
Subject: Re: bug#78250: 31.0.50; Eglot: eglot-show-call-hierarchy
Date: Fri, 09 May 2025 13:41:53 +0300

> From: João Távora <joaotavora <at> gmail.com>
> Date: Fri, 9 May 2025 09:51:43 +0100
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 78250-done <at> debbugs.gnu.org
> 
> On Fri, May 9, 2025 at 9:38 AM Gerd Möllmann <gerd.moellmann <at> gmail.com> wrote:
> 
> > I don't have that flag in compile-commands.json, but maybe the
> > difference is that I also build with clang (macOS/arm64). The
> > compilation database is also from bear -- gmake.
> 
> That's likely the reason. I'm on GNU/Linux and using gcc.  I'll let
> Eli decide if the patch is useful.  FWIW it's helpful here and doesn't
> hurt any other case.

If it can help in some cases and causes no harm in others, it's okay
to install that patch.

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

From: João Távora <joaotavora <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: gerd.moellmann <at> gmail.com, 78250 <at> debbugs.gnu.org
Subject: Re: bug#78250: 31.0.50; Eglot: eglot-show-call-hierarchy
Date: Sun, 11 May 2025 13:53:00 +0100

On Fri, May 9, 2025 at 11:41 AM Eli Zaretskii <eliz <at> gnu.org> wrote:

> If it can help in some cases and causes no harm in others, it's okay
> to install that patch.

I've done that . i don't work on Emacs C internals anymore, but it
helps me reproduce Gerd's Eglot bug reports.

João

Previous Next

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