GNU bug report logs - #78637
30.1.90; Calling setopt during init loads cus-start over and over

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 78637 <at> debbugs.gnu.org, app-emacs-dev <at> janestreet.com, azeng <at> janestreet.com
Subject: bug#78637: 30.1.90; Calling setopt during init loads cus-start over and over
Date: Sat, 07 Jun 2025 12:25:36 +0300

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: azeng <at> janestreet.com,  78637 <at> debbugs.gnu.org,  app-emacs-dev <at> janestreet.com
> Date: Sun, 01 Jun 2025 12:30:54 -0400
> 
> > Does this explain what I see: that loading cus-start via 'require'
> > during processing of the init file signals an error, like I show in my
> > previous message?
> 
> Yes.
> 
> > If so, could you explain why do we signal an error in that case?
> 
> We don't do it on purpose, of course, but the code protected by the
> `(unless after-init-time` test presumes that
> `custom-delayed-init-variables` contains a list whereas this assumption
> is true only while dumping and at the very beginning of the
> startup sequence.
> 
> So the code work fine if run:
> 
> - during dump or very early startup, when
>   `custom-delayed-init-variables` still contains a list.
> - after loading the init file, thanks to the `(unless after-init-time` test.
> 
> But not between those two (i.e. not from within the init file).
> The effect of that code is to fill `custom-delayed-init-variables`
> during the dump for subsequent use in the very early startup, hence my
> patch replaces the `(unless after-init-time` by `(if dump-mode.

Thanks, feel free to install your changes and close the bug.

Previous Next

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