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: Aaron Zeng <azeng <at> janestreet.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 78637 <at> debbugs.gnu.org, app-emacs-dev <at> janestreet.com
Subject: bug#78637: 30.1.90; Calling setopt during init loads cus-start over and over
Date: Fri, 30 May 2025 11:27:44 -0400

On Fri, May 30, 2025 at 3:24 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
>
> I don't understand: cus-start is preloaded (see lisp/loadup.el), so
> "(require 'cus-start)" should be (almost) a no-op.  Do you have any
> evidence that cus-start.el is indeed being loaded under this recipe?
> If so, can you present that evidence?  (And no, the fact that startup
> time goes down doesn't mean that loading cus-start is the reason, it
> could be something else.)


Yes, if you add (setq force-load-messages t) to the init file I provided,
you can see that "Loading cus-start..." is messaged repeatedly, once
for each time setopt runs.  Also, you can see that "Loading cus-start...done"
never gets messaged, indicating that something failed while loading
cus-start.  I also observe that just calling (require 'cus-start) in that file
triggers an error.

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

Sorry, I skipped a few steps in reasoning here.  What I am observing from the
backtrace of the load error mentioned above, is that
custom-delayed-init-variables
is set to t when add-to-list runs (on the line following the context
from the above patch).  This is, of course, a type error.

The docstring of custom-delayed-init-variables claims that it is set
to a non-list
value when the list has already been processed---so, my reasoning was that
if it is already set to a non-list value that means there is no point
adding anything
to it.

I am happy to consider different ways of solving this issue.

Previous Next

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