Received: (at 78637) by debbugs.gnu.org; 1 Jun 2025 09:40:27 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Jun 01 05:40:26 2025 Received: from localhost ([127.0.0.1]:36578 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1uLfB4-0004fS-5l for submit <at> debbugs.gnu.org; Sun, 01 Jun 2025 05:40:26 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:57048) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1uLfB2-0004eI-1D for 78637 <at> debbugs.gnu.org; Sun, 01 Jun 2025 05:40:24 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1uLfAw-0004yz-6X; Sun, 01 Jun 2025 05:40:18 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=2lLc5+lJNlcDU5H7cVrxvxw+eOwiKClFlHXqqAFAM70=; b=lv2QCdyD9eLh LCmnFRGQhrut6NULmvxyR7HEYCrTcgM4ayKMpdPsqtbamEBLYZsz0mveaQ9/qOBPnD31GmnlavVE+ ycs2HNJHzIpJwbigoyAL0P23929d2V1nCgXA2ukY3Yhdxif7lAmBPzy9x9EVfTTBVgf82ZiFpePMi qVij23WikvCvDuq3AFcdWD+O3Mm20ZcmdwWP4xrQU+NdTORe2WW0Bv7ndvMZHZ/NUfqakk7ICabrK nHoO0okEy6Hxwo28W17zlTKOO3pVrDbClrpyUzkxwCLSkwQhgIUkRt1e0R5XB7qEutxFzJY6qVX/U iTXcnhVOLq6fHMTC0w+Tvw==; Date: Sun, 01 Jun 2025 12:40:16 +0300 Message-Id: <864iwzre9r.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Stefan Monnier <monnier@HIDDEN> In-Reply-To: <jwvr004y8a8.fsf-monnier+emacs@HIDDEN> (message from Stefan Monnier on Sat, 31 May 2025 14:04:39 -0400) Subject: Re: bug#78637: 30.1.90; Calling setopt during init loads cus-start over and over References: <q7mwm9zt9sd.fsf@HIDDEN> <86o6vatvc7.fsf@HIDDEN> <jwvr004y8a8.fsf-monnier+emacs@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 78637 Cc: 78637 <at> debbugs.gnu.org, app-emacs-dev@HIDDEN, azeng@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Stefan Monnier <monnier@HIDDEN> > Cc: Aaron Zeng <azeng@HIDDEN>, 78637 <at> debbugs.gnu.org, > app-emacs-dev@HIDDEN > 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?
bug-gnu-emacs@HIDDEN:bug#78637; Package emacs.
Full text available.
Received: (at 78637) by debbugs.gnu.org; 31 May 2025 18:05:00 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat May 31 14:04:59 2025
Received: from localhost ([127.0.0.1]:59687 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1uLQZl-00048A-77
for submit <at> debbugs.gnu.org; Sat, 31 May 2025 14:04:59 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:60789)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <monnier@HIDDEN>)
id 1uLQZg-00046M-9c
for 78637 <at> debbugs.gnu.org; Sat, 31 May 2025 14:04:54 -0400
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id B2DD280919;
Sat, 31 May 2025 14:04:46 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1748714681;
bh=ppl5atKFQ6Qepd4lLw8y69abv2LAg9qYrhvxrA3y5IQ=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=eZ6YZK1E8gjKKXlt1pJ1/0yjkRv+DXyAgSPS8RvIJJ35s19+vf5Hs9RaEol/uA60X
EXpfpZPHEcA5+e0V/qsx+MkghLk9HroF8DGRT088s1WBluJyMY1qRCVzolSYelWmeE
B6oaEqqwv/nX32VyYi+QXGKHxkQmIH8wmO0CEpVn7BLkNSownazHQS/v/OOEHL5x1+
WiBY1tbjDrufN5bBz25UZqt1GnLgSOCE+KNtKtcgLqff9CHWoUM3pPspSZI6Ba2T9W
UfF1dhh73gzfA6Gy6Pydp/2RHhUnA5Xvl0QzebYdgDYA7lRndbrFnqFD1+RI/OHhV2
K37Ojg/fxYAhQ==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 7985C80191;
Sat, 31 May 2025 14:04:41 -0400 (EDT)
Received: from alfajor (unknown [104.247.225.139])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 3EE54120230;
Sat, 31 May 2025 14:04:41 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#78637: 30.1.90; Calling setopt during init loads cus-start
over and over
In-Reply-To: <86o6vatvc7.fsf@HIDDEN>
Message-ID: <jwvr004y8a8.fsf-monnier+emacs@HIDDEN>
References: <q7mwm9zt9sd.fsf@HIDDEN> <86o6vatvc7.fsf@HIDDEN>
Date: Sat, 31 May 2025 14:04:39 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL -0.371 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 78637
Cc: 78637 <at> debbugs.gnu.org, app-emacs-dev@HIDDEN,
Aaron Zeng <azeng@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
>> 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.
I think this problem comes originally from my lack of understanding when
I added that `custom-delayed-init-variables` thingy here: if I had
understood what the `(unless purify-flag` was doing there I would have
used that test right from the start instead of `after-init-time`.
startup.el sets `custom-delayed-init-variables` to t after using it, so
as to try and catch cases where we mistakenly register vars on this list
"too late". The `after-init-time` avoided the problem only as long as
`cus-start` was loaded late enough.
Stefan
diff --git a/lisp/cus-start.el b/lisp/cus-start.el
index 09364b68e11..7e07e055015 100644
--- a/lisp/cus-start.el
+++ b/lisp/cus-start.el
@@ -946,19 +946,18 @@ minibuffer-prompt-properties--setter
(put symbol 'custom-set (cadr prop)))
;; 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
- ;; 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
- ;; early, even if this file happens to be loaded late. so add them
- ;; to the end of custom-delayed-init-variables. Otherwise,
- ;; auto-save-file-name-transforms will appear in customize-rogue.
- (add-to-list 'custom-delayed-init-variables symbol 'append)))
;; If this is NOT while dumping Emacs, set up the rest of the
;; customization info. This is the stuff that is not needed
;; until someone does M-x customize etc.
- (unless dump-mode
+ (if dump-mode
+ ;; Don't re-add to custom-delayed-init-variables post-startup.
+ ;; 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
+ ;; early, even if this file happens to be loaded late. so add
+ ;; them to the end of custom-delayed-init-variables. Otherwise,
+ ;; auto-save-file-name-transforms will appear in customize-rogue.
+ (add-to-list 'custom-delayed-init-variables symbol 'append))
;; Add it to the right group(s).
(if (listp group)
(dolist (g group)
bug-gnu-emacs@HIDDEN:bug#78637; Package emacs.
Full text available.
Received: (at 78637) by debbugs.gnu.org; 31 May 2025 17:23:58 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat May 31 13:23:57 2025
Received: from localhost ([127.0.0.1]:59479 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1uLPw2-0006SZ-2j
for submit <at> debbugs.gnu.org; Sat, 31 May 2025 13:23:57 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:45140)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1uLPvw-0006Qy-Tj
for 78637 <at> debbugs.gnu.org; Sat, 31 May 2025 13:23:51 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e])
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
id 1uLPvq-0001si-F9; Sat, 31 May 2025 13:23:42 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From:
Date; bh=CxZYNg5jHb+K5EQPjE10GJRusRih0skLO651i1Brv3U=; b=JwO0YIrdIDT69wxfhJHR
oFKuAnpivpn1AoLle4PFLldGDjS19h1Gjk7caPvpyN/mRv+8RYANQoQlivr2kj7HOI8FWxWc+zB4w
j9XcLivShg5uSkIFi9n0Fw4+cTWT404wLtqh+ec1ILtvWTCdwSe9pHnbWn4SU+CXGOfJaDsUmOrZq
4ChyfdT1Pe3qzBGA0FZMjMpMxDxVgb4+OOdMjQhcj8/8nLp97qqhhviswi+mgcb+y9yaOdyXCJhTU
7DGlyHRT5e23FuWC7kzw1EYejXtbUuOljS87lTpAZYmX4YbjryGZCUdjRkWgFShe3Stcol+qkfPad
mlROCfGVcDSQmg==;
Date: Sat, 31 May 2025 20:23:39 +0300
Message-Id: <86plfor8x0.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <jwvh61024rr.fsf-monnier+emacs@HIDDEN> (bug-gnu-emacs@HIDDEN)
Subject: Re: bug#78637: 30.1.90;
Calling setopt during init loads cus-start over and over
References: <q7mwm9zt9sd.fsf@HIDDEN>
<jwvh61024rr.fsf-monnier+emacs@HIDDEN>
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 78637
Cc: 78637 <at> debbugs.gnu.org, app-emacs-dev@HIDDEN, azeng@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
> Cc: 78637 <at> debbugs.gnu.org, app-emacs-dev@HIDDEN
> Date: Sat, 31 May 2025 11:17:04 -0400
> From: Stefan Monnier via "Bug reports for GNU Emacs,
> the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN>
>
> > While trying to improve Emacs startup time at my site, I noticed that
> > cus-start was being loaded repeatedly, each time setopt was called.
>
> I don't see this, but I do see `cus-start` being (re)loaded when the
> first `setopt` is executed.
>
> This comes from the weird conditional below:
>
> (unless dump-mode
> (provide 'cus-start))
>
> This dates back to
>
> commit 4883633e7b4416a0da1a63bc7fd0c4081bdc7837
> Author: Richard M. Stallman <rms@HIDDEN>
> Date: Sat May 31 00:54:10 1997 +0000
>
> Arrange to load it once during dumping,
> and again if needed by cus-edit.el.
> (custom-start-quote): Don't define as separate function.
> (load-path): Improve the :type.
> (delete-exited-processes): Fix group to processes-basics.
>
> I have no idea why, but it's not a new problem.
>
> Maybe the repeated-loading you're seeing is due to `dump-mode` being
> non-nil in your Emacs build? If that's the case, do you have any idea
> why that would be the case (it's rather unusual).
No dump-mode is nil at this stage.
I think I'm beginning to understand why this happens: somehow loading
cus-start signals an error, so we never get to the provide part.
E.g., if I change the init file to say this:
(setq force-load-messages t)
(require 'cus-start)
(dotimes (_ 25)
(setopt make-backup-files nil))
then starting "emacs" shows the *Warnings* buffer with this text:
Wrong type argument: listp, t
To ensure normal operation, you should investigate and remove the
cause of the error in your initialization file. Start Emacs with
the ‘--debug-init’ option to view a complete error backtrace.
I also see that wrong-type-argument error signaled if I run the recipe
under GDB with a breakpoint on Fsignal. The backtrace is below, if it
helps. It seems Emacs is trying to do the equivalent of
(member transient-mark-mode t)
But I cannot figure out which part of cus-start causes this. Any
ideas?
Here's the backtrace from the error Emacs signals and some additional
data from snooping around:
(gdb) bt
#0 Fsignal (error_symbol=85536, data=-4611686018187727616) at eval.c:1820
#1 0x00955a95 in xsignal (error_symbol=85536, data=-4611686018187727616)
at lisp.h:4845
#2 0x0095bb1a in xsignal2 (error_symbol=85536, arg1=49488, arg2=48)
at eval.c:1988
#3 0x0092e545 in wrong_type_argument (predicate=49488, value=48) at data.c:135
#4 0x00967a07 in CHECK_LIST_END (x=48, y=48) at lisp.h:3368
#5 0x0096eef5 in Fmemq (elt=138077904, list=48) at fns.c:1923
#6 0x0096ebeb in Fmember (elt=138077904, list=48) at fns.c:1905
#7 0x009d14c6 in exec_byte_code (fun=-6917529027483966176,
args_template=1026, nargs=3, args=0xa020440) at bytecode.c:1604
#8 0x009cc8d7 in Fbyte_code (bytestr=-9223372036650939888,
vector=-6917529027437457712, maxdepth=4611686018427387933)
at bytecode.c:329
#9 0x0095dff5 in eval_sub (form=-4611686018187654016) at eval.c:2604
#10 0x009afade in readevalloop (readcharfun=37056, infile0=0x628cb04,
sourcename=-9223372036650939824, printflag=false, unibyte=0, readfun=0,
start=0, end=0) at lread.c:2543
#11 0x009acdba in Fload (file=-9223372036698239704, noerror=0, nomessage=48,
nosuffix=0, must_suffix=48) at lread.c:1731
#12 0x009ad1c0 in save_match_data_load (file=-9223372036698239704, noerror=0,
nomessage=48, nosuffix=0, must_suffix=48) at lread.c:1783
#13 0x0095d0c9 in load_with_autoload_queue (file=-9223372036698239704,
noerror=0, nomessage=48, nosuffix=0, must_suffix=48) at eval.c:2382
#14 0x00977eb5 in Frequire (feature=138111896, filename=0, noerror=0)
at fns.c:3771
#15 0x009600d3 in funcall_subr (subr=0x105bc40 <Srequire>, numargs=1,
args=0xa020320) at eval.c:3165
#16 0x009cd90d in exec_byte_code (fun=-6917529027484546136, args_template=257,
nargs=1, args=0xa0202e0) at bytecode.c:812
#17 0x0096094f in funcall_lambda (fun=-6917529027438039424, nargs=2,
arg_vector=0x628d470) at eval.c:3252
#18 0x0096076a in apply_lambda (fun=-6917529027438039424,
args=-4611686018298105856, count=1280) at eval.c:3215
#19 0x0095e517 in eval_sub (form=-4611686018298105872) at eval.c:2645
#20 0x00956ba6 in Fprogn (body=0) at eval.c:439
#21 0x00959483 in Flet (args=-4611686018298106016) at eval.c:1109
#22 0x0095dbc3 in eval_sub (form=-4611686018298106032) at eval.c:2549
#23 0x00956ba6 in Fprogn (body=-4611686018298006720) at eval.c:439
#24 0x00956bf2 in prog_ignore (body=-4611686018298106080) at eval.c:450
#25 0x0095951a in Fwhile (args=-4611686018298106064) at eval.c:1130
#26 0x0095dbc3 in eval_sub (form=-4611686018298106048) at eval.c:2549
#27 0x00956ba6 in Fprogn (body=0) at eval.c:439
#28 0x00959483 in Flet (args=-4611686018298106288) at eval.c:1109
#29 0x0095dbc3 in eval_sub (form=-4611686018298106304) at eval.c:2549
#30 0x009aee16 in readevalloop_eager_expand_eval (val=-4611686018298006624,
macroexpand=44400) at lread.c:2359
#31 0x009afac4 in readevalloop (readcharfun=-6917529027437162840, infile0=0x0,
sourcename=-9223372036650853472, printflag=false, unibyte=0, readfun=0,
start=0, end=0) at lread.c:2541
#32 0x009affc2 in Feval_buffer (buffer=-6917529027437162840, printflag=0,
filename=-9223372036650853472, unibyte=0, do_allow_print=48)
at lread.c:2616
#33 0x009601c0 in funcall_subr (subr=0x105d040 <Seval_buffer>, numargs=5,
args=0xa020280) at eval.c:3169
#34 0x009cd90d in exec_byte_code (fun=-6917529027484017368, args_template=257,
nargs=1, args=0xa020288) at bytecode.c:812
#35 0x0096094f in funcall_lambda (fun=-6917529027483359632, nargs=4,
arg_vector=0x628eb88) at eval.c:3252
#36 0x0095fa15 in funcall_general (fun=-6917529027483359632, numargs=4,
args=0x628eb88) at eval.c:3044
#37 0x0095fd3e in Ffuncall (nargs=5, args=0x628eb80) at eval.c:3093
#38 0x009ac862 in Fload (file=-9223372036698322936, noerror=138689728,
nomessage=138689664, nosuffix=0, must_suffix=0) at lread.c:1619
#39 0x009601c0 in funcall_subr (subr=0x105cfc0 <Sload>, numargs=3,
args=0xa0201d8) at eval.c:3169
#40 0x009cd90d in exec_byte_code (fun=-6917529027484481064, args_template=513,
nargs=1, args=0xa020238) at bytecode.c:812
#41 0x0096094f in funcall_lambda (fun=-6917529027478952400, nargs=0,
arg_vector=0x628f5a0) at eval.c:3252
#42 0x0096076a in apply_lambda (fun=-6917529027478952400, args=0, count=128)
at eval.c:3215
#43 0x0095e517 in eval_sub (form=-4611686018263554520) at eval.c:2645
#44 0x0095d5f0 in Feval (form=-4611686018263554520, lexical=48) at eval.c:2462
#45 0x008646d7 in top_level_2 () at keyboard.c:1184
#46 0x0095aa2d in internal_condition_case (bfun=0x86464e <top_level_2>,
handlers=144, hfun=0x863c02 <cmd_error>) at eval.c:1613
#47 0x0086476a in top_level_1 (ignore=0) at keyboard.c:1196
#48 0x00959ab2 in internal_catch (tag=75552, func=0x8646f6 <top_level_1>,
arg=0) at eval.c:1292
#49 0x00864541 in command_loop () at keyboard.c:1145
#50 0x00863662 in recursive_edit_1 () at keyboard.c:754
#51 0x00863900 in Frecursive_edit () at keyboard.c:837
#52 0x0085ea23 in main (argc=1, argv=0x7bf25c0) at emacs.c:2646
Lisp Backtrace:
"add-to-list" (0xa020428)
"byte-code" (0x628c270)
"require" (0xa020320)
"custom-load-symbol" (0xa0202d8)
"setopt--set" (0x628d470)
"let" (0x628d840)
"while" (0x628da80)
"let" (0x628dd10)
"eval-buffer" (0xa020280)
"load-with-code-conversion" (0x628eb88)
"load" (0xa0201d8)
0xc2418f8 PVEC_CLOSURE
"startup--load-user-init-file" (0xa0200c8)
"command-line" (0xa020048)
"normal-top-level" (0x628f5a0)
(gdb) fr 7
#7 0x009d14c6 in exec_byte_code (fun=-6917529027483966176,
args_template=1026, nargs=3, args=0xa020440) at bytecode.c:1604
1604 TOP = Fmember (TOP, v1);
(gdb) pp TOP
transient-mark-mode
(gdb) pp v1
t
(gdb) fr 9
#9 0x0095dff5 in eval_sub (form=-4611686018187654016) at eval.c:2604
2604 val = (XSUBR (fun)->function.a3
(gdb) p form
$12 = -4611686018187654016
(gdb) xcar
$13 = 0x83ad218
(gdb) xtype
Lisp_Symbol
(gdb) xsymbol
$14 = (struct Lisp_Symbol *) 0x953f378
"byte-code"
(gdb) p form
$15 = -4611686018187654016
(gdb) xcdr
$16 = 0xc00000000e4a0c70
(gdb) xcar
$17 = 0x800000000c264a10
(gdb) xtype
Lisp_String
(gdb) xprintbytestr $17->u.s
Bytecode: Non-integral right operand for "@" operator.
bug-gnu-emacs@HIDDEN:bug#78637; Package emacs.
Full text available.
Received: (at 78637) by debbugs.gnu.org; 31 May 2025 16:38:11 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat May 31 12:38:11 2025
Received: from localhost ([127.0.0.1]:59343 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1uLPDm-0007S9-EX
for submit <at> debbugs.gnu.org; Sat, 31 May 2025 12:38:11 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:50438)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <monnier@HIDDEN>)
id 1uLPDk-0007RN-70
for 78637 <at> debbugs.gnu.org; Sat, 31 May 2025 12:38:09 -0400
Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1])
by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id B3CFC440ABC;
Sat, 31 May 2025 12:38:02 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1748709481;
bh=C7ZzuAJ9vUl/90cLs1Ek/hRZYOiSZKHbIVqkn1jqDfw=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=Qkn9dkN4RvA2VpJaOXbafB9uYtsh1ikY06kUr7N7knsebitqqFUp3uLpt0n4iSHUi
OINWYHW1DgcK4iZ6e139jDg10VA5zq57qyGX2YsvtrmxtebxCTi0uob22k6Z+CPUxd
bvRCNOqg0DLEWWaM+Bv7B1nQq1x5uNZMuuXY6gZ0BVFxmyIwG584Q9Qh2VHsWH1rNV
8QYfAfOPz8Sk5vfjDGrGrK+Rv8Y3nvERGGgW5FRc6cMJ/2R/ef8a/n+W4E4bBUSsRe
gPKzec78t+KvF7xK0DR+gfdPfqkx9evEC2xucltkxpmQRLgqZF4PXpekY7ZwqDbsdN
HRwfobHYb3hFQ==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 2778B440A9A;
Sat, 31 May 2025 12:38:01 -0400 (EDT)
Received: from alfajor (unknown [104.247.225.139])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id E84DB1204D5;
Sat, 31 May 2025 12:38:00 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Aaron Zeng <azeng@HIDDEN>
Subject: Re: bug#78637: 30.1.90; Calling setopt during init loads cus-start
over and over
In-Reply-To: <jwvh61024rr.fsf-monnier+emacs@HIDDEN>
Message-ID: <jwvsekkzqnq.fsf-monnier+emacs@HIDDEN>
References: <q7mwm9zt9sd.fsf@HIDDEN>
<jwvh61024rr.fsf-monnier+emacs@HIDDEN>
Date: Sat, 31 May 2025 12:37:54 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL -0.349 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 78637
Cc: 78637 <at> debbugs.gnu.org, app-emacs-dev@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
> This dates back to
>
> commit 4883633e7b4416a0da1a63bc7fd0c4081bdc7837
> Author: Richard M. Stallman <rms@HIDDEN>
> Date: Sat May 31 00:54:10 1997 +0000
>
> Arrange to load it once during dumping,
> and again if needed by cus-edit.el.
[...]
> I have no idea why, but it's not a new problem.
The why is a bit further up in the file:
(unless dump-mode
;; Add it to the right group(s).
(if (listp group)
(dolist (g group)
(custom-add-to-group g symbol 'custom-variable))
(custom-add-to-group group symbol 'custom-variable))
;; Set the type.
(put symbol 'custom-type type)
(while rest
(setq prop (car rest)
propval (cadr rest)
rest (nthcdr 2 rest))
(cond ((memq prop '(:standard :risky :safe :set))) ; handled above
((eq prop :tag)
(put symbol 'custom-tag propval))))))))
IOW, the dump-time load of `cus-start.el` only sets up part of the info
(to try and keep the dumped executable a bit smaller), which is why we
need to *re*load it later.
So the remaining question is why/when it may be reloaded multiple times
rather than once. I personally don't see this behavior here, so I think
we need a more detailed recipe to investigate the origin.
Stefan
bug-gnu-emacs@HIDDEN:bug#78637; Package emacs.
Full text available.
Received: (at 78637) by debbugs.gnu.org; 31 May 2025 15:17:18 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat May 31 11:17:17 2025
Received: from localhost ([127.0.0.1]:58907 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1uLNxT-00048V-P3
for submit <at> debbugs.gnu.org; Sat, 31 May 2025 11:17:17 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:19328)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <monnier@HIDDEN>)
id 1uLNxQ-00047J-Ug
for 78637 <at> debbugs.gnu.org; Sat, 31 May 2025 11:17:13 -0400
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 451A0809AB;
Sat, 31 May 2025 11:17:07 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1748704625;
bh=/FlKRs6W+v+S1fOU1snypnoFOlUs8epW157vFKSKLUg=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=DQjEwsHt8LzT5yBqC2Zj7jYiiGJHprr5ZJpDP22MHrHZ/DuKvnM7ismb3jAjID20C
EWheXSi5qLMEOvj+hOq0UQCAOUjDTahX4rssEyCsiwS7f4Lvp9EDU+mvSMWIQ+WFEv
h9eWGvjsUIKdmMRTu6daheCBejbn66Gysp2N2VLPqK3ICS5nuHvT1uQUnJs/zGRt+N
U3Q5Qcp1BN4CIPinBOyMvR3HQ+l+NvNtCu1fBr4D271aTUGu/jIeL5X/ksCclNy6nv
cTlijQYYkYOkU3rF47rgCns78RGUTDN7ihR6hGzi2FvFnCYs4NYlnLjKJQzDK3AruE
M5nflYzygK3xg==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id C03E080191;
Sat, 31 May 2025 11:17:05 -0400 (EDT)
Received: from alfajor (unknown [104.247.225.139])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 8AA5012034F;
Sat, 31 May 2025 11:17:05 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Aaron Zeng <azeng@HIDDEN>
Subject: Re: bug#78637: 30.1.90; Calling setopt during init loads cus-start
over and over
In-Reply-To: <q7mwm9zt9sd.fsf@HIDDEN>
Message-ID: <jwvh61024rr.fsf-monnier+emacs@HIDDEN>
References: <q7mwm9zt9sd.fsf@HIDDEN>
Date: Sat, 31 May 2025 11:17:04 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL -0.376 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 78637
Cc: 78637 <at> debbugs.gnu.org, app-emacs-dev@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
> While trying to improve Emacs startup time at my site, I noticed that
> cus-start was being loaded repeatedly, each time setopt was called.
I don't see this, but I do see `cus-start` being (re)loaded when the
first `setopt` is executed.
This comes from the weird conditional below:
(unless dump-mode
(provide 'cus-start))
This dates back to
commit 4883633e7b4416a0da1a63bc7fd0c4081bdc7837
Author: Richard M. Stallman <rms@HIDDEN>
Date: Sat May 31 00:54:10 1997 +0000
Arrange to load it once during dumping,
and again if needed by cus-edit.el.
(custom-start-quote): Don't define as separate function.
(load-path): Improve the :type.
(delete-exited-processes): Fix group to processes-basics.
I have no idea why, but it's not a new problem.
Maybe the repeated-loading you're seeing is due to `dump-mode` being
non-nil in your Emacs build? If that's the case, do you have any idea
why that would be the case (it's rather unusual).
Stefan
bug-gnu-emacs@HIDDEN:bug#78637; Package emacs.
Full text available.Received: (at 78637) by debbugs.gnu.org; 31 May 2025 06:21:28 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat May 31 02:21:28 2025 Received: from localhost ([127.0.0.1]:54678 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1uLFax-0005Yq-Q6 for submit <at> debbugs.gnu.org; Sat, 31 May 2025 02:21:28 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:40602) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1uLFav-0005YH-Q1 for 78637 <at> debbugs.gnu.org; Sat, 31 May 2025 02:21:26 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1uLFap-0000K9-GF; Sat, 31 May 2025 02:21:19 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=RZBk1l2B9PxBwaW1VYahJbOXY5QmOFhVRhwFlNa4Ykc=; b=Lj1ewUX6IJ66x6e8miCC 5vzwGX1RdPicoem2xPyaby8yPjcUTLov+WBoLJ0kMfhBWiKQ8osNq1S/8NY+uSTJNGuVZIx4lsy+7 O9rDKDBh0oW9FUKrYpi/RLX+U9MeNg4VFPuIXWfKiIusBKukFIOGiPfTt23XvGp0E5e8wxtNK3R1y leSEquMFRaIpoZ5ytESiIINh1e64bccEsz/r7B9zEIyjjeX9TGDDtm2xvafKJXYiSqfZajvkGEgXi Z6F0yBqX2zo6KGQTP4yD5Qm9gM+1SshAoAo/C64ZNE1wUiabdQPZ6yTk8lH2pkiJHwm61Kko+lxg7 nfl2t/G8DKCLhg==; Date: Sat, 31 May 2025 09:21:16 +0300 Message-Id: <868qmdti5f.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Aaron Zeng <azeng@HIDDEN> In-Reply-To: <CAB7SQMEBMTr+e3EnQJ93h8cFs449r9hSyonOfGkfT5EfmmyEfg@HIDDEN> (message from Aaron Zeng on Fri, 30 May 2025 13:09:12 -0400) Subject: Re: bug#78637: 30.1.90; Calling setopt during init loads cus-start over and over References: <q7mwm9zt9sd.fsf@HIDDEN> <86o6vatvc7.fsf@HIDDEN> <CAB7SQMEZddArxiUsZW4qJioCArXvFPo5fSpDLOt0VQDQx2kEcw@HIDDEN> <86cybqt6y2.fsf@HIDDEN> <CAB7SQMEBMTr+e3EnQJ93h8cFs449r9hSyonOfGkfT5EfmmyEfg@HIDDEN> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 78637 Cc: 78637 <at> debbugs.gnu.org, app-emacs-dev@HIDDEN, monnier@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Aaron Zeng <azeng@HIDDEN> > Date: Fri, 30 May 2025 13:09:12 -0400 > Cc: Stefan Monnier <monnier@HIDDEN>, 78637 <at> debbugs.gnu.org, > app-emacs-dev@HIDDEN > > On Fri, May 30, 2025 at 12:11 PM Eli Zaretskii <eliz@HIDDEN> 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?
bug-gnu-emacs@HIDDEN:bug#78637; Package emacs.
Full text available.Received: (at 78637) by debbugs.gnu.org; 30 May 2025 17:10:01 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri May 30 13:10:01 2025 Received: from localhost ([127.0.0.1]:50163 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1uL3F2-0004eK-S7 for submit <at> debbugs.gnu.org; Fri, 30 May 2025 13:10:01 -0400 Received: from mxout1.mail.janestreet.com ([38.105.200.78]:39451) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <azeng@HIDDEN>) id 1uL3Ey-0004dh-P3 for 78637 <at> debbugs.gnu.org; Fri, 30 May 2025 13:09:58 -0400 Received: from mail-lj1-f199.google.com ([209.85.208.199]) by mxgoog2.mail.janestreet.com with esmtps (TLS1.3:TLS_AES_128_GCM_SHA256:128) (Exim 4.98.2) id 1uL3Et-000000027FE-18UD for 78637 <at> debbugs.gnu.org; Fri, 30 May 2025 13:09:51 -0400 Received: by mail-lj1-f199.google.com with SMTP id 38308e7fff4ca-32a74099591so14700311fa.0 for <78637 <at> debbugs.gnu.org>; Fri, 30 May 2025 10:09:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com; s=google; t=1748624990; x=1749229790; darn=debbugs.gnu.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=h8V5GWVimrVK9oA1d98sx9PrSNPeXeUz9p/j9bsPV48=; b=b29IzD5TwplejMaDoXbKLFoE5JGVj8IlvDb87JS9LjZvvoKNkih+yTVbeoXpa1kLn9 s9vzekHqXeeY3tOt5Ewtt96Rdp6V94h+RusJbsgM3SbbCJPDg+m57+JoeamM6GA7HWCC W7MZdoc+THMqu1AqYzD0uX1+rzz0QqVzXi1pI= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com; s=waixah; t=1748624991; bh=h8V5GWVimrVK9oA1d98sx9PrSNPeXeUz9p/j9bsPV48=; h=References:In-Reply-To:From:Date:Subject:To:Cc; b=vcebawhfbb+UAQYbxGV9JAmybLr+m2CNmhdtQqeGf1C6XV1blA2zY93/1kF0n+mOm mpXGXVrttFo2xfSRSooN1C09aEk1VIeVXf2kVn0m+QZzwU80971IZrCN3Op/WCa0m2 nitOff6ej3G0/+UltaA2BpuxnPGCpYxdhgnHiQnO9svWuUL7vg3zcA6u1r9WFcDs0G We8U+yQKR5lOcMH3Byc6Q7RGpw2UC1wBJJlh00uYNyC1Oj0I+fuYirxVGrZLaU/Xu1 yL+cTKyoW5kipBmL/HlXRHAYnR2I5q7WEIDYCyS0MUNsmgILhKhZ2uW+cxOYFteNm/ AoEYl+XbjYNzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1748624990; x=1749229790; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=h8V5GWVimrVK9oA1d98sx9PrSNPeXeUz9p/j9bsPV48=; b=WdM/PdJO+076xEulZhUi52SAredcAp3Z0EpyMPvObK6MTp4TUYYmcbeuw5CZIlpg7V kluiVrK6rjRyJz2IsqNSw9LdJFwEoUTEA2benXJhcT1yd9vGr6l8VIonkMqbRKMamNm/ G5VUYYp2Ioth7jnkfwnqkr+yEp8qTQ0lTpQZWhjDxTUT3uJ8vzCZXCgKt0zd2igsWqnx MDdbQfRPK4cacJGO1ESkG9zDUicz8I6TbgMYkLUIYvdu7BOeRdUh36jaLYa8u4m1iEr3 oQBNni9pGrAMs5uYAakyL11qyQPO1JCfUxlGRcQB3yIU+Nqb4/MV/TKNLEq+kWnC3iZS +YtA== X-Forwarded-Encrypted: i=1; AJvYcCXPazN23nLixeYP1yWilhYw3E9zP3w/3UxS58BxKVRi8Q4LdCO0isR0YL1xoqIzLXXR3dMh1g==@debbugs.gnu.org X-Gm-Message-State: AOJu0Ywz35hzU7MTOXEjPFev61Rfqd/lxzEPnbTGzY0lMC+2BdgLtsnX at+ll9mtjAbEkWzXRHPhQNJDFkL44g+Ouysn4EVFOcj1uLB7JIwHbJFsGH3XrPim7cnvwPRt/V1 EupbaDPRffNWl5JYvk8N5ENo28HGCNF0fuz7nIby+K24vn7GboPjjD9rkrS2EIpFE7/Q5p9TVTX aq4VJAgnFjngABmu4NrH9U2/htdrJV X-Gm-Gg: ASbGncuvju57j2CyPWTs6P9enOcljQsmM8zr4OFq+6sXX2OVevw/PQiJ5M6d8IBAr9E gkX3Ez2Z5151nQCXCWlVO183rpGaP3rdl+HF80Q7g0RP5e/W1wocotYbxrAjUbf6pGWQ= X-Received: by 2002:a05:651c:4c9:b0:32a:6dc2:aab8 with SMTP id 38308e7fff4ca-32a8cd6d584mr16810681fa.15.1748624990167; Fri, 30 May 2025 10:09:50 -0700 (PDT) X-Google-Smtp-Source: AGHT+IH53er+b6HkbkFTKjDCXJTSm/F/SNIj+ZyKDf1i2FcfjkeFvHi5JICjEH4qOc9H2EsS4bGOT1ehQJ7Rinaz+CQ= X-Received: by 2002:a05:651c:4c9:b0:32a:6dc2:aab8 with SMTP id 38308e7fff4ca-32a8cd6d584mr16810601fa.15.1748624989741; Fri, 30 May 2025 10:09:49 -0700 (PDT) MIME-Version: 1.0 References: <q7mwm9zt9sd.fsf@HIDDEN> <86o6vatvc7.fsf@HIDDEN> <CAB7SQMEZddArxiUsZW4qJioCArXvFPo5fSpDLOt0VQDQx2kEcw@HIDDEN> <86cybqt6y2.fsf@HIDDEN> In-Reply-To: <86cybqt6y2.fsf@HIDDEN> From: Aaron Zeng <azeng@HIDDEN> Date: Fri, 30 May 2025 13:09:12 -0400 X-Gm-Features: AX0GCFsZtI84RrBEun9Z8A6HA9TrgyIf584Go837dIv7F6dBXMHOoM_kHS1VMXo Message-ID: <CAB7SQMEBMTr+e3EnQJ93h8cFs449r9hSyonOfGkfT5EfmmyEfg@HIDDEN> Subject: Re: bug#78637: 30.1.90; Calling setopt during init loads cus-start over and over To: Eli Zaretskii <eliz@HIDDEN> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 78637 Cc: 78637 <at> debbugs.gnu.org, app-emacs-dev@HIDDEN, Stefan Monnier <monnier@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) On Fri, May 30, 2025 at 12:11=E2=80=AFPM Eli Zaretskii <eliz@HIDDEN> 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 err= or, and therefore the (provide 'cus-start) line is never executed and the featu= re never gets added to the list. > 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.
bug-gnu-emacs@HIDDEN:bug#78637; Package emacs.
Full text available.
Received: (at 78637) by debbugs.gnu.org; 30 May 2025 16:11:14 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri May 30 12:11:14 2025
Received: from localhost ([127.0.0.1]:49826 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1uL2KA-0000Ra-9P
for submit <at> debbugs.gnu.org; Fri, 30 May 2025 12:11:14 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:38870)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1uL2K6-0000R0-Hg
for 78637 <at> debbugs.gnu.org; Fri, 30 May 2025 12:11:12 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e])
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
id 1uL2K0-0007Bd-Gb; Fri, 30 May 2025 12:11:04 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From:
Date; bh=VgvlxtooLEMZqXel3NZJguA1hDGPef1U8lGqkrSi7Wo=; b=rd7MNQaDxyC2kqBTHbjx
tpgU+RPqvJ7AwsgDyvvHqs25MEWap8jnmDlWYqU5BAuY1pDEM+GLuBkFfSGU/oBPTy8Ys4YiSTEAt
kRYhHUXumBvuWLXC1L9x+6g53IDNSQczLTNTaej++NufzKToumRwwGAgbHR0trUAsjpk+K0vUlL9l
RMYP72YrMhevHm0v6zOmqsyBGe0FASxv0s5rF2T0MIzYCUe6Ln8INGd3zE6zpWtj8HFf80b2isZNt
c9RgefPnqLutPIS7aYZV1QrC4RW/U/BKF2lAWUYD49lsL5xbZ8M/dxm1i8YNCAL5OGyeDx0tqoYGO
Joy8lKF5aauYPw==;
Date: Fri, 30 May 2025 19:11:01 +0300
Message-Id: <86cybqt6y2.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Aaron Zeng <azeng@HIDDEN>,
Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <CAB7SQMEZddArxiUsZW4qJioCArXvFPo5fSpDLOt0VQDQx2kEcw@HIDDEN>
(message from Aaron Zeng on Fri, 30 May 2025 11:27:44 -0400)
Subject: Re: bug#78637: 30.1.90; Calling setopt during init loads cus-start
over and over
References: <q7mwm9zt9sd.fsf@HIDDEN> <86o6vatvc7.fsf@HIDDEN>
<CAB7SQMEZddArxiUsZW4qJioCArXvFPo5fSpDLOt0VQDQx2kEcw@HIDDEN>
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 78637
Cc: 78637 <at> debbugs.gnu.org, app-emacs-dev@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
> From: Aaron Zeng <azeng@HIDDEN>
> Date: Fri, 30 May 2025 11:27:44 -0400
> Cc: 78637 <at> debbugs.gnu.org, app-emacs-dev@HIDDEN
>
> On Fri, May 30, 2025 at 3:24 AM Eli Zaretskii <eliz@HIDDEN> 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.
This is because:
. custom.el and cus-edit.el say (require 'cus-start), something they
don't need to do
. 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
Stefan, why does this happen? It sounds like when 'require' is called
from bytecode, it always loads the file? Or is this something special
for cus-start? Or something else?
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?
> > 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.
The way to solve this is to understand why 'require' insists on
loading cus-start although it's preloaded. I hope Stefan will help us
understand why this happens.
Here's the patch which reduces the number of loads to 1 (and which I
hoped will reduce it to zero):
diff --git a/lisp/cus-edit.el b/lisp/cus-edit.el
index 2ecae54..510c0b9 100644
--- a/lisp/cus-edit.el
+++ b/lisp/cus-edit.el
@@ -149,7 +149,8 @@ recentf-exclude
(error nil))
(condition-case nil
- (require 'cus-start)
+ (unless (featurep 'cus-start)
+ (require 'cus-start))
(error nil))
(put 'custom-define-hook 'custom-type 'hook)
diff --git a/lisp/custom.el b/lisp/custom.el
index a0dc194..e5ceda8 100644
--- a/lisp/custom.el
+++ b/lisp/custom.el
@@ -699,7 +699,8 @@ custom-load-symbol
(ignore-errors
(require 'cus-load))
(ignore-errors
- (require 'cus-start))
+ (unless (featurep 'cus-start)
+ (require 'cus-start)))
(dolist (load (get symbol 'custom-loads))
(cond ((symbolp load) (ignore-errors (require load)))
;; This is subsumed by the test below, but it's much faster.
bug-gnu-emacs@HIDDEN:bug#78637; Package emacs.
Full text available.Received: (at 78637) by debbugs.gnu.org; 30 May 2025 15:28:32 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri May 30 11:28:32 2025 Received: from localhost ([127.0.0.1]:49495 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1uL1ep-0005az-ME for submit <at> debbugs.gnu.org; Fri, 30 May 2025 11:28:32 -0400 Received: from mxout5.mail.janestreet.com ([64.215.233.18]:37923) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <azeng@HIDDEN>) id 1uL1em-0005aU-Ik for 78637 <at> debbugs.gnu.org; Fri, 30 May 2025 11:28:29 -0400 Received: from mail-lj1-f198.google.com ([209.85.208.198]) by mxgoog2.mail.janestreet.com with esmtps (TLS1.3:TLS_AES_128_GCM_SHA256:128) (Exim 4.98.2) id 1uL1eg-00000001wbo-34FS for 78637 <at> debbugs.gnu.org; Fri, 30 May 2025 11:28:22 -0400 Received: by mail-lj1-f198.google.com with SMTP id 38308e7fff4ca-32a6e117b55so11529971fa.1 for <78637 <at> debbugs.gnu.org>; Fri, 30 May 2025 08:28:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com; s=google; t=1748618902; x=1749223702; darn=debbugs.gnu.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=dC5odKeZmTiLXu2ke4sNz8gp5JweYld42NV11r1tFjE=; b=pU/jvUCQQ37aAB3lJuTRcfdR/+w4aB70E5X8pV6F7wsCLFv1lYIqwiz/PCYiZaEQgL N7147dowiClUHBIMjXnAEAU21vjsmUq/NhUfUYJU748i9ZEgZl4GrxdXDvXlTfaU3WxN iPQgA58EbMyNR6hrub/IxgZTYLJ8QOpV03HdY= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com; s=waixah; t=1748618902; bh=dC5odKeZmTiLXu2ke4sNz8gp5JweYld42NV11r1tFjE=; h=References:In-Reply-To:From:Date:Subject:To:Cc; b=E8MG1NrtTgr1eaIXOpctSeUmY3lDua2WVzZ13lTQ3GjhtzITD9T5Ca8vnShDb9wL6 SuOAPqYLCbhXrOiNQQ3/a3AzH/h87LsYxIZY1MBehqNn0OF5Dx0XoR+xSaEzespe8T wAfPHQm5srKw2dIfqPboNAz6bvdAv5pNagUnDzavRyD/35qSkhjNhko90jIAxeQDH0 Kzp5zBk3EW+4Byxp4o+tatDQ1JoWuwWa/qs+gzznvTMwC4dFGgigkULbaFqi7EjAJl nLRZdr+n1qw4oIQ0CEXcCcXUdfuc3JXfZHpy16lTztvLfpZ3nHOcXf9wdQnJWzGvSC tixJN8/N7apLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1748618902; x=1749223702; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=dC5odKeZmTiLXu2ke4sNz8gp5JweYld42NV11r1tFjE=; b=u9VpInxd0a0WwPN9qeKaRfpZKi3U2qU3ExOVi7fQHk9Ytz7WMPinhkDxnGrie8hRZW RtXXp4rDz7jkwMjrAAWl4Czt1xLn+Td/u73T60voRIbKFUi3UosN9AFngZF1XKxeKsjn SDKKPKtMYAqw8AWCtOzb1rQ8u8X62m/tS0Qpgn86pBbnHCaQxD3FaYAm+OrYMaMLy+Cd TQnGd+MG7u5ImQpikFIViC9ilJn42iHt0OCepNtPhyFCsHPI4vxqrUdXoXBnhyaKHbBC 3lh6yZux4chp/bk1aQDTiWNjCNHDkLux5Ir1R0LwNvbvPCvoF6YPlZJLODhAvM6yCU4d BF1A== X-Gm-Message-State: AOJu0YyTlMHmhVIr4j+VG33e/tPsTdbXnJR4C/pmvswfnglJDd+bWRBp Hj3ZckJdoWakeRh2eushIusiYQMZV+8KD5PcfxDjfYUkuP9w9i0x4qD/5SIf1KTLLX1+LJvAzhh vCiRhs+qZpkiTgDmTC2cPcDl/rDHnj0u7dWDeqLLHHcvfwKWwObrJBqQquyqTZViUwT6pZvvRWR DL5a9Bo30YE2wNHBzM02/O14umZNji X-Gm-Gg: ASbGncucj47t/Dc5H3P9DkfvOZI0JBt1O9CToP2dCg1I8ZSMmZgvr6tsRrgqYFptxfq o4ACdfxzQMB8yzNJhtpo7CCFQOkNPbbhvyPnvD3YkYnqLqCQnwOzMfqsxk7w6qZ6TuWg= X-Received: by 2002:a05:651c:4208:b0:32a:88b5:7b3e with SMTP id 38308e7fff4ca-32a90807b48mr7114261fa.41.1748618901601; Fri, 30 May 2025 08:28:21 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGvVOiwMUKXiz7SJu4SLIIf65V1Smt/7wBm1FErRfi/A/Nrlz3NSkrV0hhNvM+g/6N10oAfpZVA2mphf3C0b8w= X-Received: by 2002:a05:651c:4208:b0:32a:88b5:7b3e with SMTP id 38308e7fff4ca-32a90807b48mr7114151fa.41.1748618901158; Fri, 30 May 2025 08:28:21 -0700 (PDT) MIME-Version: 1.0 References: <q7mwm9zt9sd.fsf@HIDDEN> <86o6vatvc7.fsf@HIDDEN> In-Reply-To: <86o6vatvc7.fsf@HIDDEN> From: Aaron Zeng <azeng@HIDDEN> Date: Fri, 30 May 2025 11:27:44 -0400 X-Gm-Features: AX0GCFskHdVAJsjmtS6oHSpw5O6uxFHD1A4reyd-nGEyt6Uvsby_7OdMTTUflFw Message-ID: <CAB7SQMEZddArxiUsZW4qJioCArXvFPo5fSpDLOt0VQDQx2kEcw@HIDDEN> Subject: Re: bug#78637: 30.1.90; Calling setopt during init loads cus-start over and over To: Eli Zaretskii <eliz@HIDDEN> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 78637 Cc: 78637 <at> debbugs.gnu.org, app-emacs-dev@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) On Fri, May 30, 2025 at 3:24=E2=80=AFAM Eli Zaretskii <eliz@HIDDEN> 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...don= e" never gets messaged, indicating that something failed while loading cus-start. I also observe that just calling (require 'cus-start) in that f= ile 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 initializ= ed > > 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 t= he 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.
bug-gnu-emacs@HIDDEN:bug#78637; Package emacs.
Full text available.Received: (at 78637) by debbugs.gnu.org; 30 May 2025 07:24:21 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri May 30 03:24:21 2025 Received: from localhost ([127.0.0.1]:44835 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1uKu6H-0005Xb-1z for submit <at> debbugs.gnu.org; Fri, 30 May 2025 03:24:21 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:60492) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1uKu6E-0005X6-Sd for 78637 <at> debbugs.gnu.org; Fri, 30 May 2025 03:24:19 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1uKu67-0007yf-Vy; Fri, 30 May 2025 03:24:12 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=einO+SfPpd3q2I2An8zo0OixHxRpw+3mM2LEOK2eDG8=; b=LBtTUI37floQ mbtUH7nadHPMlL+J8rJ2hskBsxvvMGpFul05DLR9VYPFCcedL47yZJHZh5HfayVmBuByPAZEVot+7 Q2YZs21CKwssz6Nw3ShBytcWAKpE97+7fVrwW6SMxYfLd3beYy/TW+IvRTlYH7Kqx7i4FtWXQtUx8 w7Il+bDcb+d1SfiIldNej+HxU8THqL2EexIUnH3XcFARPVc1PHhYdzOGBdzyFgnrpXYlxFqF/tqoK CekM7S9q3dGhkxDgJFr+y1l19n4awPlUyFsz0oKUZlNvDXQckwB3JoayCCss5HHWOHljbu/dkKdRp B/F3B7IM9GT5znaUv8IRow==; Date: Fri, 30 May 2025 10:24:08 +0300 Message-Id: <86o6vatvc7.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Aaron Zeng <azeng@HIDDEN> In-Reply-To: <q7mwm9zt9sd.fsf@HIDDEN> (bug-gnu-emacs@HIDDEN) Subject: Re: bug#78637: 30.1.90; Calling setopt during init loads cus-start over and over References: <q7mwm9zt9sd.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 78637 Cc: 78637 <at> debbugs.gnu.org, app-emacs-dev@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > Cc: app-emacs-dev@HIDDEN > Date: Thu, 29 May 2025 16:57:22 -0400 > From: Aaron Zeng via "Bug reports for GNU Emacs, > the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN> > > While trying to improve Emacs startup time at my site, I noticed that > cus-start was being loaded repeatedly, each time setopt was called. > It seems that, when called during site-start or loading the user's > init file, setopt (which eventually calls custom-load-symbol) requires > cus-start, ignoring errors---and loading cus-start at that moment does > indeed error. > > As a result of this ignored error, cus-start is loaded from scratch > each time (require 'cus-start) is evaluated. This adds something like > 12ms of startup time to Emacs batch commands at my site, since we have > about 25 setopt calls in site-start, and each one takes an extra 500us > or so. > > I performed a quick experiment, with: > > emacs -Q --batch --init-directory=example-init --user "" > > where example-init/init.el contains just: > > (dotimes (_ 25) > (setopt make-backup-files nil)) > > Running the above command under hyperfine shows that the runtime is > about 82ms on my machine. > > Prepending this code to example-init/init.el: > > (ignore-errors > (require 'cus-start)) > (push 'cus-start features) > > drops the runtime of the command to 75ms. (I believe this experiment > might underestimate the true impact of repeatedly loading cus-start > due to caching effects.) 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.) > 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 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).
bug-gnu-emacs@HIDDEN:bug#78637; Package emacs.
Full text available.
Received: (at submit) by debbugs.gnu.org; 29 May 2025 20:57:40 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu May 29 16:57:40 2025
Received: from localhost ([127.0.0.1]:39796 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1uKkJm-0005ro-M4
for submit <at> debbugs.gnu.org; Thu, 29 May 2025 16:57:40 -0400
Received: from lists.gnu.org ([2001:470:142::17]:53298)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <azeng@HIDDEN>)
id 1uKkJh-0005qt-A4
for submit <at> debbugs.gnu.org; Thu, 29 May 2025 16:57:36 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10])
by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <azeng@HIDDEN>)
id 1uKkJb-00004q-2O
for bug-gnu-emacs@HIDDEN; Thu, 29 May 2025 16:57:27 -0400
Received: from mxout5.mail.janestreet.com ([64.215.233.18])
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <azeng@HIDDEN>)
id 1uKkJZ-0002bz-0x
for bug-gnu-emacs@HIDDEN; Thu, 29 May 2025 16:57:26 -0400
From: Aaron Zeng <azeng@HIDDEN>
To: bug-gnu-emacs@HIDDEN
Subject: 30.1.90; Calling setopt during init loads cus-start over and over
X-Debbugs-Cc:
Date: Thu, 29 May 2025 16:57:22 -0400
Message-ID: <q7mwm9zt9sd.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com;
s=waixah; t=1748552243;
bh=Z0PEmSqbmAOyJui8d1xufrninmLdRh5Ah5IifrO0A+Q=;
h=From:To:Cc:Subject:Date;
b=TpvKWP8hGlXS0oOjN2xWBf+gio9jHHNQxbWHf89JI6ww9+RTPmy1GN0vUXJvDBt4S
pA2P2W/qbXdCxp7DPSqg9BM6lAf86yhpZ7NJ6ezp7I6Gmf4WPtEPZ7CvWwcy6JVMnQ
4+yrSiwTk/QjUbjnEjHK0mRlKCdD7qNXOLaC1CemNagXjpb22i4TR9rF7Ajuk4f8nf
gSKZUZfxUqvm9LRe2YzfjO6YLarDwmtgvQQiSynZi8A9PAVvDfGIuKqIuYnUB86ux8
wlxrDK6Fd7OMQ9yw1SYDTONlCApQH2njtJL5A3rdspx1fK6nCHH/RZRxytaxFW/pgX
bCM0C631ladjQ==
Received-SPF: pass client-ip=64.215.233.18; envelope-from=azeng@HIDDEN;
helo=mxout5.mail.janestreet.com
X-Spam_score_int: -43
X-Spam_score: -4.4
X-Spam_bar: ----
X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,
DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1,
RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001,
RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001,
SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: 0.9 (/)
X-Debbugs-Envelope-To: submit
Cc: app-emacs-dev@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.1 (/)
Hello,
While trying to improve Emacs startup time at my site, I noticed that
cus-start was being loaded repeatedly, each time setopt was called.
It seems that, when called during site-start or loading the user's
init file, setopt (which eventually calls custom-load-symbol) requires
cus-start, ignoring errors---and loading cus-start at that moment does
indeed error.
As a result of this ignored error, cus-start is loaded from scratch
each time (require 'cus-start) is evaluated. This adds something like
12ms of startup time to Emacs batch commands at my site, since we have
about 25 setopt calls in site-start, and each one takes an extra 500us
or so.
I performed a quick experiment, with:
emacs -Q --batch --init-directory=example-init --user ""
where example-init/init.el contains just:
(dotimes (_ 25)
(setopt make-backup-files nil))
Running the above command under hyperfine shows that the runtime is
about 82ms on my machine.
Prepending this code to example-init/init.el:
(ignore-errors
(require 'cus-start))
(push 'cus-start features)
drops the runtime of the command to 75ms. (I believe this experiment
might underestimate the true impact of repeatedly loading cus-start
due to caching effects.)
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
In GNU Emacs 30.1.90 (build 2, x86_64-pc-linux-gnu, X toolkit, cairo
version 1.15.12, Xaw scroll bars) of 2025-05-29 built on
igm-qws-u12685a
Repository revision: 3e57c35323abe0782ba6a70adeecf99c27497e48
Repository branch: HEAD
Windowing system distributor 'The X.Org Foundation', version 11.0.12011000
System Description: Rocky Linux 8.10 (Green Obsidian)
Configured using:
'configure --config-cache --with-x-toolkit=lucid --without-gpm
--without-gconf --without-selinux --without-imagemagick --with-modules
--with-gif=no --with-cairo --with-rsvg --without-compress-install
--with-tree-sitter --with-native-compilation=aot --prefix='
Configured features:
CAIRO DBUS FREETYPE GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG LIBSYSTEMD
LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP
SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER X11 XDBE XIM
XINPUT2 XPM LUCID ZLIB
Important settings:
value of $LANG: en_US.utf8
locale-coding-system: utf-8-unix
Major mode: Lisp Interaction
Minor modes in effect:
tooltip-mode: t
global-eldoc-mode: t
eldoc-mode: t
show-paren-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
tool-bar-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
minibuffer-regexp-mode: t
line-number-mode: t
indent-tabs-mode: t
transient-mark-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
Load-path shadows:
None found.
Features:
(shadow sort mail-extr emacsbug message mailcap yank-media puny dired
dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg rfc6068
epg-config gnus-util text-property-search time-date subr-x mm-decode
mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader
cl-loaddefs cl-lib sendmail rfc2047 rfc2045 ietf-drums mm-util
mail-prsvr mail-utils rmc iso-transl tooltip cconv eldoc paren electric
uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel
term/x-win x-win term/common-win x-dnd touch-screen tool-bar dnd fontset
image regexp-opt fringe tabulated-list replace newcomment text-mode
lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow isearch
easymenu timer select scroll-bar mouse jit-lock font-lock syntax
font-core term/tty-colors frame minibuffer nadvice seq simple cl-generic
indonesian philippine cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
composite emoji-zwj charscript charprop case-table epa-hook
jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs
theme-loaddefs faces cus-face macroexp files window text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget keymap
hashtable-print-readable backquote threads dbusbind inotify
dynamic-setting system-font-setting font-render-setting cairo x-toolkit
xinput2 x multi-tty move-toolbar make-network-process native-compile
emacs)
Memory information:
((conses 16 50339 9279) (symbols 48 5372 0) (strings 32 15703 2215)
(string-bytes 1 493685) (vectors 16 9036)
(vector-slots 8 126107 9764) (floats 8 24 2) (intervals 56 274 0)
(buffers 992 10))
Aaron Zeng <azeng@HIDDEN>:bug-gnu-emacs@HIDDEN.
Full text available.bug-gnu-emacs@HIDDEN:bug#78637; Package emacs.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.