Hi Nicholas, Чт 29 апр 2021 @ 13:54 Nicholas D Steeves <nstee...@gmail.com>:
> 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. That's interesting! Thanks for your input. I've tried Antoine's minimal configuration and can confirm that commenting out (package-initialize) resolves the problem. So, it really means that lsp-mode has an autoload cookie which when evaluated twice causes the bug. But now I wonder to which package should we assign the bug report, lsp-mode, emacs, some other package?.. Cheers! Lev
