Hi Antoine and Lev! Antoine Beaupré <anar...@debian.org> writes:
> That didn't work, but I manually bisected my .emacs.d/init.el file and
> came up with this minimal reproducer:
>
> (when (require 'package nil t)
> (setq-default
> load-prefer-newer t
> package-enable-at-startup nil)
> (package-initialize)
I wonder if this "(package-initialize)" line, while using Emacs >= 27 is
exposing a bug in lsp-mode? Since Emacs 27 now automatically runs
package-initialize in between the new early-init.el and the classic
.emacs.el/init.el/etc, maybe lsp-mode has an autoload cookie that gets
evaluated twice, leading to the broken state of the lsp sentinel?
Alternatively, maybe lsp-mode now assumes we live in a post-Emacs 27
world where all users have already dropped package-initialize from their
configs?
These Emacs >= 27 changes also affect the point in emacs init where
package-enable-at-startup can be set:
If non-nil, packages are made available before reading the init file
(but after reading the early init file). This means that if you
wish to set this variable, you must do so in the early init file.
I think this bug is still valid and actionable even if removing
package-initialize from the minimum reproducer, and/or after moving
package-enable-at-startup to early-init.el makes the bug unreproducible.
If nothing else, it seems like our src:emacs might need a NEWS entry on
the topic, but that said, my suspicion is that lsp-mode could be more
defensive.
Cheers,
Nicholas
signature.asc
Description: PGP signature
