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

Previous Next

Full log

Message #35 received at 78637 <at> debbugs.gnu.org (full text, mbox):

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: Re: bug#78637: 30.1.90; Calling setopt during init loads cus-start
 over and over
Date: Sun, 01 Jun 2025 12:40:16 +0300

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: Aaron Zeng <azeng <at> janestreet.com>,  78637 <at> debbugs.gnu.org,
>   app-emacs-dev <at> janestreet.com
> 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?

Previous Next

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