GNU bug report logs -
#78250
31.0.50; Eglot: eglot-show-call-hierarchy
Previous Next
Reported by: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Date: Mon, 5 May 2025 03:37:02 UTC
Severity: normal
Found in version 31.0.50
Done: João Távora <joaotavora <at> gmail.com>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 78250 in the body.
You can then email your comments to 78250 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78250; Package
emacs.
(Mon, 05 May 2025 03:37:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Gerd Möllmann <gerd.moellmann <at> gmail.com>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Mon, 05 May 2025 03:37:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78250; Package
emacs.
(Thu, 08 May 2025 10:38:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 78250 <at> debbugs.gnu.org (full text, mbox):
> 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?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78250; Package
emacs.
(Thu, 08 May 2025 11:54:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 78250 <at> debbugs.gnu.org (full text, mbox):
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))))
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78250; Package
emacs.
(Thu, 08 May 2025 12:28:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 78250 <at> debbugs.gnu.org (full text, mbox):
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!
Reply sent
to
João Távora <joaotavora <at> gmail.com>:
You have taken responsibility.
(Thu, 08 May 2025 20:44:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Gerd Möllmann <gerd.moellmann <at> gmail.com>:
bug acknowledged by developer.
(Thu, 08 May 2025 20:44:02 GMT)
Full text and
rfc822 format available.
Message #19 received at 78250-done <at> debbugs.gnu.org (full text, mbox):
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]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78250; Package
emacs.
(Fri, 09 May 2025 00:14:02 GMT)
Full text and
rfc822 format available.
Message #22 received at 78250-done <at> debbugs.gnu.org (full text, mbox):
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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78250; Package
emacs.
(Fri, 09 May 2025 03:46:02 GMT)
Full text and
rfc822 format available.
Message #25 received at 78250-done <at> debbugs.gnu.org (full text, mbox):
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?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78250; Package
emacs.
(Fri, 09 May 2025 08:22:02 GMT)
Full text and
rfc822 format available.
Message #28 received at 78250-done <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78250; Package
emacs.
(Fri, 09 May 2025 08:39:02 GMT)
Full text and
rfc822 format available.
Message #31 received at 78250-done <at> debbugs.gnu.org (full text, mbox):
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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78250; Package
emacs.
(Fri, 09 May 2025 08:52:02 GMT)
Full text and
rfc822 format available.
Message #34 received at 78250-done <at> debbugs.gnu.org (full text, mbox):
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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78250; Package
emacs.
(Fri, 09 May 2025 10:43:01 GMT)
Full text and
rfc822 format available.
Message #37 received at 78250 <at> debbugs.gnu.org (full text, mbox):
> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78250; Package
emacs.
(Sun, 11 May 2025 12:53:01 GMT)
Full text and
rfc822 format available.
Message #40 received at 78250 <at> debbugs.gnu.org (full text, mbox):
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
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Mon, 09 Jun 2025 11:24:09 GMT)
Full text and
rfc822 format available.
This bug report was last modified 8 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.