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

From: Po Lu <[email-masked]>
Date: Thu, 26 Jun 2025 00:07:59 +0800

Eli Zaretskii <[email-masked]> writes:

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

These changes prevented standard variables from being initialized on
Android, which was detected by my automated testing system and which
I've attempted to address specifically for that system, but I get the
impression that Stefan's solution also produces the very same issues on
configurations --with-dumping=none.  Hence the correct solution lies
elsewhere.

I'm sorry I can't be of more assistance, but my hands are too full at
the present.