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

From: Eli Zaretskii <[email-masked]>
Date: Sun, 01 Jun 2025 12:40:16 +0300

> From: Stefan Monnier <[email-masked]>
> Cc: Aaron Zeng <[email-masked]>,  [email-masked],
>   [email-masked]
> Date: Sat, 31 May 2025 14:04:39 -0400
> 
> >> I believe this can be fixed with the following patch.  On my machine,
> >> this patch reduces the runtime of the original init file to 75ms and
> >> causes the prepended code to make no difference to the runtime.
> >> 
> >> diff --git a/lisp/cus-start.el b/lisp/cus-start.el
> >> index 91cc6e22152..e82e97e87ca 100644
> >> --- a/lisp/cus-start.el
> >> +++ b/lisp/cus-start.el
> >> @@ -934,7 +934,7 @@ minibuffer-prompt-properties--setter
> >>        ;; This is used by describe-variable.
> >>        (if version (put symbol 'custom-version version))
> >>        ;; Don't re-add to custom-delayed-init-variables post-startup.
> >> -      (unless after-init-time
> >> +      (when (listp custom-delayed-init-variables)
> >>  	;; Note this is the _only_ initialize property we handle.
> >>  	(if (eq (cadr (memq :initialize rest)) #'custom-initialize-delay)
> >>  	    ;; These vars are defined early and should hence be initialized
> 
> I'm sorry I was dense, but yes it looks like you found the culprit.
> 
> > I think this patch changes behavior, so it is not TRT.  But before we
> > discuss how to fix the problem, let's be sure we understand the
> > problem and its reason(s).
> 
> I think the patch below is a cleaner version of the patch above and
> I think it does do TRT: `custom-delayed-init-variables` is used only at
> early startup to force re-evaluation of some of the preloaded (a.k.a
> dumped) variables; after that it should simply not be used and adding
> entries to it is pointless.

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?  If so, could you explain why do we signal an error
in that case?