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>
> Date: Fri, 30 May 2025 13:09:12 -0400
> Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, 78637 <at> debbugs.gnu.org,
> app-emacs-dev <at> janestreet.com
>
> On Fri, May 30, 2025 at 12:11 PM Eli Zaretskii <eliz <at> gnu.org> 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?
This bug report was last modified 13 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.