GNU bug report logs - #70211
emacs-eglot fails after upgrade to emacs-29.3

Previous Next

To reply to this bug, email your comments to 70211 AT debbugs.gnu.org.

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

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

From: Lilly <lilly.ra <at> proton.me>
To: "bug-guix <at> gnu.org" <bug-guix <at> gnu.org>
Subject: emacs-eglot fails after upgrade to emacs-29.3
Date: Fri, 05 Apr 2024 07:25:07 +0000

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

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 <at> 1.17. This package has a dependency to emacs-jsonrpc <at> 1.0.23
Upgrading jsonrpc to version 1.0.25 solved the issue for me.

Yours,
Lilly

[Message part 2 (text/html, inline)]

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

From: hiecaq <this <at> hiecaq.org>
To: 70211 <at> debbugs.gnu.org
Cc: Lilly <lilly.ra <at> proton.me>
Subject: Re: bug#70211: emacs-eglot fails after upgrade to emacs-29.3
Date: Wed, 10 Apr 2024 22:49:58 +0800

Lilly via Bug reports for GNU Guix <bug-guix <at> gnu.org> writes:

> 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 <at> 1.17. 
> This package has a dependency to emacs-jsonrpc <at> 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:
> 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.

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

From: hiecaq <this <at> hiecaq.org>
To: 70211 <at> debbugs.gnu.org
Cc: Lilly <lilly.ra <at> proton.me>
Subject: Re: bug#70211: emacs-eglot fails after upgrade to emacs-29.3
Date: Sat, 13 Apr 2024 18:58:57 +0800

Lilly via Bug reports for GNU Guix <bug-guix <at> gnu.org> writes:

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

Previous Next

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