emacs-eglot fails after upgrade to emacs-29.3

  • Open
  • quality assurance status badge
Details
3 participants
  • Lilly
  • Nicolas Graves
  • hiecaq
Owner
unassigned
Submitted by
Lilly
Severity
normal
L
L
Lilly wrote on 5 Apr 2024 09:25
(name . bug-guix@gnu.org)(address . bug-guix@gnu.org)
EEX8t_3SL6F_lyYYjoaEcA4sEFigaq2n92Zaish9vhqmRgkmPXl272yhxAdjarfo9okVQZgJYhiqlNc4FoMPkqJmc1mQPbFXLdnD5pcI5bc=@proton.me
Hi,

after upgrading to emacs 29.3 eglot fails to start with an error message like

Invalid slot name: "#<eglot-lsp-server eglot-lsp-server-cacbec>", :events-buffer-config

This also happens if I start emacs with 'emacs -q' and activate just eglot manually.

I'm using not the build-in eglot package, but emacs-eglot@1.17. This package has a dependency to emacs-jsonrpc@1.0.23
Upgrading jsonrpc to version 1.0.25 solved the issue for me.

Yours,
Lilly
Attachment: file
H
H
hiecaq wrote on 10 Apr 2024 16:49
(address . 70211@debbugs.gnu.org)(name . Lilly)(address . lilly.ra@proton.me)
87cyqxs25l.fsf@hiecaq.org
Lilly via Bug reports for GNU Guix <bug-guix@gnu.org> writes:

Toggle quote (18 lines)
> Hi,
>
> after upgrading to emacs 29.3 eglot fails to start with an error
> message like
>
> Invalid slot name: "#<eglot-lsp-server
> eglot-lsp-server-cacbec>", :events-buffer-config
>
> This also happens if I start emacs with 'emacs -q' and activate
> just eglot manually.
>
> I'm using not the build-in eglot package, but emacs-eglot@1.17.
> This package has a dependency to emacs-jsonrpc@1.0.23
> Upgrading jsonrpc to version 1.0.25 solved the issue for me.
>
> Yours,
> Lilly

I also encountered this on my Guix configuration (on a foreign
distro). I tried to investigate into it, but I got confused.

The error message I got is:
Toggle quote (3 lines)
> slot-missing: Invalid slot name: "#<eglot-lsp-server
> eglot-lsp-server-170231c>", :events-buffer-config

However, events-buffer-config (it is defined in
jsonrpc-connection, and eglot-lsp-server inherits that if I read
correctly) is introduced in jsonrpc.el at
e0b9944b69ff72923c29756fcfcea9528a3f5069, which is included in
1.0.23.
H
H
hiecaq wrote on 13 Apr 2024 12:58
(address . 70211@debbugs.gnu.org)(name . Lilly)(address . lilly.ra@proton.me)
875xwlbkb2.fsf@hiecaq.org
Lilly via Bug reports for GNU Guix <bug-guix@gnu.org> writes:

Toggle quote (2 lines)
> Upgrading jsonrpc to version 1.0.25 solved the issue for me.

Hi, the above solution does not work for me so I tried to dig into
the problem further, and I think I've moved closer to the real
cause of this problem.

TLDR:

This issue is more close related to jsonrpc instead of eglot, and
putting
Toggle quote (1 lines)
> (setq load-no-native t)
In early-init.el fixes the problem for me.

The first thing I noticed is that if we look up
"jsonrpc-connection", Help page tells us that it is a
native-compiled function, which is the hint to my following
attempts because in my configurations packages are only
byte-complied and not native-compiled, while built-ins are
native-compiled. This can be quickly checked if you open the
jsonrpc.elc file. (and I believe that it is the same case for the
upstream Guix)

Also, if you visit the "jsonrpc-connection"'s class Help page, it
shows that it does not have a slot named
"events-buffer-config". Instead it has
"events-buffer-scrollback-size", which reflects the corresponding
file in 29.3 built-in.

So my guess is that Emacs somehow prefers the native-compiled
version (from the built-in) over the byte-compiled version (from
the package), even if the latter is newer. I do have "(setq
load-prefer-newer t)" in my early-init.el, but it still works that
way. I'm not sure why the package loading works as expected before
recent updates in Guix though.
N
N
Nicolas Graves wrote on 11 Jan 12:07 +0100
87msfxvcbq.fsf@ngraves.fr
Hi guys,

I think this issue is fixed with the patches in 67292. Can you try them
and merge or close this issue after that? Thanks!

--
Best regards,
Nicolas Graves
?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 70211@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 70211
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch