GNU bug report logs - #76142
[PATCH] Eglot: do not activate unsupported menu items

Previous Next

To reply to this bug, email your comments to 76142 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: Felician Nemeth <felician.nemeth <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: [PATCH] Eglot: do not activate unsupported menu items
Date: Sat, 08 Feb 2025 12:13:37 +0100

[Message part 1 (text/plain, inline)]

Hi João,

This small patch follows the current tradition of disabling menu items
that are known not to work with the current server.

By the way, the new eglot-hierarchy-mode looks really nice.  I wonder
if outline-minor-mode cloud somehow be enabled here.  Or if
eglot-hierarchy-mode cloud be derived from outline-mode.  Their
navigation commands are quite useful.

Thanks.

[0001-Eglot-do-not-activate-unsupported-menu-items.patch (text/x-diff, attachment)]

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

From: João Távora <joaotavora <at> gmail.com>
To: Felician Nemeth <felician.nemeth <at> gmail.com>
Cc: 76142 <at> debbugs.gnu.org
Subject: Re: bug#76142: [PATCH] Eglot: do not activate unsupported menu items
Date: Sat, 8 Feb 2025 11:18:49 +0000

Thanks, felicián.  Feel free to push and close this issue.

Re outline mode, I'm not sure it would help.  You can already use tab
to navigate buttons.
What do other modes that display tree widgets from tree-widget.el do?

João

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

From: Felician Nemeth <felician.nemeth <at> gmail.com>
To: João Távora <joaotavora <at> gmail.com>
Cc: 76142 <at> debbugs.gnu.org
Subject: Re: bug#76142: [PATCH] Eglot: do not activate unsupported menu items
Date: Sat, 08 Feb 2025 12:45:44 +0100

> Thanks, felicián.  Feel free to push and close this issue.

I don't have access rights to push.

> Re outline mode, I'm not sure it would help.  You can already use tab
> to navigate buttons.

I have not used call hierarchies long enough to have a strong opinion,
but maybe starting with fully open hierarchy is more useful than the
current closed one.  For example:

[-]  ∘ funcb
 |-[-]  ← funca
 |  `-   ← main
 `-   ← main

vs:

[+]  ∘ funcb

And in the former case, 'Up' and 'Next Same Level' commands can be
useful.

> What do other modes that display tree widgets from tree-widget.el do?

I don't know.  If Eglot just relies on the tree-widget library, then
maybe that library should be enhanced with more navigation commands
instead.

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

From: João Távora <joaotavora <at> gmail.com>
To: Felician Nemeth <felician.nemeth <at> gmail.com>
Cc: 76142-done <at> debbugs.gnu.org
Subject: Re: bug#76142: [PATCH] Eglot: do not activate unsupported menu items
Date: Sat, 8 Feb 2025 13:31:34 +0000

On Sat, Feb 8, 2025 at 11:45 AM Felician Nemeth
<felician.nemeth <at> gmail.com> wrote:
>
> > Thanks, felicián.  Feel free to push and close this issue.
>
> I don't have access rights to push.

Ok, I pushed it for you.  I'll close the bug, but we can keep talking.

>
> > Re outline mode, I'm not sure it would help.  You can already use tab
> > to navigate buttons.
>
> I have not used call hierarchies long enough to have a strong opinion,
> but maybe starting with fully open hierarchy is more useful than the
> current closed one.

Opening the first node is feasible (and logical, since why else would
you invoke the hierarchy commands?) but expanding the whole tree
is impossible.  In general, especially when both directions are considered,
the tree is infinite.

> For example:
>
> [-]  ∘ funcb
>  |-[-]  ← funca
>  |  `-   ← main
>  `-   ← main
>
> vs:
>
> [+]  ∘ funcb
>
> And in the former case, 'Up' and 'Next Same Level' commands can be
> useful.

indeed.

> I don't know.  If Eglot just relies on the tree-widget library, then
> maybe that library should be enhanced with more navigation commands
> instead.

Yes.  tree-widget.el could come with some kind of tree-widget-mode with such
commands.  outline-mode is not a good choice, it's meant for plain text
with some markup.

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.  I think you should have commit rights to push to Eglot
directly.

João

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

From: Felician Nemeth <felician.nemeth <at> gmail.com>
To: João Távora <joaotavora <at> gmail.com>
Cc: 76142-done <at> debbugs.gnu.org
Subject: Re: bug#76142: [PATCH] Eglot: do not activate unsupported menu items
Date: Sat, 08 Feb 2025 21:01:08 +0100

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

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.

> I think you should have commit rights to push to Eglot directly.

Thanks.  I asked for commit rights at the savannah site.

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

From: João Távora <joaotavora <at> gmail.com>
To: Felician Nemeth <felician.nemeth <at> gmail.com>
Cc: 76142-done <at> debbugs.gnu.org
Subject: Re: bug#76142: [PATCH] Eglot: do not activate unsupported menu items
Date: Sun, 09 Feb 2025 00:22:25 +0000

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

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

From: Felician Nemeth <felician.nemeth <at> gmail.com>
To: João Távora <joaotavora <at> gmail.com>
Cc: 76142-done <at> debbugs.gnu.org
Subject: Re: bug#76142: [PATCH] Eglot: do not activate unsupported menu items
Date: Mon, 10 Feb 2025 18:10:59 +0100

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

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

If the detail is just the signature of a function as in the exaple of
the specification, then it can follow the name with a less important
face.  However, I think displaying the detail in the echo area with
eldoc would be better.

Currently a tag can only be "Deprecated", so the tag as a string can go
after the name.  Or the name can be printed with a warning face.  But an
eldoc message can also display the warning.

I personally do not need this, but I think people usually like to see
the "kind" field as an icon before the name.  company-box is an example
for this, but it is not in GNU ELPA.  Eglot cloud show icons if the
svg-lib package and a suitable icon collection were installed.  svg-lib
is in GNU ELPA.  Or Eglot cloud provide easy customizability for users
to implement this for themselves.

Would you be interested in any of these?

Previous Next

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