Subject: bug#78637: 30.1.90; Calling setopt during init loads cus-start over and over

From: Eli Zaretskii <[email-masked]>
Date: Sat, 07 Jun 2025 12:25:36 +0300

> From: Stefan Monnier <[email-masked]>
> Cc: [email-masked],  [email-masked],  [email-masked]
> 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.