From unknown Fri Aug 15 21:27:20 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78637: 30.1.90; Calling setopt during init loads cus-start over and over Resent-From: Aaron Zeng Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 29 May 2025 20:58:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 78637 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 78637@debbugs.gnu.org Cc: app-emacs-dev@janestreet.com X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.174855226022571 (code B ref -1); Thu, 29 May 2025 20:58:02 +0000 Received: (at submit) by debbugs.gnu.org; 29 May 2025 20:57:40 +0000 Received: from localhost ([127.0.0.1]:39796 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uKkJm-0005ro-M4 for submit@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 ) id 1uKkJh-0005qt-A4 for submit@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 ) id 1uKkJb-00004q-2O for bug-gnu-emacs@gnu.org; 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 ) id 1uKkJZ-0002bz-0x for bug-gnu-emacs@gnu.org; Thu, 29 May 2025 16:57:26 -0400 From: Aaron Zeng Date: Thu, 29 May 2025 16:57:22 -0400 Message-ID: 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@janestreet.com; 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-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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)) From unknown Fri Aug 15 21:27:20 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78637: 30.1.90; Calling setopt during init loads cus-start over and over Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 30 May 2025 07:25:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78637 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Aaron Zeng Cc: 78637@debbugs.gnu.org, app-emacs-dev@janestreet.com Received: via spool by 78637-submit@debbugs.gnu.org id=B78637.174858986121308 (code B ref 78637); Fri, 30 May 2025 07:25:02 +0000 Received: (at 78637) by debbugs.gnu.org; 30 May 2025 07:24:21 +0000 Received: from localhost ([127.0.0.1]:44835 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uKu6H-0005Xb-1z for submit@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 ) id 1uKu6E-0005X6-Sd for 78637@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 ) 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@gnu.org> From: Eli Zaretskii In-Reply-To: (bug-gnu-emacs@gnu.org) References: X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: app-emacs-dev@janestreet.com > 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" > > 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). From unknown Fri Aug 15 21:27:20 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78637: 30.1.90; Calling setopt during init loads cus-start over and over Resent-From: Aaron Zeng Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 30 May 2025 15:29:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78637 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 78637@debbugs.gnu.org, app-emacs-dev@janestreet.com Received: via spool by 78637-submit@debbugs.gnu.org id=B78637.174861891221518 (code B ref 78637); Fri, 30 May 2025 15:29:01 +0000 Received: (at 78637) by debbugs.gnu.org; 30 May 2025 15:28:32 +0000 Received: from localhost ([127.0.0.1]:49495 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uL1ep-0005az-ME for submit@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 ) id 1uL1em-0005aU-Ik for 78637@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@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@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: <86o6vatvc7.fsf@gnu.org> In-Reply-To: <86o6vatvc7.fsf@gnu.org> From: Aaron Zeng Date: Fri, 30 May 2025 11:27:44 -0400 X-Gm-Features: AX0GCFskHdVAJsjmtS6oHSpw5O6uxFHD1A4reyd-nGEyt6Uvsby_7OdMTTUflFw Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) On Fri, May 30, 2025 at 3:24=E2=80=AFAM Eli Zaretskii 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. From unknown Fri Aug 15 21:27:20 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78637: 30.1.90; Calling setopt during init loads cus-start over and over Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 30 May 2025 16:12:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78637 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Aaron Zeng , Stefan Monnier Cc: 78637@debbugs.gnu.org, app-emacs-dev@janestreet.com Received: via spool by 78637-submit@debbugs.gnu.org id=B78637.17486214741718 (code B ref 78637); Fri, 30 May 2025 16:12:02 +0000 Received: (at 78637) by debbugs.gnu.org; 30 May 2025 16:11:14 +0000 Received: from localhost ([127.0.0.1]:49826 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uL2KA-0000Ra-9P for submit@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 ) id 1uL2K6-0000R0-Hg for 78637@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 ) 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@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Aaron Zeng on Fri, 30 May 2025 11:27:44 -0400) References: <86o6vatvc7.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Aaron Zeng > Date: Fri, 30 May 2025 11:27:44 -0400 > Cc: 78637@debbugs.gnu.org, app-emacs-dev@janestreet.com > > On Fri, May 30, 2025 at 3:24 AM Eli Zaretskii 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. From unknown Fri Aug 15 21:27:20 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78637: 30.1.90; Calling setopt during init loads cus-start over and over Resent-From: Aaron Zeng Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 30 May 2025 17:10:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78637 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 78637@debbugs.gnu.org, app-emacs-dev@janestreet.com, Stefan Monnier Received: via spool by 78637-submit@debbugs.gnu.org id=B78637.174862500117880 (code B ref 78637); Fri, 30 May 2025 17:10:02 +0000 Received: (at 78637) by debbugs.gnu.org; 30 May 2025 17:10:01 +0000 Received: from localhost ([127.0.0.1]:50163 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uL3F2-0004eK-S7 for submit@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 ) id 1uL3Ey-0004dh-P3 for 78637@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@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@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: <86o6vatvc7.fsf@gnu.org> <86cybqt6y2.fsf@gnu.org> In-Reply-To: <86cybqt6y2.fsf@gnu.org> From: Aaron Zeng Date: Fri, 30 May 2025 13:09:12 -0400 X-Gm-Features: AX0GCFsZtI84RrBEun9Z8A6HA9TrgyIf584Go837dIv7F6dBXMHOoM_kHS1VMXo Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) On Fri, May 30, 2025 at 12:11=E2=80=AFPM Eli Zaretskii 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. From unknown Fri Aug 15 21:27:20 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78637: 30.1.90; Calling setopt during init loads cus-start over and over Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 31 May 2025 06:22:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78637 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Aaron Zeng Cc: 78637@debbugs.gnu.org, app-emacs-dev@janestreet.com, monnier@iro.umontreal.ca Received: via spool by 78637-submit@debbugs.gnu.org id=B78637.174867248821385 (code B ref 78637); Sat, 31 May 2025 06:22:01 +0000 Received: (at 78637) by debbugs.gnu.org; 31 May 2025 06:21:28 +0000 Received: from localhost ([127.0.0.1]:54678 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uLFax-0005Yq-Q6 for submit@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 ) id 1uLFav-0005YH-Q1 for 78637@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 ) 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@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Aaron Zeng on Fri, 30 May 2025 13:09:12 -0400) References: <86o6vatvc7.fsf@gnu.org> <86cybqt6y2.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Aaron Zeng > Date: Fri, 30 May 2025 13:09:12 -0400 > Cc: Stefan Monnier , 78637@debbugs.gnu.org, > app-emacs-dev@janestreet.com > > On Fri, May 30, 2025 at 12:11 PM Eli Zaretskii 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? From unknown Fri Aug 15 21:27:20 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78637: 30.1.90; Calling setopt during init loads cus-start over and over Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 31 May 2025 15:18:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78637 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Aaron Zeng Cc: 78637@debbugs.gnu.org, app-emacs-dev@janestreet.com Received: via spool by 78637-submit@debbugs.gnu.org id=B78637.174870463815930 (code B ref 78637); Sat, 31 May 2025 15:18:01 +0000 Received: (at 78637) by debbugs.gnu.org; 31 May 2025 15:17:18 +0000 Received: from localhost ([127.0.0.1]:58907 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uLNxT-00048V-P3 for submit@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 ) id 1uLNxQ-00047J-Ug for 78637@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 In-Reply-To: Message-ID: References: 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-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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 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 From unknown Fri Aug 15 21:27:20 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78637: 30.1.90; Calling setopt during init loads cus-start over and over Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 31 May 2025 16:39:05 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78637 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Aaron Zeng Cc: 78637@debbugs.gnu.org, app-emacs-dev@janestreet.com Received: via spool by 78637-submit@debbugs.gnu.org id=B78637.174870949128662 (code B ref 78637); Sat, 31 May 2025 16:39:05 +0000 Received: (at 78637) by debbugs.gnu.org; 31 May 2025 16:38:11 +0000 Received: from localhost ([127.0.0.1]:59343 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uLPDm-0007S9-EX for submit@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 ) id 1uLPDk-0007RN-70 for 78637@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 In-Reply-To: Message-ID: References: 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-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > This dates back to > > commit 4883633e7b4416a0da1a63bc7fd0c4081bdc7837 > Author: Richard M. Stallman > 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 From unknown Fri Aug 15 21:27:20 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78637: 30.1.90; Calling setopt during init loads cus-start over and over Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 31 May 2025 17:24:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78637 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: 78637@debbugs.gnu.org, app-emacs-dev@janestreet.com, azeng@janestreet.com Received: via spool by 78637-submit@debbugs.gnu.org id=B78637.174871223824874 (code B ref 78637); Sat, 31 May 2025 17:24:03 +0000 Received: (at 78637) by debbugs.gnu.org; 31 May 2025 17:23:58 +0000 Received: from localhost ([127.0.0.1]:59479 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uLPw2-0006SZ-2j for submit@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 ) id 1uLPvw-0006Qy-Tj for 78637@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 ) 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@gnu.org> From: Eli Zaretskii In-Reply-To: (bug-gnu-emacs@gnu.org) References: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: 78637@debbugs.gnu.org, app-emacs-dev@janestreet.com > 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" > > > 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 > 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 , 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 , 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 , 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 , handlers=144, hfun=0x863c02 ) 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 , 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. From unknown Fri Aug 15 21:27:20 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78637: 30.1.90; Calling setopt during init loads cus-start over and over Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 31 May 2025 18:05:04 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78637 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 78637@debbugs.gnu.org, app-emacs-dev@janestreet.com, Aaron Zeng Received: via spool by 78637-submit@debbugs.gnu.org id=B78637.174871470015905 (code B ref 78637); Sat, 31 May 2025 18:05:04 +0000 Received: (at 78637) by debbugs.gnu.org; 31 May 2025 18:05:00 +0000 Received: from localhost ([127.0.0.1]:59687 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uLQZl-00048A-77 for submit@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 ) id 1uLQZg-00046M-9c for 78637@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 In-Reply-To: <86o6vatvc7.fsf@gnu.org> Message-ID: References: <86o6vatvc7.fsf@gnu.org> 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-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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) From unknown Fri Aug 15 21:27:20 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78637: 30.1.90; Calling setopt during init loads cus-start over and over Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 01 Jun 2025 09:41:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78637 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: 78637@debbugs.gnu.org, app-emacs-dev@janestreet.com, azeng@janestreet.com Received: via spool by 78637-submit@debbugs.gnu.org id=B78637.174877082717955 (code B ref 78637); Sun, 01 Jun 2025 09:41:02 +0000 Received: (at 78637) by debbugs.gnu.org; 1 Jun 2025 09:40:27 +0000 Received: from localhost ([127.0.0.1]:36578 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uLfB4-0004fS-5l for submit@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 ) id 1uLfB2-0004eI-1D for 78637@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 ) 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@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Stefan Monnier on Sat, 31 May 2025 14:04:39 -0400) References: <86o6vatvc7.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Stefan Monnier > Cc: Aaron Zeng , 78637@debbugs.gnu.org, > app-emacs-dev@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? From unknown Fri Aug 15 21:27:20 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78637: 30.1.90; Calling setopt during init loads cus-start over and over Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 01 Jun 2025 16:32:05 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78637 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 78637@debbugs.gnu.org, app-emacs-dev@janestreet.com, azeng@janestreet.com Received: via spool by 78637-submit@debbugs.gnu.org id=B78637.174879546617603 (code B ref 78637); Sun, 01 Jun 2025 16:32:05 +0000 Received: (at 78637) by debbugs.gnu.org; 1 Jun 2025 16:31:06 +0000 Received: from localhost ([127.0.0.1]:40989 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uLlaU-0004Zo-78 for submit@debbugs.gnu.org; Sun, 01 Jun 2025 12:31:06 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:47096) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uLlaR-0004YQ-Kb for 78637@debbugs.gnu.org; Sun, 01 Jun 2025 12:31:04 -0400 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 7D102441034; Sun, 1 Jun 2025 12:30:57 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1748795456; bh=d+I0GA31AVqjMCWssVNh7G8TUQ5BSHvLQZJ306IrgHk=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=Q2laJqhojrDNTbPUGQd1RJpWDJl9fH7mlg8S0IbKj71bEFbN6+hkWrUMCGGiiRTR5 AbSw9Q2piXfNdnMCEWa/TUWO4bRVpAsnMPYlYJjlC2CqFB+xTamRiT0PXPGt27qH3c xiD8yGLwgsuupKzDKGHLhmT8HLkIk4N6TekrCzEpet0A4ObR5QKaKK2g8vYPJ+uL5M 8i/xxtansHPhzyWJber/lhGaJ8PfZklpVealotgVbl4t37jG8BCbqu3muqldmqj2Oz VfU0hCs5Ve/iEw46U5ANMG45pMY7QYNgykvXOBTzrVWUevaqsrhh2iFRA7vHKRNwHm livitOLm5XBHA== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 7CC534404F2; Sun, 1 Jun 2025 12:30:56 -0400 (EDT) Received: from alfajor (unknown [104.247.225.139]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 33CA01201DA; Sun, 1 Jun 2025 12:30:56 -0400 (EDT) From: Stefan Monnier In-Reply-To: <864iwzre9r.fsf@gnu.org> Message-ID: References: <86o6vatvc7.fsf@gnu.org> <864iwzre9r.fsf@gnu.org> Date: Sun, 01 Jun 2025 12:30: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-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > 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? Yes. > If so, could you explain why do we signal an error in that case? We don't do it on purpose, of course, but the code protected by the `(unless after-init-time` test presumes that `custom-delayed-init-variables` contains a list whereas this assumption is true only while dumping and at the very beginning of the startup sequence. So the code work fine if run: - during dump or very early startup, when `custom-delayed-init-variables` still contains a list. - after loading the init file, thanks to the `(unless after-init-time` test. But not between those two (i.e. not from within the init file). The effect of that code is to fill `custom-delayed-init-variables` during the dump for subsequent use in the very early startup, hence my patch replaces the `(unless after-init-time` by `(if dump-mode. Stefan From unknown Fri Aug 15 21:27:20 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78637: 30.1.90; Calling setopt during init loads cus-start over and over Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 07 Jun 2025 09:26:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78637 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: 78637@debbugs.gnu.org, app-emacs-dev@janestreet.com, azeng@janestreet.com Received: via spool by 78637-submit@debbugs.gnu.org id=B78637.17492883469443 (code B ref 78637); Sat, 07 Jun 2025 09:26:01 +0000 Received: (at 78637) by debbugs.gnu.org; 7 Jun 2025 09:25:46 +0000 Received: from localhost ([127.0.0.1]:46932 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uNpoA-0002SE-Bx for submit@debbugs.gnu.org; Sat, 07 Jun 2025 05:25:46 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:39474) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uNpo7-0002Rz-PG for 78637@debbugs.gnu.org; Sat, 07 Jun 2025 05:25:44 -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 ) id 1uNpo2-0001Te-23; Sat, 07 Jun 2025 05:25:38 -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=4ejtuUxh9Uo/hHEsO5LLL6/dyZOBYmZ/SmesgROm5e0=; b=jLFDeS+uPJ8z V271ziQ9e2We2gi2mPf9KzCA3LYukvnLpvOK1Ddrye8tMoeHIdcKa+KR+lFkDQRH26OUqX1Y9uA20 LGjHOy+HtB3Hqg7b1ImCwA2Slhl0YW9oxEi/4mRs/oT9OYt6bNj3tkeIKS3R3OxTqNxxesMOhTxZc rOXhGlOFE4kc7HCQlBs806/1uJ4kUpMMTXQtnk01d2fnnhw0i35QvHefSLwzo+hzvCzILGZy6PGMU 5QRIYnPrfSQk6qEGseU5ZP+jpmI7J+B2CL0myps1YdWqZLzcAXuUcWpJEKmMnd+UTelX5rq6JEDR2 6bP8eOqU9EZrI0xiWOh3gw==; Date: Sat, 07 Jun 2025 12:25:36 +0300 Message-Id: <86ecvvj433.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Stefan Monnier on Sun, 01 Jun 2025 12:30:54 -0400) References: <86o6vatvc7.fsf@gnu.org> <864iwzre9r.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Stefan Monnier > Cc: azeng@janestreet.com, 78637@debbugs.gnu.org, app-emacs-dev@janestreet.com > Date: Sun, 01 Jun 2025 12:30:54 -0400 > > > 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? > > Yes. > > > If so, could you explain why do we signal an error in that case? > > We don't do it on purpose, of course, but the code protected by the > `(unless after-init-time` test presumes that > `custom-delayed-init-variables` contains a list whereas this assumption > is true only while dumping and at the very beginning of the > startup sequence. > > So the code work fine if run: > > - during dump or very early startup, when > `custom-delayed-init-variables` still contains a list. > - after loading the init file, thanks to the `(unless after-init-time` test. > > But not between those two (i.e. not from within the init file). > The effect of that code is to fill `custom-delayed-init-variables` > during the dump for subsequent use in the very early startup, hence my > patch replaces the `(unless after-init-time` by `(if dump-mode. Thanks, feel free to install your changes and close the bug. From unknown Fri Aug 15 21:27:20 2025 MIME-Version: 1.0 X-Mailer: MIME-tools 5.505 (Entity 5.505) X-Loop: help-debbugs@gnu.org From: help-debbugs@gnu.org (GNU bug Tracking System) To: Aaron Zeng Subject: bug#78637: closed (Re: bug#78637: 30.1.90; Calling setopt during init loads cus-start over and over) Message-ID: References: X-Gnu-PR-Message: they-closed 78637 X-Gnu-PR-Package: emacs Reply-To: 78637@debbugs.gnu.org Date: Tue, 24 Jun 2025 22:28:07 +0000 Content-Type: multipart/mixed; boundary="----------=_1750804087-17985-1" This is a multi-part message in MIME format... ------------=_1750804087-17985-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Your bug report #78637: 30.1.90; Calling setopt during init loads cus-start over and over which was filed against the emacs package, has been closed. The explanation is attached below, along with your original report. If you require more details, please reply to 78637@debbugs.gnu.org. --=20 78637: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D78637 GNU Bug Tracking System Contact help-debbugs@gnu.org with problems ------------=_1750804087-17985-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at 78637-done) by debbugs.gnu.org; 24 Jun 2025 22:27:37 +0000 Received: from localhost ([127.0.0.1]:51965 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uUC76-0004cv-96 for submit@debbugs.gnu.org; Tue, 24 Jun 2025 18:27:36 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:4153) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uUC73-0004bn-6s for 78637-done@debbugs.gnu.org; Tue, 24 Jun 2025 18:27:34 -0400 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id B24FF1000BC; Tue, 24 Jun 2025 18:27:27 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1750804042; bh=HD4wbvOvwABk+heE9PrFDocuiy2RjWi+n+Hfi7VYp0I=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=LPJnIDmG0oTmKABc4BOmnzVklT99GFBXOaHVkjBLTzE8dk5OoGXb3qkoks+HJ4tbG 84KO1HwVxe7I2Gpfen2FCxTfthH6lKoVuuKmXyCB5/6dtlUaMhk0j92fsfyByo73bQ w/RkGtoq55gMQ3TrD97xPzoEWyVhinmUJ+TL3lhc5421Jf2ueNo5NWk0YwNM0B/77Z ePlruenvkmIixEVBheP4AvLLVwWP0HnkguZF8BhivKxgXYFOyWinykZaWvlBvLPwpK SZ81fW0PC0D8mK3p7hKzgXOYHUo2Gh6DwT7TV3j7jBGe9P/0oH+5ISwul+oKKJSr2L 4D2VSH0nApM0g== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id C7CA6100029; Tue, 24 Jun 2025 18:27:22 -0400 (EDT) Received: from pastel (unknown [104.247.225.139]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 95CC2120223; Tue, 24 Jun 2025 18:27:22 -0400 (EDT) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#78637: 30.1.90; Calling setopt during init loads cus-start over and over In-Reply-To: <86ecvvj433.fsf@gnu.org> Message-ID: References: <86o6vatvc7.fsf@gnu.org> <864iwzre9r.fsf@gnu.org> <86ecvvj433.fsf@gnu.org> Date: Tue, 24 Jun 2025 18:27:20 -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.312 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-done Cc: 78637-done@debbugs.gnu.org, app-emacs-dev@janestreet.com, azeng@janestreet.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Thanks, feel free to install your changes and close the bug. Pushed, closing, Stefan ------------=_1750804087-17985-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at submit) by debbugs.gnu.org; 29 May 2025 20:57:40 +0000 Received: from localhost ([127.0.0.1]:39796 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uKkJm-0005ro-M4 for submit@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 ) id 1uKkJh-0005qt-A4 for submit@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 ) id 1uKkJb-00004q-2O for bug-gnu-emacs@gnu.org; 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 ) id 1uKkJZ-0002bz-0x for bug-gnu-emacs@gnu.org; Thu, 29 May 2025 16:57:26 -0400 From: Aaron Zeng To: bug-gnu-emacs@gnu.org 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: 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@janestreet.com; 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@janestreet.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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)) ------------=_1750804087-17985-1-- From unknown Fri Aug 15 21:27:20 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78637: 30.1.90; Calling setopt during init loads cus-start over and over Resent-From: Po Lu Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 25 Jun 2025 16:09:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78637 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 78637@debbugs.gnu.org, app-emacs-dev@janestreet.com, Stefan Monnier , azeng@janestreet.com Received: via spool by 78637-submit@debbugs.gnu.org id=B78637.17508677017773 (code B ref 78637); Wed, 25 Jun 2025 16:09:02 +0000 Received: (at 78637) by debbugs.gnu.org; 25 Jun 2025 16:08:21 +0000 Received: from localhost ([127.0.0.1]:37188 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uUSfa-000215-Lv for submit@debbugs.gnu.org; Wed, 25 Jun 2025 12:08:20 -0400 Received: from sonic308-9.consmr.mail.ne1.yahoo.com ([66.163.187.32]:34979) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1uUSfW-000208-G7 for 78637@debbugs.gnu.org; Wed, 25 Jun 2025 12:08:15 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1750867688; bh=JVzyuIQfp5KGhhi866/mu/K5tLuUOj2mqgFh4qWv5YI=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From:Subject:Reply-To; b=JkO5lYnTTMxLqcxslcNmwoSqxF3q8PvJIBmpe7eXW0hDsnhE/mxrKO1hN4k9ZJkrmtZkDW4LMl/a8HL64k5xlwcavpOydNGGcf40yKzW4QQo/1slcuKpBUWRJoHN/hvqrOcQEmWRl5mEboRklqTO5hlnpSquRuHeEcNSYKiI69PZeuC8WZxspEJbiC/73ruWWu1IorPwYE8Y74BS11QblQ7NsEvxwRC9kIcbDAaZFargfeusReRQEutyRc4Knc3vVZSdnufppFjLqFfcSDAIVgoUbuPWVcNF/Igv3NwSj5rHZgif9DIoNH/yoEFA0kiBBQdWnjIBcSyUy5pR/oH8Cg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1750867688; bh=4R10bPQubEDAPBAZ8Zzd8+y8C6jespNEDR4lkUcMHj6=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=d9P5hqLNdJYWY629ZTrpgTtGUnrGxKVSUF2yD64ktMe2Ss9lhKASXcLf2MlzxDAQk/eDYSCJ4ojNAaNWANVOjyTd8eBbKJl+0osXkY1yzOR1Bh9GPthbHoEjqF1bs+LElxJTjKPqRQwXsx7mhAVoDHjbroGJ6it14F2ymtQPrrXq7KyVXdx40+UALJBB/AQ4WpbGo0bwQIroLRmkkJboxGKqUph0ffSGc35dNhIO/ypArWFSSdQTH8pWP73tDw3zfNSa53yd7g8BGwPhRnjmreLMr98V2GkkUoah6D97KMWodDM8E4RaKP9eGIp9v8P8XjfCjeJD/Gzai0GUX4VEhg== X-YMail-OSG: 6mHeEvcVM1nzVMgoChQGW9QjXuZxLpNqp4UyJz.hKTwM8.3gJDCjhWrlIaszoaT E1.Qx5JgUWvf_5CHluHIhJRJy4i5Es_pE3yAwWg3VRwc5lm9rMkhV7XoO9fkuafGdgdO76kD1OGP 7koUDIGFmcjLnJfzku.oQr_7s_noD7ZdK8T3RlsgGw_CgtnvEiRmpsWA_7O_tOOSZ7LG_F2s5afJ F8rVU1fgJq3Rg7.OtuRrxxAB6exI.ikKdV6GZF4m.Trla8lu4Jwj_R7I9RZIeDvMIuQ_3rbWzwOm J2skJpNPujo16bBizJX8RTyWPa2NpZoZ3SVQwFT8HEWjaXhiMGdLhRMu3eSnJfabVfXhK6h0ZA3d 2zhoS1sIlozi5wWF2DBMoENoWMbXCy1ohEW7F05lh4viwq9Oc05NkE44TxM_YTnM4nLs48RFHK43 y3TiDrjjRL6CXQQs5_GetO9kZcaCfC5zJTnecTyu7i8ilRsq2deVs1uTNez05Ct96EewAGCExMAm kJAxniwO7xrj8LaLW6FVbFjkNT1D5wW8MX5uQ4YVpkcQc7d0zodA.B9lVhI2VV4o49GDuNdXuGZ5 AqeMyBMx4ErX2HZ0cYwgIqxWZPQgZecxe2C5NheBjoAEL3awjFjE01GNJX_3Sc6tkazylMfqQbyr Ivm577a394fTVYp5rZ1MvpY1RbQ5y6Xk.KjH66fT0uUvCJj7AAr7uGSUjgUSKUVHY3bLPPiAzGkv 4du40KX47XwtTiD2OMeg1bcS1LrfKxuAKHABVZKaWEhb9lwjzc0jjBLbYOsZBt25UZ10OXXtoZOZ ghCkqg9lWGqcq6kWorm_ZM2GSg_xMzF4VXsP59vmg0y5cShKlTJt4MKfBlvbYrjNaHlxc6Hm4Iex 1y3NAxhqjlZJt.u0t96UWhxo_MTsCowqg9az35S7k07lm2Pi8ue_PKvEX8A7VdIDOtMhEAHSMVtR NrhFLVhu7AAAhChPRaECB0U.dWvSLz8mAyWLYpSuw_w5Z0MFhqrPFU9LlnUOaDsxYL.49R0zquPI 2l4oAlbmMvAOwJVBOHL9cfptQAoK9NBdPkHI.bt.UWFWgipQzz_iRoAHPDFHQ1MYJMrzn7szhyR2 YHnAxFeGNzvfIpW9zElH2cuB1WrhFKfaNdLZxWA2f2hGEuiVTNbVriqvxSuWj.fdFecLu7t5szVX icMtNGNAN1vys6fplJsOpLu9dVqM3o4gb39br78VVgK6UNLTkK8quxPuzA.1kfCaWq2hu.k.yunn KkNehhbaHUpao4nM1caoA6zGocqrH6jXtJVkMNVzcK6lqH7Qubs4WJpOvUs0XKWHLOrzWGemQu77 T3gn.mPmXbQKFLlcjFJcSYRWttyMzvdsXvLcu.FbtXOTjAkQxcZUXd4lmGgeU3k__OD.P_aXuZ7I wXu.5H2jhEdbSO4.DFMt6_9Mqt4xXBcAO12wHxzqAuk_MIjM6Uk0ze52NZJbPL6UiR8JxVwDj.WN hfQRhtfOsJ2AYd5rGkB4Bo8rRSdqgc6OFxBPGk0aJoBTAxobimCphgXcXlZYF_PhZVhY6j2BfHKd 8XjjOFcOOCTgoMsJmRuk1VWFsBt1qPVG_UYjwMAHjB6ApTA.keoh_zkqKJFd13WNluj7iRxKR43e DGNiGPYOgJakyUck9zKJ.TKQLoVyDmcgaDUYH9vr1Af81xGae.4B56i9oay4lwfJ7wExUBXqF2of 2AtFunS37CBu0Yx8qh3LlVEfo7ZXkQPhDyKPnAb3e6KjP7TvTt3wMdTeoLPKqfpF1bn0PYZ3JLnl zTkhtyn1EW7Zonh46vMCoyuDcIDQIyH1RSFz9KyxKijUqWRN8f4GIUZ1FODhojtaIoov6GYneFlk 2PxI.BOsSJASMZ1R1_fHWwkfeQoQx5xIZeB.LYnIEIygOFh1EFbwyq_OXhTEGhRsTlXb0zBkQigs zrD8uu16S0GCEmiNkmiEQ3z4f04qQEpQ4njBasj58r7.nP_OfzU7GGvsfsnRCHXIOuVLz75m2og4 EJK9fHTFB7.E5xUGJHpWshrUHvAOYlB7Lv3VTuo8w1EiUa._xffsljWiv_C7tFZRBvjvWJOWcgmT IS8mxRupHJhr02k4.WAPR_sKot0iYzvkof.z3jAyn6iLWaaKvNTkwldH2aUpNywFJDbmM5lA1321 la_v537qIyQKOIQkOpNTW6QK4jPrKOzTMUhN8H4yZzRmvCSH5W.AnPnwkS66EyJSoyqxMjmbWMZZ xFsAToPkzb6.2gAVEmFzowwBWyC3qkau45X1HFQ-- X-Sonic-MF: X-Sonic-ID: 66665997-726c-4f5f-9224-c6f08367f90b Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.ne1.yahoo.com with HTTP; Wed, 25 Jun 2025 16:08:08 +0000 Received: by hermes--production-sg3-cdfd77c9c-j9cxk (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 1e59b5f3692e200e35ec2e6dca6b18c3; Wed, 25 Jun 2025 16:08:02 +0000 (UTC) From: Po Lu In-Reply-To: <86ecvvj433.fsf@gnu.org> References: <86o6vatvc7.fsf@gnu.org> <864iwzre9r.fsf@gnu.org> <86ecvvj433.fsf@gnu.org> Date: Thu, 26 Jun 2025 00:07:59 +0800 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Mailer: WebService/1.1.24027 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Content-Length: 1789 X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: >> From: Stefan Monnier >> Cc: azeng@janestreet.com, 78637@debbugs.gnu.org, >> app-emacs-dev@janestreet.com >> Date: Sun, 01 Jun 2025 12:30:54 -0400 >> >> > 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? >> >> Yes. >> >> > If so, could you explain why do we signal an error in that case? >> >> We don't do it on purpose, of course, but the code protected by the >> `(unless after-init-time` test presumes that >> `custom-delayed-init-variables` contains a list whereas this >> assumption >> is true only while dumping and at the very beginning of the >> startup sequence. >> >> So the code work fine if run: >> >> - during dump or very early startup, when >> `custom-delayed-init-variables` still contains a list. >> - after loading the init file, thanks to the `(unless >> after-init-time` test. >> >> But not between those two (i.e. not from within the init file). >> The effect of that code is to fill `custom-delayed-init-variables` >> during the dump for subsequent use in the very early startup, hence >> my >> patch replaces the `(unless after-init-time` by `(if dump-mode. > > Thanks, feel free to install your changes and close the bug. These changes prevented standard variables from being initialized on Android, which was detected by my automated testing system and which I've attempted to address specifically for that system, but I get the impression that Stefan's solution also produces the very same issues on configurations --with-dumping=none. Hence the correct solution lies elsewhere. I'm sorry I can't be of more assistance, but my hands are too full at the present. From unknown Fri Aug 15 21:27:20 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78637: 30.1.90; Calling setopt during init loads cus-start over and over Resent-From: Po Lu Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 25 Jun 2025 16:17:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78637 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 78637@debbugs.gnu.org, app-emacs-dev@janestreet.com, Stefan Monnier , azeng@janestreet.com Received: via spool by 78637-submit@debbugs.gnu.org id=B78637.175086816711854 (code B ref 78637); Wed, 25 Jun 2025 16:17:01 +0000 Received: (at 78637) by debbugs.gnu.org; 25 Jun 2025 16:16:07 +0000 Received: from localhost ([127.0.0.1]:37312 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uUSn8-000357-TR for submit@debbugs.gnu.org; Wed, 25 Jun 2025 12:16:07 -0400 Received: from sonic305-21.consmr.mail.ne1.yahoo.com ([66.163.185.147]:44336) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1uUSn6-00034I-G4 for 78637@debbugs.gnu.org; Wed, 25 Jun 2025 12:16:04 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1750868157; bh=Ow20S6VWXe6X/0ADcRK2GuxBlH71quYz/52wnxAO0CU=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From:Subject:Reply-To; b=IJ41w5YDDdR/hx36SYNWOkm5LEQdALvFLoh8CTT+sM0Hgdk/jEcowG+h7Wtp87LAijgjNoB2lPJgKowVLIgyz3t76hZ+o6DgfO8fwqUV52G3ASQDpR64i72evji0XXDwy92cgF9g+2M1Mr0nZ03Q4M0Iggp+yvvc1yrcBNidVrD3OP/1JY9ZrTxSXmsNmZ8+SkiRtwSw9hpxQBC9AboLBUS4sfkqx+bnE0XTIQIUabeUPnq4CHsQszIDgSijHqFj4VOWD8RRP3nTMHla2i3z4AirxpU96xK99kA8SlS/npIvgSIAUu353pcdFa+zHCGywpCEGLLeiA1BYs8CxBv9wA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1750868157; bh=AfZbclNQBuEBdbmsHPOkyXXAxQ8E9iT4LrzkpFGswzK=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=lUR0/7BoSSqTCCzdSikRp0P3pWqAxAj3oZE3AsS9+qlYXQ4KeUsS2Q9BoKYUdfmJDkYGSm93I8iEQKGqv5ETZbvB2Jk/W0YKCdpTf7BAwTMAjEj+rvLuntvYnWjUKQNgOXuIkmcLj8qL924ltMgsGMipoyuRVXi0Th7FShQMrhbTwag49d48Tn4IW6lGOECKTmdkFOydLPAnttndFa4k6Q6nSD3fTH4gdGkQyKFD1DaBK/zSxvbqq132YHYMfrSMX/8r/OLP6maySNYegmdN6mL9hbFpCYDV9qjBVUhawBrPERuP/5m9QiWaMOmopa0a1m88TuOYcOS4Ov0GoS4RzA== X-YMail-OSG: jwCCJc0VM1muQbetA8Lj6gBMbl6oo9cPpfQUrKtkODzUetpCZZcCoo5UMaXUliE T7FzOHecayeb2FbtKPvB4G4ZCkIk69Jh6VywHeJtdKabB2Mnm_cDmCvrlGi5uT8o8TVLdmfKxjle LDqmpICCks_WKBr2rHMHr3rWkucnk23pzzo_pQvcTXlocb1pwJQ8kcLmUkwToNzvFyGDhBzdXG7i 1xkKxdNu9N_.JC3S9u4Soc4pJOS_4z78qDYwE4xIjvttx9lWc4qgIsSeG80PKSqpwEcgdETQ1Mtz Ucdtg1c4Vx10DApGqOfx5keTZCvXZVF8tqrCMYu5Mta3hxVLtop6Bk2WBPoT9pQaDobIYCwjTe9K iewX1VGtHsd_1mEgOnu.iRLkuym4yvjE_midQ28ViXijhWfsrXPCtBe5DfNEtpT_pj4R5Ew6h2OP ZiakTtj3QPPCL_GKA7adbR.Fwo3n07hnQEq4x1uKfebB5g_vSdqKqil4tOzFegXkyCUNrjd3NHMg IwXafAmTl5WzKbh32gEGBg_TI771PHIOF6gYn7Hnrix2KGGQJk7wgERlQZfwGIn_WB3buJBDfssn vDCMvxgindHUiPK32mVd54AVrsNKX6bOHGKPWpjruZxZGwCxluzJezjK2qDQsm9V0QvpsYA8u59L QM.LJSTiMD90ekk686sYS93jPSPVFCsgzJgXRlwFEDjPhANThJC2K8ky3YhXe_bkV_56kYy2YXO. xdnyLu1UtM5WbPmhtM8U3_AgcpxLybrevBWeEilF_aLfvNqNGizH6GXtiOLSEwLanNeTvO8SQ7LB 0zaAPYiQ81e3bNNTio772eAySsqi.uDmoyWp0EQMHw0_AAxwx9vqpmrlcDDhRlYLjO5WcT60_bL8 w7L9aCV_nmELXFKVsf18.8oTM3cHgRsCsC8KljATiAJBDUzuLu4OwoIAAU7BsHeT0Op7dhDr7v.7 PScWm5jk.SBZeyQnFs1fYqiNRXXiJkDCQpHWu2qKcaUuLueX3xOoficyP9SKhsDxHDEX4aBVe40t V3uAwSt.HQL0XGxddUZ.bXzeHOaGdiJ6andgr_Xl3RlmU12x68bC1SX_jWOKXV2_j4eFz8FY1cez RF1acelHo896Xgreq1ChKwl0cgj3yVoieLXx3a2C_UToOUWflkKGXc_RxGIohUZnVoS2r5KiVQnT OzzdPkKIATwpkYbpsvdyWILvORIJ9Weq1wBECm9ph8uNixqTIqKosm58T3iNmv8ryf2mega3BzPS P1v9UV3dkWeJeqhhkLdeNY4YKB3qq71xJiN6SJkTIbGXMTqAnGZYelQfi3WrACGQmIf659H058QU .8snkHJo_AEWPCt00SRHX0VV_W2L3tqo.oNmLY1avQs2TxjEwNPZCKJxJQefAk0lYn1ieGjTleD8 oz1BO1Ymtp1U_QWWGgEcSaPl1HZDOLRIY49AP11DZX1NoXmrAHiwpPEob_2Avg8ZQOeDw7YxoUy1 mcnRaHXbSORLIx.p54rSMdnIyhSXWkERoYbJrpY_xXpFfG5kY23EoBbseOzNgPj.plkBziju4bb0 UgADCqRg4BgogaSD61rPZtUAqNAUIC.NzLCrvMiA7pfVBcTr9feoQkvajLE2z4Lb99DXx2mURTD. Q2FbZF160tSusJ_YG.90YyQrrgcSNcg_gQkPPTF.SL5UmutruR8i8BDZkwMaAm6AOATO_fzcNbMQ jod2hUHxSwToder2PkjGSNX4bHtToI16IExUUV6X9NTWufdxdKG607JmbvSRFU1T6BwK3KFzVEWD NcNPXuP7NG3uw0MgCQlASGhHwCoZpdtpRkDO.DQT0uclJTGtNke80ZfTN0k6A9DtyKtSusTLGCy1 VzKAVVjZ_lppn83XRyCmAYgBxtHyo_g3ITEAmiiq8K3PjlsULQIcAkfpB4L3W_Bevt7H83qSPmPH F52UKu3S1NeH.GfL6t4l5areRCt9c8fHcFokQ2vvljs3jNN_qoh2_sdybaB8g9wDD_g0wg3GTxgY dhuaP6I.7XPFDwE3Cln_pKGEnRhIJecyk_bya1fny1KemMnKWhsI18B73h1rKqUrJT8N6T7GgEWq 6tKZUAJ5weD6FDc.WWOiLl8geBZO_I0ufHLc8TjdCSByTbsj.98uOpcjEqFYDjDZUpqJrdsiCkxF vsVuKKNvH4tYJkSYg5umPnkwKLo_yjfmkPy1Tg68wO2_Q8RFCqvRlygDuXob9Z8nZj1j6uC4M4xG qBu1349veHzef7T5qTFDVkoKwvvmZWu1JYJM- X-Sonic-MF: X-Sonic-ID: 340c9e18-9993-4722-a043-a7ef5b3a62dc Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.ne1.yahoo.com with HTTP; Wed, 25 Jun 2025 16:15:57 +0000 Received: by hermes--production-sg3-cdfd77c9c-gk59v (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 393839b0c34217b388e5421e1819b42f; Wed, 25 Jun 2025 16:15:50 +0000 (UTC) From: Po Lu In-Reply-To: References: <86o6vatvc7.fsf@gnu.org> <864iwzre9r.fsf@gnu.org> <86ecvvj433.fsf@gnu.org> Date: Thu, 26 Jun 2025 00:15:47 +0800 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Mailer: WebService/1.1.24027 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Content-Length: 922 X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Po Lu writes: > These changes prevented standard variables from being initialized on > Android, which was detected by my automated testing system and which > I've attempted to address specifically for that system, but I get the > impression that Stefan's solution also produces the very same issues > on configurations --with-dumping=none. Hence the correct solution > lies elsewhere. > > I'm sorry I can't be of more assistance, but my hands are too full at > the present. I should also clarify that Android builds are dumped with `dump-mode' set to nil, during the first startup after initialization, because the session where the dumping is conducted subsequently becomes an ordinary user session. (As this is the only opportunity for dumping on Android, where no facilities exist for running code during package installation or at build time, as Emacs is cross-compiled into a shared object.) From unknown Fri Aug 15 21:27:20 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78637: 30.1.90; Calling setopt during init loads cus-start over and over Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 26 Jun 2025 17:04:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78637 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Po Lu Cc: 78637@debbugs.gnu.org, Eli Zaretskii , app-emacs-dev@janestreet.com, azeng@janestreet.com Received: via spool by 78637-submit@debbugs.gnu.org id=B78637.17509573944893 (code B ref 78637); Thu, 26 Jun 2025 17:04:02 +0000 Received: (at 78637) by debbugs.gnu.org; 26 Jun 2025 17:03:14 +0000 Received: from localhost ([127.0.0.1]:53289 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uUq0H-0001Gr-UZ for submit@debbugs.gnu.org; Thu, 26 Jun 2025 13:03:14 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:65125) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uUq0G-0001G0-AO for 78637@debbugs.gnu.org; Thu, 26 Jun 2025 13:03:12 -0400 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id E30E710013E; Thu, 26 Jun 2025 13:03:06 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1750957386; bh=HFhSaU/jKMrBUXCy8A0tjDRe3a0djbJGfLlTfoRhvQ0=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=kYcb3QvUFUxwO1yVlW4Nhooa1U3JCPhp+u2nDkKgS1QxFSNHdX33dKlx/5dxshYhd IQONE4XOW+syj2oqPdFXvWhEFDjcbJQYt8wBAQUYtfa/6I60C95r1FlTQTZKLFJrJs +w2AcKyzpUuu9A+bk9YVYJSmc8lkHtBTYLWAp333z4HSJkhfm0oqdEFVXDUH2AcXjY O0fSco6exIKbPpe8CxFjfJzicfcHFC+cOFpyIBim6N4GtzEauIkzyl3dNkMJxfmwGl sdgfYhuwlKNgdFfkK1uaZlI9FXalrgy5uEwlz1cDLYCmTrhbx3eTNdeQGMniRu5ss9 sCmxMPvEENoIg== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id ECF6710002E; Thu, 26 Jun 2025 13:03:05 -0400 (EDT) Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id D9C4412062E; Thu, 26 Jun 2025 13:03:05 -0400 (EDT) From: Stefan Monnier In-Reply-To: Message-ID: References: <86o6vatvc7.fsf@gnu.org> <864iwzre9r.fsf@gnu.org> <86ecvvj433.fsf@gnu.org> Date: Thu, 26 Jun 2025 13:02:57 -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.094 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-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) >> These changes prevented standard variables from being initialized on >> Android, which was detected by my automated testing system and which >> I've attempted to address specifically for that system, but I get the >> impression that Stefan's solution also produces the very same issues >> on configurations --with-dumping=none. Hence the correct solution >> lies elsewhere. Hmm... I think `--with-dumping=none` wouldn't be affected. > I should also clarify that Android builds are dumped with `dump-mode' > set to nil, during the first startup after initialization, because the > session where the dumping is conducted subsequently becomes an ordinary > user session. (As this is the only opportunity for dumping on Android, > where no facilities exist for running code during package installation > or at build time, as Emacs is cross-compiled into a shared object.) IIUC on Android, the first time the users run their Emacs, you run a special session started from `temacs` with `dump-mode=nil` but where you do perform a dump at the end of `loadup` and then continue on to a normal GUI startup? In that case, I'd expect that this first GUI session works correctly (w.r.t `custom-reevaluate-setting`), but indeed the subsequent runs (which presumably make use of the generated pdmp file) will fail to reevaluate the settings. Is that what you saw? Stefan From unknown Fri Aug 15 21:27:20 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78637: 30.1.90; Calling setopt during init loads cus-start over and over Resent-From: Po Lu Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 27 Jun 2025 01:40:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78637 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: 78637@debbugs.gnu.org, Eli Zaretskii , app-emacs-dev@janestreet.com, azeng@janestreet.com Received: via spool by 78637-submit@debbugs.gnu.org id=B78637.17509883697428 (code B ref 78637); Fri, 27 Jun 2025 01:40:02 +0000 Received: (at 78637) by debbugs.gnu.org; 27 Jun 2025 01:39:29 +0000 Received: from localhost ([127.0.0.1]:55996 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uUy3s-0001vj-Lq for submit@debbugs.gnu.org; Thu, 26 Jun 2025 21:39:28 -0400 Received: from sonic314-21.consmr.mail.ne1.yahoo.com ([66.163.189.147]:46607) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1uUy3q-0001vB-MR for 78637@debbugs.gnu.org; Thu, 26 Jun 2025 21:39:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1750988360; bh=Kw5z1w5l4CI9yyNtl9jDlFbWvkJlavX9Q0u4gpK4H7g=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From:Subject:Reply-To; b=MbmHylJdrfxyBjb8oX7zAnfYGeUvUosTAxFeQGianAJPPcHxGFpXMnlVQ9bUn77JqGQLvcSkPyAyqLa9qqIoH0ldAe4i1fRAOFYO1CJZZMIdWjooMCpnEjJOcdDnLpMgeiuKmuiJXHp02AD3RPWpEZsQx03tw1eEqcPFSuwADIlu+MS+vBXw8kkFpMvFyP+ynzwioaog31zxfKfBmvXZXlUgaV54NOHxzuc/TD+It71XxijG9WUVZPEViMoxUpxrj/0OdJJj9n8DXrWmUKFaEPAXd9JAqqJU+ipWHijmaeAq4auPY9myTIbDNRSJWuhk4LWzGGHR8eHxPWyisQ3qVg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1750988360; bh=tD11FLPSxcUgCZWEm+uXy1dCnUM2SXWM9GjyYNNZyd4=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=oXCePI6GfsGydG9fMyEcSpyUvkXYimfO9tA9jh7iJYJIl2FsmUV2V1UG58NXxzRbhchKbUC4EJB+D5jIkFlaLLOmBGT+x4o3KlsYicD6Lb3yBqK+MOfLliKVbY18s5vgnBHqQfFa+pab2soEMbmxSr0Y9QE/zAv2nEJhzHqPJejmNuutYw3Y3lbbGGts464e6pvnrY98mfjyHJD1UKPMblOwdlHYBzeANeSt9teytPuRlPd+r7JIY3a0aNj51rKeqKoY3G1HiiT/wFnRWxZrBSKQNlI39JeLY/GKcb6cygEFRHQ45jN1nCuC72oNomNuocBYhow1Nt/eUkrfpPwR3Q== X-YMail-OSG: ddew6FwVM1kC5vbEl0WFTIjibRGtuASoSXN9dn4EOllLnae35Ecm7GBNf6pQcj5 Chu7U3Jgn8GJf7PK6sloEk0Pef5o2k2WlWyTJgqRQe0wkycGfHnTBaqGxQUo9eSlPZiBp3.UHljO iqIMXPMsqnRSF.q1CnqTVgKKEehprXRPlX8BxNfHXUQfrnIjA59jj2KexiKqaNqmShvV0AgrdHxe r8NnrOi4DTb_h4Xwch0AXchffaXh1C.QbNGO6Al_yjnT5cVozPbavZHe0r1NR19sQBAOVc4hWGwj zQINQIMIa2n7_H_6HWQqkfLGa5yMr2FBW807j.02KFQORtFftV8mw2Fy7r96WCOjnuxXT6du0Uxq K03FXsXmx4UfE9m_MS09qDMR9tivyVjXAMm44r463EZwnj_UfPH5N28B103GtEr_1D6vsCxeIZeT TOtwAe9q1EBdORChNqSM.O3Kt5byVPCvW24ChedBcwXeyOVeVzD4zEz5OEN38.GtZkFxaeHitVzH brQdofB.1XINMgMLbQWqD8RbmSOO6lpmcA8UuFj4EW3zz5ZWeIxBvfdcrvOp1Z4h3yH.8GrPSaMs 6qt91u9fHmABbAUDFt78znCLUwL_V8RZ_XsreYVU3Lvf0gLxbCkZ35VHhkRkqdbOM3g8pArRZzGI 9WMzcQoWYexOaK3FlvUIKCope2_9SD5qCRzCJHyCi2VVic5mbGvh8OXn1Zj4ehDPIE9CMR2Q5p5X JQHMlk2MwaWMaK7VAJWrsWmVB0uSus9Oven_TzaRw6pn2txQXHhxb0Ih14H5xcEoNmR3hQOJJixl 0Doja.oIoamZRmmCBNqo4FhVPGS8gkam9Cy5SsSh1MXeSh8fYs5FMO6tQQQ4ZPe9ERoeSKRxr9ee obmjkmWNaUUNmDuyqwZGkCgp0RgV0d.9tr.8GYYV0iBZRPijXWRhE8oKlO4oyaGj8UF60L52CXpV fEWAYZOYh7MzxwkbF4NHzL8FsMtZljxVeWqpV61aTblDW9VWx6U7n0qi.PTBinRzxUII4SH1xn7c p94OZISROIWJkU1r.JEJidv6OCqNQp6ZBUrtfDuk90pON8vEmfLcuMHarLS57Vpm1APePXO3xJVX 9O1c6kzBazAxSpWXFe4hKXfIpDUh.INjUTIObMl6Fp_46DEkSTzvWcmNKBJF_JKRmKIH7LkGr6sS JyepfjG6UPghbehbCiid.3RNoHJ8cQL_v0PLinxzIIsjRhXovfa3ec2xDbwlEz6d3EmmtMQIOe0j ythoF_B38LMWaAvR_padg4m0q9fFeCKWKAiyGDo5HqtsQ41ZW2RzkXU56mDRApreZFdjrikavAOq qSJ2AYUKJbjfx4b6M9_S2SQfZlKES0P_bZOaAkNMsuLTanartkcFUdA3WBCk7BqfbpS2oZsEX8lt a98Id_hjRpP_tX7rVMZP8zeq3mrIZ7zmNWKkZn4WoCMOqzeCh2fRFa0WSkGV0jpBU6bimoA_LSVF N9mTADWW984CfVdwmvT3v8pfQwPzgM4YTpKy9RZDjRUdMXx8sKshwiXAKkrGCUjahIIvUl0hymGZ UdyOm.MyjmlNUJZJc6dgT8.eCxCVD8F02SuY.uPYOAI7nY.lTGsIlcYlNCDtKd6DikCTwDUoTEEw 0gusHNXTHml6tjCA1V8Vyprt.uANKY6onnCKgP8wTOuDnURt0yzKr4TmB3C.8X3dEKiVcttiqoFQ 5A6wu4ERoVVCiU8p.ztRcIFhLD90jca7PPHDlSg10SoqfoQmboiPY_pkgYzlEFo_PMiYKMzAHXg1 D35tkYAfhKzcwRHyameT9jMCXFl1SVBUwLgfDPyQiu.ziTUcPDTWRLfHA5ADFDsa0Lr.dn704qrx O4KO34YXyyboYfipOXCeKMb3R7fkDifETrW7zsFrdfDrHVyUUqL6epMQq9fX2j2Va7o71B9BYUHg aglFAsBlK6t6TUA.qPzkeDydQGp62LD6x5TpkLdFbFUY3XU52Gu.c9zK5CHjDYPd7KDLSOSccPwG 5Vz8ksNhyGthh4cX9XmJIvYnKtqcCDGAeEcD3s9n4.7c4Uh8Yyy8gc6gZapfC2Y7LbJkr8gUpu9Y YfwoZ1VUnC0YSNDhDIFIpKxX2Qlup4IJ3HpTAgatmFFoR5iTlpKjHdf2.i6xNvS6pDH8mcp07iNH KOtMrY3RCWlmYn6dHIB21963e0PcrMK_c2tXYg.rMB9LsS2HWZnFS7Zg_Pj0vPMVz_VAgvsVTYgL 4SGkoXC9Fj4jljMRzD.zn1Oncf53vOt.fD53WRodxK0xkaqfq4scyKdfw5Q-- X-Sonic-MF: X-Sonic-ID: 2a6b0291-7d62-434b-881f-29a59c54cdbb Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.ne1.yahoo.com with HTTP; Fri, 27 Jun 2025 01:39:20 +0000 Received: by hermes--production-sg3-cdfd77c9c-l8dbd (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 36491b7975b73d13e3fee2418e9f69c0; Fri, 27 Jun 2025 01:39:18 +0000 (UTC) From: Po Lu In-Reply-To: References: <86o6vatvc7.fsf@gnu.org> <864iwzre9r.fsf@gnu.org> <86ecvvj433.fsf@gnu.org> Date: Fri, 27 Jun 2025 09:39:13 +0800 Message-ID: <8734bmq7y6.fsf@yahoo.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Mailer: WebService/1.1.24076 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Content-Length: 739 X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Stefan Monnier writes: > IIUC on Android, the first time the users run their Emacs, you run > a special session started from `temacs` with `dump-mode=nil` but where > you do perform a dump at the end of `loadup` and then continue on to > a normal GUI startup? > > In that case, I'd expect that this first GUI session works correctly > (w.r.t `custom-reevaluate-setting`), but indeed the subsequent runs > (which presumably make use of the generated pdmp file) will fail to > reevaluate the settings. > > Is that what you saw? I believe so, yes, though there is no `temacs' binary, just a shared object that is loaded into `/system/bin/app_process' and which is used to load dumped and undumped sessions alike. From unknown Fri Aug 15 21:27:20 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78637: 30.1.90; Calling setopt during init loads cus-start over and over Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 27 Jun 2025 21:45:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78637 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Po Lu Cc: 78637@debbugs.gnu.org, Eli Zaretskii , app-emacs-dev@janestreet.com, azeng@janestreet.com Received: via spool by 78637-submit@debbugs.gnu.org id=B78637.175106068811973 (code B ref 78637); Fri, 27 Jun 2025 21:45:02 +0000 Received: (at 78637) by debbugs.gnu.org; 27 Jun 2025 21:44:48 +0000 Received: from localhost ([127.0.0.1]:43693 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uVGsJ-000370-Ee for submit@debbugs.gnu.org; Fri, 27 Jun 2025 17:44:47 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:21258) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uVGsH-00035n-JU for 78637@debbugs.gnu.org; Fri, 27 Jun 2025 17:44:46 -0400 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id D4B93100374; Fri, 27 Jun 2025 17:44:39 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1751060678; bh=fvJOHrrkBsujwkRcFBt1RdohVQOSXkZzsQuZqwaV8aE=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=P2/EYaK0K4Pio9suPV6u7C6Fu6BZMk2FSdeQD9O0/pV0eKuy4psJZNyemdwUWxdtH HiiYYfUDtMEInDMGcTO0Fa0c0+AGy5+4pgp3olqEHE5JHhDmnSWGR5Ud/F9ziZKXjE QOQ6k4/RVS/BZC596SZePvSUN6tZtAlxCo2fvi+zp9iAwDq19FABqXFD07kRBitnVX rAlhCDkGZCWMSxQWDhZxIt8Nx3s+Cu0HWhDiKHpglF2fv4640Y0Rqmgi9Lqt2dfd/y 5WVtx/ZeH4ctXV26Vry8KgLxD6hTAezt2uq3CVNFjisph6KK7MN0wDA6T6WBYpwNqK 6VHGDHtIUKzCw== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id BB30110013E; Fri, 27 Jun 2025 17:44:38 -0400 (EDT) Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id A74D512044C; Fri, 27 Jun 2025 17:44:38 -0400 (EDT) From: Stefan Monnier In-Reply-To: <8734bmq7y6.fsf@yahoo.com> Message-ID: References: <86o6vatvc7.fsf@gnu.org> <864iwzre9r.fsf@gnu.org> <86ecvvj433.fsf@gnu.org> <8734bmq7y6.fsf@yahoo.com> Date: Fri, 27 Jun 2025 17:44:38 -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.093 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-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) >> IIUC on Android, the first time the users run their Emacs, you run >> a special session started from `temacs` with `dump-mode=nil` but where >> you do perform a dump at the end of `loadup` and then continue on to >> a normal GUI startup? >> >> In that case, I'd expect that this first GUI session works correctly >> (w.r.t `custom-reevaluate-setting`), but indeed the subsequent runs >> (which presumably make use of the generated pdmp file) will fail to >> reevaluate the settings. >> >> Is that what you saw? > > I believe so, yes, though there is no `temacs' binary, just a shared > object that is loaded into `/system/bin/app_process' and which is used > to load dumped and undumped sessions alike. Then I suggest the patch below. Stefan diff --git a/lisp/cus-start.el b/lisp/cus-start.el index 5057ab93161..79c23d9328b 100644 --- a/lisp/cus-start.el +++ b/lisp/cus-start.el @@ -949,7 +949,7 @@ minibuffer-prompt-properties--setter ;; 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. - (if (or dump-mode (and (featurep 'android) (not after-init-time))) + (if (bound-and-true-p cus-start--preload) ;; 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) diff --git a/lisp/loadup.el b/lisp/loadup.el index 6748c0a0750..c6cfc5690e2 100644 --- a/lisp/loadup.el +++ b/lisp/loadup.el @@ -392,7 +392,8 @@ (compiled-function-p (symbol-function 'macroexpand-all))) (setq internal-make-interpreted-closure-function #'cconv-make-interpreted-closure)) -(load "cus-start") ;Late to reduce customize-rogue (needs loaddefs.el anyway) +(dlet ((cus-start--preload t)) + (load "cus-start")) ;Late to reduce customize-rogue (needs loaddefs.el anyway) (load "tooltip") (load "international/iso-transl") ; Binds Alt-[ and friends. From unknown Fri Aug 15 21:27:20 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78637: 30.1.90; Calling setopt during init loads cus-start over and over Resent-From: Po Lu Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 28 Jun 2025 01:22:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78637 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: 78637@debbugs.gnu.org, Eli Zaretskii , app-emacs-dev@janestreet.com, azeng@janestreet.com Received: via spool by 78637-submit@debbugs.gnu.org id=B78637.17510737157563 (code B ref 78637); Sat, 28 Jun 2025 01:22:01 +0000 Received: (at 78637) by debbugs.gnu.org; 28 Jun 2025 01:21:55 +0000 Received: from localhost ([127.0.0.1]:44952 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uVKGQ-0001xs-Ab for submit@debbugs.gnu.org; Fri, 27 Jun 2025 21:21:54 -0400 Received: from sonic307-10.consmr.mail.ne1.yahoo.com ([66.163.190.33]:41976) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1uVKGN-0001wS-Ih for 78637@debbugs.gnu.org; Fri, 27 Jun 2025 21:21:52 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1751073704; bh=rmUNSzCtZDPj5TzSug4zMdbti7LHeVjUJ1A1tjuWUKU=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From:Subject:Reply-To; b=A8J+rHUV/Iam7t5WrTQLjIGpVe8ImIf4AtANb1InKWBSNY6XVWFTbOyO6wLbKKwy/KD995gNoILrngYuTZfJ6aYbe5IrDO8mg38t0ZFhSp+o/16vSXDfFy6XdCAgjo+gV4jfv8ZIAvT7oYi8SYwHTJlqsimTOaRvKJ83WXUT2kEl91vbtqT04oAdIeSTbbNpzPJrIXf6XbSbUYv4nG+KMGp6W7oMdxU9vD9+y66LJ58SEQy5hgvHQgu+pUh5pwC8RgCrT6b/AptKo15he5KMzgK3Vteuy10TK1yrtQmIGxlhBVmXmt/qrCanHpFewOKxAI3ZSrA6apxrA8LwaWZBFg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1751073704; bh=GHGr6coQlXXVASTgPm4g3CdcitcF4zdYdwAdCNpsVqJ=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=X46cIdB3R6yJvt6clrJQimu5kF/iouq8y4M/v4c8BASB0zbOq7CsjiKeClD7LdVrOetwtnwKHFOx47KudcJeBBQFkwiAZcX2XQ3Tarq101lln0Ujm0IDpaO7yYH2/3GKcLEMq8wYdPb5sKelQZbkH8tdZHjfcv3zyCYJdU5nL12f9+4QjQ13zkIuIvk3ERMaPmK4B7A/EVg/s/hS8eEw3YrQpU7BCcPMtug/mV+0fR+PvdbEEtvvZFIvoElqmGrDaA4HTs5JDNa0KlASmRLu2RpQXMtgnHNXo6rv0OcnDsESrR/NETYOJZsPqOp7vWwRR5sYLMpVD5Y6BUelRaXJng== X-YMail-OSG: 6Uyk2yQVM1kc95PaRXJq0uEgBhhfe55.muuULHjmN0GW3en8VZK9MYsJFgAOvQc hKnAwecCD6t9i2gNCDQAG.BzcBWWdVqVGK2dAwlQF0.6scleSgdnZWt1ultaOvK._KRZKI0WIwl6 ctkBdDAoBmZ6h5hcCpcaWCzj74l62wlMZrESxYiO0IW7ys2vNzeiHN70ZtlEacqkVee0m.87AnOz 0dnD622DgUtjqivrWbZ7Ntb1HZgsmB9nbZ7bu6wYYTV7YEOi5GNoDEow41afRoi5uKtFC6hZ5bdG 7TcGZ_SfcLZLBP1b_AOZCyzxo7i0low6N2btYrnwu2b1RG9u2F2sA70xrC24sf..4gW_VGGm.y7c mInc4qcJiwyfxW0X.O2IU5jJHm0gEYk5uadDuFWeaoYFFld2ifk4NgBddKmfYdxEZ3Z75kV2QV2q m87ps7bbMMT9w_oUZHx7bXZYYH0R6rLcX5WvOis.uIpZx26degwyndCSVIpVEb3qT6tv4BePYlS4 kqco0P7WUZS6fMT0OufaEt_DLYex9SgdqcFD1GShuas9APoCdSsy9rzw1oXRVkLAINdygnGdb5xN ftjnhyUIL3GMbuyajD2KDjxEPoPtvHZ.OAHC0XVaNdxnkaqz.YjwfFUbH.rFD6LjOxeGlIH2ZGDU 0sHuBdLaQKKg4_Bdle.dNNxXRw5Gh01_m1_qZJaJrOrq5cNULQ.WJ2KXMOvAKdKj1U6jeL3NM.D2 2R8k8puL2Ur8TG0s68t48_aqujMGB_hVKBaK25C5Kjxrn2F5It_kr8A_JFOuF6x.tWCiFo9YuKgg 4FW16Ifgqa2yifGMCE6Ybl8afa635R6X5yAJeCFcdac9xBoTcSZzvIK5IIBUDkrh7WMDAtTriiKh jmIc5Htqtk10amdEJ.jhWasrgHBB6apL_CsjUEJL5Q3_ESD_E.gZAIqn0I5I9Llij1m2LnOrZQMz ieMBuespHXzx6UP4Crf2rmWa55Vc0kgaH7vx_op7gif04FBCA2HnhuAGkTRPuqQMYkFVGam3mFqb A2tI5pUVnCFIa3FzwVXDOApMrCkG5d8RJA46NmUQ.8VhPGb.l6.jexNHjPaULXPVsEkSpU2IgTex .hjHY2R1HbaoY6Dl4azF8iUzy_Ssv1oJFNzh0Kn02VD5UquRFZw.wYfLf.jTftgbQl6T9zMAJ.Sf ImVxvX5hh4iu2iZGMGXcSj4l.Kw6BGMT3XzY5i6XJqYPLYQraFTFP5le0lWguFogo56g2GMSeo_7 7Cbhf2eXMisONBVUUCyXYSZhgSiwdMYbMj47jMyezTVl9cspIYJEqN1cLl42JL2Ghjdh9fKEfc4M Is.CEhambbyYFvKD2SDEim_1tWoxI0eeJByEJr5D.J4e5yjEjMORbPPx1LJfm2d9nWJmim3rxK8g ezSKSxA6.SP6v9THIS4nN2AJWMS6OBMZdOqpM.uSYpKwbjiSUxu7955xzgowzPxS3O9aMpyHeWyh m2.96xFOMi_8Fd8mLh_MXkyv6HOnQ7waQzxqYY727AK13F4EcCgvRxeC6jEtrJfUJXRAcJeRFPR_ Km3VmQ7Mt_gYt3OAJCf7yJ7PT4mlXhAISmJrMXuqa3_sFNfYAnKv9nc5.eU5HecOzHQaDEIEPOn1 Y.NBLMY8.3SsKVJfuABD5dcYnQbOc78tO_W1mgMAD8IdwzOSF6fPWXDeVj.13JAT1fc3WyzK5dYO awlyDf.hGq3d1321VDq7so7DlKrG5ZCAwivpNmwXfNLTPtXVx300cdxnvhirolSoiHSd9ga3VPH4 p3rdOag63qu3iDDFvCBYZbvma9rxPq6UjhF41Ey5UacAoCrehdtkxslpdKiHxds1RA4_Et2bHhTK QFOzyBJD6bxg3NRpxTWLDrGRvG8TFD78EJ1MYfZtX58qIVHQKfzQSI_Peh5oQr9Z1EdrcarruWgk 44g2_Kw9jd0jx6aoEXB6U7WRTroTSCzNPmCyB_cUebl.4Lso9dSAwkf4PSDZtkC4c3t2drl2l9fx fL4dYs9L.IH0La566_PDicVXnZK51jjdzIPKVrlFXLyY02JEVGGt5XjigRGG6PkMJrvWl8UvnW.9 apSnu5eCZTnMqVsegtWCtkz1.IoSMWspPTb3TCYYA_dxlG42tW8ABCan8bkuWicfAdGZyci_Zjdz hhDbmZx9_IyUbQ6Z3lVUUSDomjHAmxLqVSLBIs5fU7xfIr2pYukxwW9cBZmmfd1lvMp9QiXCAE2M JrXjtUeLEegjWWtHY1ObEbnK3HFDJXJka1bDxXH3fBRd8efkGtX_SVQ-- X-Sonic-MF: X-Sonic-ID: a42f8688-a0a9-436a-830b-2d71437e0524 Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.ne1.yahoo.com with HTTP; Sat, 28 Jun 2025 01:21:44 +0000 Received: by hermes--production-sg3-cdfd77c9c-s5dsp (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 813ef7174a02befec271975512eaf379; Sat, 28 Jun 2025 01:21:38 +0000 (UTC) From: Po Lu In-Reply-To: References: <86o6vatvc7.fsf@gnu.org> <864iwzre9r.fsf@gnu.org> <86ecvvj433.fsf@gnu.org> <8734bmq7y6.fsf@yahoo.com> Date: Sat, 28 Jun 2025 09:21:33 +0800 Message-ID: <87y0tcpso2.fsf@yahoo.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Mailer: WebService/1.1.24076 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Content-Length: 181 X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Stefan Monnier writes: > Then I suggest the patch below. > > > Stefan LGTM. If you push it now it will be tested automatically in a few hours. From unknown Fri Aug 15 21:27:20 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78637: 30.1.90; Calling setopt during init loads cus-start over and over Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 28 Jun 2025 02:57:04 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78637 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Po Lu Cc: 78637@debbugs.gnu.org, Eli Zaretskii , app-emacs-dev@janestreet.com, azeng@janestreet.com Received: via spool by 78637-submit@debbugs.gnu.org id=B78637.175107937532557 (code B ref 78637); Sat, 28 Jun 2025 02:57:04 +0000 Received: (at 78637) by debbugs.gnu.org; 28 Jun 2025 02:56:15 +0000 Received: from localhost ([127.0.0.1]:45281 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uVLji-0008Sz-Dx for submit@debbugs.gnu.org; Fri, 27 Jun 2025 22:56:14 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:45198) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uVLjc-0008R7-6e for 78637@debbugs.gnu.org; Fri, 27 Jun 2025 22:56:12 -0400 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 5DB40440A04; Fri, 27 Jun 2025 22:56:02 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1751079361; bh=0bNxouLQqVG9IbPYG05Fr5RSclrE4nl9QpL7Efs5vB0=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=h5J21FysCPGJOmjSpoH2e68anI2oVWIt30f+KkC089Hm4UNq+7uJufcr7UYnsgh2Z Y0YoHYrpX4LNehhokIgMuDwOuK92VQS4D29IkBhf1YVT/pJ2AS27XELJ9JxSl8ZGRQ uCOxi0UgZC+E/QuMWspNY/Vv1kZ6gDbm7rx0x71WiBlcSS8HNuWoA2lm2wY4mQUgIg j/9zMF9jr2NnqsU3Jov5Nrsj+gpO4ItXPZ6olgZ9GBkjVbY4MGqjanC/rcUYynAmcr tGPG5u4AWwdCjgGBaWjCMT0vjWPtiKMYAnE1BvAJCjp58S3E6fYTk9E/zt1BOOzf7I mcYSHV1lHIiwQ== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 011FD4409B0; Fri, 27 Jun 2025 22:56:01 -0400 (EDT) Received: from pastel (unknown [104.247.225.139]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id BA4D512044C; Fri, 27 Jun 2025 22:56:00 -0400 (EDT) From: Stefan Monnier In-Reply-To: <87y0tcpso2.fsf@yahoo.com> Message-ID: References: <86o6vatvc7.fsf@gnu.org> <864iwzre9r.fsf@gnu.org> <86ecvvj433.fsf@gnu.org> <8734bmq7y6.fsf@yahoo.com> <87y0tcpso2.fsf@yahoo.com> Date: Fri, 27 Jun 2025 22:55:59 -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.296 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-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) >> Then I suggest the patch below. > LGTM. Pushed, thanks. Stefan From unknown Fri Aug 15 21:27:20 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78637: 30.1.90; Calling setopt during init loads cus-start over and over Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 28 Jun 2025 03:09:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78637 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Po Lu Cc: 78637@debbugs.gnu.org, Eli Zaretskii , app-emacs-dev@janestreet.com, azeng@janestreet.com Received: via spool by 78637-submit@debbugs.gnu.org id=B78637.17510801237804 (code B ref 78637); Sat, 28 Jun 2025 03:09:03 +0000 Received: (at 78637) by debbugs.gnu.org; 28 Jun 2025 03:08:43 +0000 Received: from localhost ([127.0.0.1]:45352 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uVLvl-00021d-IN for submit@debbugs.gnu.org; Fri, 27 Jun 2025 23:08:42 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:4602) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uVLvh-000202-BR for 78637@debbugs.gnu.org; Fri, 27 Jun 2025 23:08:38 -0400 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id EA2A2100374; Fri, 27 Jun 2025 23:08:31 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1751080106; bh=NGJujOjU40XgtVUNhsqmCtEC+e0XiKAEJX8Ax+QJsSM=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=QCtqff/Rg+l5VmO0/zYxzlu8Pgzi8aOG8kKe2l1oyMdcTKSOKKwY1JaTld2hl4isK OE24TjpefYjAL/uE646AKsnLcV19qJmN0ViDNxkmGSIX9kuqZCQYd1F6B7DOLnUF7p ESl+upAyub593N2+pMtDQ7iEG3dLZEy0XzUtH5nje3XrI/UgCkP+eI/ZeglLqFBkpg KBn+82Irm9oW30IrdrGZhnx5hrz3vPnYvmpyXMm+jechSsjTShMMz/4t+PWsjpY/J8 FWd6SRPTR6ixdB7Qx3IeVQyjHbyN1+LkzxGOuWk4LgQr8Mk/CXPEI4xjoYthqlU/qU 8HNo0MHoQ+sxA== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id CAB9610013E; Fri, 27 Jun 2025 23:08:26 -0400 (EDT) Received: from pastel (unknown [104.247.225.139]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 8D1D812034B; Fri, 27 Jun 2025 23:08:26 -0400 (EDT) From: Stefan Monnier In-Reply-To: <8734bmq7y6.fsf@yahoo.com> Message-ID: References: <86o6vatvc7.fsf@gnu.org> <864iwzre9r.fsf@gnu.org> <86ecvvj433.fsf@gnu.org> <8734bmq7y6.fsf@yahoo.com> Date: Fri, 27 Jun 2025 23:08:25 -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.310 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-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) >> IIUC on Android, the first time the users run their Emacs, you run >> a special session started from `temacs` with `dump-mode=nil` but where >> you do perform a dump at the end of `loadup` and then continue on to >> a normal GUI startup? >> >> In that case, I'd expect that this first GUI session works correctly >> (w.r.t `custom-reevaluate-setting`), but indeed the subsequent runs >> (which presumably make use of the generated pdmp file) will fail to >> reevaluate the settings. >> >> Is that what you saw? > > I believe so, yes, though there is no `temacs' binary, just a shared > object that is loaded into `/system/bin/app_process' and which is used > to load dumped and undumped sessions alike. I wouldn't be surprised if there are other places where we presume that `dump-mode = nil` means that we won't dump (or have already dumped). BTW, the above reminds me that when I tried Emacs on my phone, I found it unbearably slow. I assumed it was because my phone is underpowered but now that I think of it, it did startup much more quickly the second time. I assumed it was faster the second time around because it was still in RAM or somesuch, but maybe the excruciatingly slow startup was because it was doing the preload+dump and the faster startup is the more normal case. >From this experience, I wonder if the Android port shouldn't be more "in your face" about the preload&dump, i.e. tell the users about it, so they don't get false ideas about Emacs startup being ridiculously slow, like I did. Also, It could even exit after the dump, I think, telling the users to just start again (or maybe even doing the restart on its own), so it could use a more "normal" value of `dump-mode` which would save it from triggering old bugs like the one above. Stefan From unknown Fri Aug 15 21:27:20 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78637: 30.1.90; Calling setopt during init loads cus-start over and over Resent-From: Po Lu Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 28 Jun 2025 14:20:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78637 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: 78637@debbugs.gnu.org, Eli Zaretskii , app-emacs-dev@janestreet.com, azeng@janestreet.com Received: via spool by 78637-submit@debbugs.gnu.org id=B78637.175112035113279 (code B ref 78637); Sat, 28 Jun 2025 14:20:02 +0000 Received: (at 78637) by debbugs.gnu.org; 28 Jun 2025 14:19:11 +0000 Received: from localhost ([127.0.0.1]:50967 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uVWOZ-0003Rk-Lm for submit@debbugs.gnu.org; Sat, 28 Jun 2025 10:19:10 -0400 Received: from sonic315-20.consmr.mail.ne1.yahoo.com ([66.163.190.146]:46570) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1uVWOS-0003Pz-UD for 78637@debbugs.gnu.org; Sat, 28 Jun 2025 10:19:02 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1751120334; bh=/ue8KwWAazyZXVcDWFRnqCFmTZB5fe0YtP8OnzNwM+0=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From:Subject:Reply-To; b=U+9y+YDve0VkODL3/g/kKhp7pM17gu69M0K6GDNoTkhyRY1snvbkDgKDIVFxyWtelH9OVWQpUOtFbfAyaqc7EzWQPB/sh/hsR1r75DllbL1ttFGlgiiF8YL8iir+c0kePi/Yt/sOJ7iVq9oA9tpkyyZwxj8Hxw2uvBVcv3KCyDyZPfoHZuz3pkuM6YUJVAnicD395+cCqTAwJ+3L35HqoyyaRyGNgS1yHGLPI7Dz1+Kk7Kiwp8/R96BBIEGkaEGC/PejebCy0eZLDB8IZlV1kDBJbJvLNDCHtOeITwwP6UbKg9bJveUHyVe7w8OaXV3fNaAHBe0Tyi8mep6+myVXfg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1751120334; bh=LPu+Lv7PNCqbL3XiWJ4iURe/9vsDa3tdczgNvefcAQa=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=PuJKtIiYFbnj/AItxRZ0OmrqkTxuCgoH/QLsLUhdYFLvwjlKIwGWjgJO0v2F1kpEpXQsBt9flfFtz+g9FwRz3XLL+cXcOWc5wzfi/jN8wgtP2gEfeH+vBnniq3rto/3wKQHn0Sb/CZ4084lCqF/Cj4PJg1P5XcaZvsuhGQhKvnPEkDHhV8RV5wDJnDm+jkmkteTAqVBlce7fMfl+NTajDBgwSWm6h6yFIvWGizkip8SG+ivngu0xsqPKa0OMouhLAezofRIP4AdYmcRlGLUlvHgun8p66DHelKzTVUdC2QnOgdBz1kjZ/D7jPhInIdjnXvmMWBDBvgtPNZPKpdFu+w== X-YMail-OSG: o9qPz6EVM1mng_H0YzbSuLToJ9C2Jw3S.DYPoqNwPpnrjLxgxomvExSNi3pjYBK KztRzBRQSIYSOhlvyFBOogUwn41H8fdupirXLi9psJhBtQ8uLuA6eOuPVuESSLJyYspUxNi0DuL_ yZy0ltyHDwgwGQD0Ji4BggA5hXFYf8KKnL.d93gUiket9WIY4wf3Z76hqBXcYHX2ZQ3uhQnY43eN vWwc8EFq.cl9re.CjOzh2wCH3HMvnEZSaNgaldl_L07QDXhktWaJSEsnJJk4j4dpYlIZ4HE8EYT1 vBw6D66c_AbZRhfbKgqBPyB00TaHPT1oQoC1JrpF5J0EFG70BFA.Is_rDlZKnPMwuyHp9FXozN7L rCAZhdhVm3Qr4KqVQdwuz1m.qiO_DhDCsWQ5MheYtVco31m8rXkuttuveKiPUl5i5KARELDqmKzf y8w6acqexmFmPgq68bDJF4smtno04KGEW.7PYXuHD7VmCIrsnZMQvLfUu7DLPVB1k8sG77Ot5m04 vl2mOjejnFbZ772Wl.Dw9aKluT2XvY8WYxq.7z9Gk6TNastAMS_y54m662.q98O5QkoXZKz_EeT9 JLVF91RrOWM8X7yzTSXAUeR.4NvjA9y5rdsdOkArb.azGYr0dXRhmIje23lhBM0Goq5HTUKyfBgo R9KkbWJLQt15rqhfcySTvphYWjRoe_asB0H3CpFjR2V3Kvxd2_VZ7aEHGiaKG4zn16H8w1ywlfil 7pE2dTz7YvnLm9Lv1u2umlJW_BSp1K7JfSqseTA9bN6Zf4Y7pvabLeSQkVhLVrHOfVfgUMeAH_D2 avsbm6QIJUmhOTZnrfuLwXquljP5CDcYmytV17eyQk1WNbBp.WrJ7l1VqYmvwx1rXORgCFT2Gqul Sb0TE1qIey_YjSXW8KMzYBoEK_S8gcXiZ40BmKAJ51SNyC3sARwf.lZM1J3zGU8rmPC3CaEFzjM2 rWsROGLF5qsD8eOPNmp7GWWakrc9CVLxUC3SprVjPyUWL8qvzHH.u53BE4z.nErnVUyNkZKTdmbZ cD5LsOo8treoqncD22OcYnLBKDjSYSvaYFzsAkdnEJp.dn9IxWvW8ty.QT_vS2Xd8RU9v3likdjG gx37wMDT9l22fJSq6SUIh.7pu6q9C2BZy8jHRRjr9ZupU_GMaiHwKz8msgBzbFND1ezdokRmhQOu jv2lP3X9KRuNPnwU68GCMIlkrcRuBn_8AiIz0p59iJ5tv48f8.TCWeUg6IOq5_Bx2c.IeBX3RqS8 VVnHnaK19Aw1zY19Rka23pdpsy3QJAfdqLZAS42OvW9UjQ0F0J7wzMCUwhJKS8IrAtr.VIuAyLbR rFPvf2iHaK6SMlWtyM2w7jPKJw0hSciuBRl3CHSHf9vfk5BFqiPRlvlPQADdOhgE8jQ.V4_caSQW 5EUJvzmrof7N1bKOV2KMmPbWtZPQU7ufU_cqABAg.ssKUiy7vER_dfTRhypMi.ZyPMqsLPQRyNf4 OP9jqLSne8lj0QLxoLMA1RXQyQ5xZdCzrwXAL_Pon1BQ9._r7t4QRdyvSLTwtoJT3WBskl901f1f Q1I5lEKiH1DLmOYiLJSqJaWc5TEFbEHXANR3CJVCH7Ypaw3aSVTQHz1lDytDFARkL25TyBzkERFN QC37CeYZD6QgHgIvlKryiYq9JZvOVh.0e8NPOqOPCMc8Y3kiRMEuYrs3mkQ71RT_6xSlr_FnjY9Y wTkKcMDbESt1SM45tngQWQ9QU1A00.9aWwHjvjkum8C3mdE3Mxh_Z7JLmCko_oFub8QQrxwArCOX svcmxlSG0_1deWqniCehtefXedT5Z6J8uCkNZQ6Y1uKBAOcKYZC0C_kThqaKCmwE2GhXLMoQbLV1 gGHDJoXTrnqxDZkck2ivldkxscbAmIzMmrkBG1Q2SRfV3Fc96XtqJhI0S698FonVuhofy8lGlpVa RiyfFC9pZ.aA5YAgb.uYL5Ou1Hx8HRtPzb7gYi_ivepgJ9YCYdUWFo17uaMRgZJJ4yOiMwB9zooC tPm1OowFiPx9bEh12le0K4RrfLUTDg41MgMvKVxjfcx75PreAjBhS4qgVZTVAw.jp.m94.nUY6Dc TenQc_5q.ZM58QU3u.pcN3NC95cd_ovfco1fqnqQD8XFHyvPMcpGwcYg8Qvd0A5nTQl74XUknuPQ Bq1X7xI5Bw_du2G1QA.VoypunU91lNWYtevt8SFQ9sMB0lPtD3qKj0tfjDZCnTW9ndab0KQ9KAxe mt5C_gPdoXaGla3rtOyH3z6EKs.xBt_254T6bkZYmx5owjnhuyn3QtQHTJy2w_8VhpDs- X-Sonic-MF: X-Sonic-ID: 862a9f63-1b3e-4e5f-a79d-cf16bb395289 Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.ne1.yahoo.com with HTTP; Sat, 28 Jun 2025 14:18:54 +0000 Received: by hermes--production-sg3-cdfd77c9c-gk59v (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 92dfa1b1461f85d449d2ab4501725dda; Sat, 28 Jun 2025 14:18:49 +0000 (UTC) From: Po Lu In-Reply-To: References: <86o6vatvc7.fsf@gnu.org> <864iwzre9r.fsf@gnu.org> <86ecvvj433.fsf@gnu.org> <8734bmq7y6.fsf@yahoo.com> <87y0tcpso2.fsf@yahoo.com> Date: Sat, 28 Jun 2025 22:18:39 +0800 Message-ID: <87ikkgosow.fsf@yahoo.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Mailer: WebService/1.1.24076 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Content-Length: 97 X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Stefan Monnier writes: > Pushed, thanks. Works on Android. Thanks. From unknown Fri Aug 15 21:27:20 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78637: 30.1.90; Calling setopt during init loads cus-start over and over Resent-From: Po Lu Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 28 Jun 2025 14:35:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78637 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: 78637@debbugs.gnu.org, Eli Zaretskii , app-emacs-dev@janestreet.com, azeng@janestreet.com Received: via spool by 78637-submit@debbugs.gnu.org id=B78637.175112125921200 (code B ref 78637); Sat, 28 Jun 2025 14:35:01 +0000 Received: (at 78637) by debbugs.gnu.org; 28 Jun 2025 14:34:19 +0000 Received: from localhost ([127.0.0.1]:50999 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uVWdG-0005Vk-Fb for submit@debbugs.gnu.org; Sat, 28 Jun 2025 10:34:19 -0400 Received: from sonic312-23.consmr.mail.ne1.yahoo.com ([66.163.191.204]:45031) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1uVWdE-0005Uu-Cc for 78637@debbugs.gnu.org; Sat, 28 Jun 2025 10:34:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1751121250; bh=5UdXyAjxAC6aWYVauJx2jtpTDo/Y5iQuNunjDPSV77A=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From:Subject:Reply-To; b=odyTvkvE0teaqzKzPesuYpFFbd996C5C0JYGxuh6S/IFri9EbI4vm2SdRTW16YavmwocZeTYqDA5zDs7Ezw6+geL6mu5GIyv94xMgmoiSEcQGuElF5dmp0D86FJgzQqrPzqsGPtyezrBPk0l7AJtQdJ/d82jvBzak4rhyZh1q+1EpxHVez1JEw63H3kbxDsAIpHimwZ5FgFsdmnXb/Sp0xwrdKE30qztdtQMLRvhYu/xqvcaKjYxtSANXKeO7GYXabc/g70vHmWntCrrGVReEtToBOjcmZ94wN/31r6FVyD+tWd+WUGYnh2t9odhsvB7EEgJ38Z+FX0bHDBo1Qkzqg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1751121250; bh=0JVx0QcVpxiVdWos7SCQsG7hFoLgU5XHEYcFsufln9e=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=SyOYwiwyfclU0rWhLdIvSvjRVi3kE0hTgqHdYC3i0kv/UUCZ8vspbKJnSLg5KyWFr+fUrJMSZUwHu0SN7l1h1SE+cttvdvJg2wLz1s0Tk+J7UHe0WShYBnEDhjRIjEPma1SK5C6K86si1vF9gbTQMlcAVTScxTu3hygFWCRHCZ1nqHEDiApuEdrosxKfm3PO1J3TTjTXZm8FjxnNBuqjy4xhRM3x0eM645rBUBexiCZba1T/uW5/5NxYMByYtEhdp45Mx/P/8kC4a80x4kUZk8s4DIe9+BTbx0slnu6WGA0AHck6i0OiY3th7P1P8hTAzBHw7Si6MqGEySwfbeC/6Q== X-YMail-OSG: 9FigKQ8VM1kilAwOzF5ocpp6M3xmFZlUAA68wupupWk_GNCcLEc8q1m9dWH_g32 9oLD250lZf75F1oiHwCmVyndMVBBhmSIO3wsn46JDQsFa7hcmTl8eE3ChHWviQZWfCfEHr8QSz7j 40yssHz0kLoR104ZwJDax2smhfxxQaP0enI.m_OUkiUUT1K6MCkJfGD9EysqrPVXHsp3H6VuSEtO dQTbL3xZz3xKgU0iLq2eKeMvKx3YIp8RrmdTzK44eFbJCPFnok7MRYUDaEBPlH8NBk4p9VfWS52c n_65D42VersyiLKgmoTAnSeA6j2I6Gu8nv.WRSMt55xgcyHUbWdENFQ0Dsh7HPMzOIsU5I77pL2p pVEKWPSad.xoVurZxwfJXdVjJjoitTSDT6.NBEGWVIJGVZV2YclzAmjv.cdgovH7mgBnNAJsXaYe Nehcp5g1B8t63KmZTKjxW2waDMAOw4a1ZS1dxBCvdbdkDOsHdkP9yLUpqmvdlmS0VPyi2pZf5rLp Xxcl_r4j7mfmPNh9eF.JtgmIDuh3i8FQ4s.R2Qxzd2rq48zSeLocHY_bUCQ2hVahy.gtZx3na42p 2ebnubQ3O123BrgL8rEWXfBaX36n_XAPCZOPYGzBClxvymAW0HyvAdBd33cQ_Ddq32sQvic5G7Y7 pAyXMv.t412Bmf0sYfVDh7c7YYCtYFIBvby7hpGs3AScprJuX.MGM9vXqrm9Xh31wg2TazV_BIyH lZL.yH0FqAHDD0_fh_cAwSKpZ2zcAyM0mrWbP.TKzDqZ64TcGcwrJTgt5w_Ka8OmPly1dy6uz2i_ TXX8WW7Y5CKSPoTIXnTN5H3EQ92nLt4D1U7.dQ36wGduU7Kf6mMfmU5xdu3MxzjDoVZBtpVgFTTu hJwAv9sgqTIzRY5vknS49mTiW6i1gwfVvvRgtkSU4SkV9OfkzlQZJuKsQcOkGmTNAwWtb_hLpmvR 3x.WGn5kZwMVMsL8GOiGenrZX.NiEmAVmhBdJh5qpcaiA8xEfQ9YEHTi0rOLF0w8avlmRrrwNhlj KBR4vXpnHXEwNvci2a6.hWygdrR1ozebW19QxLdvq3WsAmAMaHhRljJKHZYgSHHCd4MhrRPj5YfP m.RM5kW.AV8hiLbAok2gDdFCbxh03EZaVB9XfBfnQJwv0myw.5727H.pejuYBuR_ROG8k8XqL3Gt exr1GAzVAhthbK527iBaGhnXjZ6KbcAuPGYfoweY_RRFrA3gr8uM1kfCBYlEV0aaETrySwBljI29 nCpz0TDf354kpTcxtMg8Z.eSC0l2U_tAYuhMg1ZZpCTYxB42l4pVm_zPZGXijAs462k.PB.ZUGkG hjZFvKZOinB_spAibz4E4WD5dAq8o3uiHnspL1k2.9JoOpDKR6YSEmdVAaPOb0sR76YS3s.KXbXB UncNk1HFQa51fIQGd17HxqvTAYmFlqU6vvpvvDBOfm3JeCT4mqBFbt9Hieaa_lkBMhGyGwi1D327 KK1a9r_rvtlhgcCSkd3nu7sdI.NZ_U5I2EfvZ.YrbRQi9bvipoZ1TS7rbmeoyXIHe7HdqbC9Cbb2 qk1_T581UvdkDkUQ15g.Cx1ertcl8DmDzQKoh2gtuQtV6kkum_LO0YziX4tRDPX8QlgOb1ClZBmX 4FlV0u0QGYZUZZe_bV_HTIf9YcY4rRtQGcMm93WXBlNm7Belowt_JW30EU1gli6ES83RWPbEb1S8 sm95ab.9lSCHIirdcBl91E0jYOtvMmktQ0meF1L7.O8M8fLrL.fFFC_WuXWRqyaNg0Abys._I327 YrppPaOaYBrQUGMVL2vUoKz0oTCW7ecwZSjTeTzATgWXmYH7ETzFvHOP._XQ8zgo7O.P9UIUgEEB MOgnnIrDrIjTfsBny0fRg7hoT3_NQ2i.606Fdh2fGXQr1rXIR5Gqfukr9wCvYz4GyZbwnmmV7shu wAPyDQ0idM2lyLUup3l098FCCG7XXKi8JyJ3NTLrYJxKpnUmVw_zxmL5GlVtLumjhIHyzTBUzSPr VF8itVsYDduQunm86.U2KwN7sECQH_fwqNSORUrjmf4Ye90or1VmOeZqMPVOCf4yyu_fAas2RPTs eKXfxLiIlAHyiEkKZN2ZwpAVCAi5F2p_nvve.7UFnW7rKmK3P2bgjvQ5uauXajBGqMeL91RsC0jj JJbhC8RwnGZw6oGlpYQpCBG6VRCnA81uu0GN2lrimm_ZeibvIm5mVb4fgkIqB8FY3ntNrE4M27Vk gsVe1uKgPLTixDi6A1v3WDUhCglD3x8e6EKh38KekxQGfKfO7xgSepg479z5Nfn_e X-Sonic-MF: X-Sonic-ID: fa73afd8-40d2-45cc-9567-baefd1a54a00 Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.ne1.yahoo.com with HTTP; Sat, 28 Jun 2025 14:34:10 +0000 Received: by hermes--production-sg3-cdfd77c9c-g6c85 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 45585ae4096a010515939288debcc706; Sat, 28 Jun 2025 14:34:04 +0000 (UTC) From: Po Lu In-Reply-To: References: <86o6vatvc7.fsf@gnu.org> <864iwzre9r.fsf@gnu.org> <86ecvvj433.fsf@gnu.org> <8734bmq7y6.fsf@yahoo.com> Date: Sat, 28 Jun 2025 22:33:58 +0800 Message-ID: <878qlcorzd.fsf@yahoo.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Mailer: WebService/1.1.24076 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Content-Length: 2328 X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Stefan Monnier writes: >>> IIUC on Android, the first time the users run their Emacs, you run >>> a special session started from `temacs` with `dump-mode=nil` but where >>> you do perform a dump at the end of `loadup` and then continue on to >>> a normal GUI startup? >>> >>> In that case, I'd expect that this first GUI session works correctly >>> (w.r.t `custom-reevaluate-setting`), but indeed the subsequent runs >>> (which presumably make use of the generated pdmp file) will fail to >>> reevaluate the settings. >>> >>> Is that what you saw? >> >> I believe so, yes, though there is no `temacs' binary, just a shared >> object that is loaded into `/system/bin/app_process' and which is used >> to load dumped and undumped sessions alike. > > I wouldn't be surprised if there are other places where we presume that > `dump-mode = nil` means that we won't dump (or have already dumped). There were till I eliminated all of those I discovered which impacted the Android port. > BTW, the above reminds me that when I tried Emacs on my phone, I found > it unbearably slow. I assumed it was because my phone is underpowered > but now that I think of it, it did startup much more quickly the second > time. I assumed it was faster the second time around because it was > still in RAM or somesuch, but maybe the excruciatingly slow startup was > because it was doing the preload+dump and the faster startup is the more > normal case. Yes, that's correct. My phone is about to see its 10th anniversary and Emacs is absolutely serviceable. > From this experience, I wonder if the Android port shouldn't be more "in > your face" about the preload&dump, i.e. tell the users about it, so they > don't get false ideas about Emacs startup being ridiculously slow, like > I did. Sure, although this is the first instance I've encountered of this particular complaint. > Also, It could even exit after the dump, I think, telling the users to > just start again (or maybe even doing the restart on its own), so it > could use a more "normal" value of `dump-mode` which would save it from > triggering old bugs like the one above. Doing so would create a much more alarming surprise for users, IMHO. I can name no computer program in general that aborts on initial startup, let alone an Android app... From unknown Fri Aug 15 21:27:20 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78637: 30.1.90; Calling setopt during init loads cus-start over and over Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 28 Jun 2025 15:55:04 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78637 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Po Lu Cc: 78637@debbugs.gnu.org, Eli Zaretskii , app-emacs-dev@janestreet.com, azeng@janestreet.com Received: via spool by 78637-submit@debbugs.gnu.org id=B78637.175112607930999 (code B ref 78637); Sat, 28 Jun 2025 15:55:04 +0000 Received: (at 78637) by debbugs.gnu.org; 28 Jun 2025 15:54:39 +0000 Received: from localhost ([127.0.0.1]:51108 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uVXsz-00083l-P9 for submit@debbugs.gnu.org; Sat, 28 Jun 2025 11:54:38 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:16878) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uVXsx-00082j-QF for 78637@debbugs.gnu.org; Sat, 28 Jun 2025 11:54:36 -0400 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 21A57809FD; Sat, 28 Jun 2025 11:54:30 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1751126069; bh=HeZdyaqjH+Hok66a1lzXRDALRyyyin7K15aoJQ6Oeqo=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=aqUvlF1QwKEvoOHMDOB0vqDJ4eZ0KXIhnlzT0X07VSDdrNyfjQn9A7NpzOk2EybVQ LWuaPDfuOVFgPRvR+6RR6fC62SQ24JMKP/O9h5f4lBlDir1ZOzLZvYcQwI1Crm4UuS tac80Vv+QnJJyT0kZfT8LjkN73O92Nw1wkWq5qSqmTUgOFKUAjHou2E8qdpaLnOjM1 XPDmp1OVTG86JE6t1n3nejC4PrXydchItcIi5ZQoJK70M/z4ysvyQ2mUSKxz1FKm3C btwmknvf41mr482T8VHKZ8JTVzeIgnmdtA5lYx7bmKt1pviJPPbiIgzgnneW09ll5e kjfmY4d9EFoIw== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id F3AA780925; Sat, 28 Jun 2025 11:54:28 -0400 (EDT) Received: from pastel (unknown [104.247.225.139]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id B8E761202F4; Sat, 28 Jun 2025 11:54:28 -0400 (EDT) From: Stefan Monnier In-Reply-To: <878qlcorzd.fsf@yahoo.com> Message-ID: References: <86o6vatvc7.fsf@gnu.org> <864iwzre9r.fsf@gnu.org> <86ecvvj433.fsf@gnu.org> <8734bmq7y6.fsf@yahoo.com> <878qlcorzd.fsf@yahoo.com> Date: Sat, 28 Jun 2025 11:54:27 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.310 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-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) >> I wouldn't be surprised if there are other places where we presume that >> `dump-mode =3D nil` means that we won't dump (or have already dumped). > There were till I eliminated all of those I discovered which impacted > the Android port. The `dump-mode` test in `cus-start` that was present before the recent `custom-reevaluate-setting` *did* impact the Android port, but we just didn't notice because the impact was sufficiently minor. >> From this experience, I wonder if the Android port shouldn't be more "in >> your face" about the preload&dump, i.e. tell the users about it, so they >> don't get false ideas about Emacs startup being ridiculously slow, like >> I did. > Sure, although this is the first instance I've encountered of this > particular complaint. Yeah, maybe it's just me. But note that I didn't bother to complain (until just now that I finally figured what had happened), so maybe others have just been put off and moved on. >> Also, It could even exit after the dump, I think, telling the users to >> just start again (or maybe even doing the restart on its own), so it >> could use a more "normal" value of `dump-mode` which would save it from >> triggering old bugs like the one above. > Doing so would create a much more alarming surprise for users, IMHO. I think a well chosen message should avoid such alarm. E.g. Performing the 2nd part of the install (the =ABdump=BB)... Done! You can start the real Emacs now, thanks! Of course, if we can `exec` ourselves right away, we'd avoid the need to ask users to retry, but I don't know Android enough to if that can be done. > I can name no computer program in general that aborts on initial > startup, let alone an Android app... It's not common, indeed, but there are a few somewhat related precedents: - When you upgrade F-Droid from F-Droid, the application exits. Nowadays it's reasonably clean, but in the past it would appear to crash (exit abrubtly), and restarting it right away would silently fail (IIUC it would fail for the duration of the actual install of the new version, which took place invisibly, in the background). - When registering as a new user on most websites, the registration process ends by "OK, you can now try to log in". In any case, it was just a suggestion. Stefan