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

From: Eli Zaretskii <[email-masked]>
Date: Sat, 31 May 2025 09:21:16 +0300

> From: Aaron Zeng <[email-masked]>
> Date: Fri, 30 May 2025 13:09:12 -0400
> Cc: Stefan Monnier <[email-masked]>, [email-masked], 
>  	[email-masked]
> 
> On Fri, May 30, 2025 at 12:11 PM Eli Zaretskii <[email-masked]> wrote:
> >   . for some reason, 'require' doesn't avoid loading cus-start even if
> >     it is already loaded; the simple patch below reduces the number of
> >     loads of cus-start to just 1 in this scenario
> 
> Maybe I am misunderstanding, but I think this is deliberate.  cus-start.el
> does not provide the 'cus-start' feature when Emacs is dumping.
> 
> > Further, that single load of cus-start that is left is also strange:
> > it comes from cus-load, and stepping with a debugger into Frequire, I
> > see that cus-start is not in the Vfeatures list?  Why?
> 
> If I understand correctly, this is because loading cus-start signals an error,
> and therefore the (provide 'cus-start) line is never executed and the feature
> never gets added to the list.

That might explain the single load that is still left after the patch
I sent, but it cannot explain the rest, because cus-start does provide
its feature after dumping.

> > Here's the patch which reduces the number of loads to 1 (and which I
> > hoped will reduce it to zero):
> 
> I don't think this patch worked on my machine.  I still see that
> cus-start is loaded
> once each time setopt runs, when setting force-load-messages to t.

Doesn't happen here.  I see only one "Loading cus-start" message in
*Messages*, not 20+ I saw before.  Maybe you haven't fully re-built
Emacs after patching it?