From debbugs-submit-bounces@debbugs.gnu.org Mon Oct 14 22:59:39 2024 Received: (at submit) by debbugs.gnu.org; 15 Oct 2024 02:59:39 +0000 Received: from localhost ([127.0.0.1]:49848 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t0Xmc-0002mH-Gq for submit@debbugs.gnu.org; Mon, 14 Oct 2024 22:59:39 -0400 Received: from lists.gnu.org ([209.51.188.17]:45352) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t0Xma-0002m0-2i for submit@debbugs.gnu.org; Mon, 14 Oct 2024 22:59: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 1t0XkC-0002sv-3a for bug-gnu-emacs@gnu.org; Mon, 14 Oct 2024 22:57:08 -0400 Received: from mail-108-mta80.mxroute.com ([136.175.108.80]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1t0XkA-00042G-2I for bug-gnu-emacs@gnu.org; Mon, 14 Oct 2024 22:57:07 -0400 Received: from filter006.mxroute.com ([136.175.111.3] filter006.mxroute.com) (Authenticated sender: mN4UYu2MZsgR) by mail-108-mta80.mxroute.com (ZoneMTA) with ESMTPSA id 1928e1b88c30003e01.001 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Tue, 15 Oct 2024 02:57:02 +0000 X-Zone-Loop: e99cee45dbb71855fef66e956cdabdfdad9a9c186339 X-Originating-IP: [136.175.111.3] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=neverwas.me ; s=x; h=Content-Type:MIME-Version:Message-ID:Date:Subject:To:From:Sender: Reply-To:Cc:Content-Transfer-Encoding:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=kx8DRQFB29lbmQU5TNtJlOGcq72kJ7h+4uO/IHD6EuM=; b=LmO2tyBZWrL5LI7cK7lVaEFlRP 3pQrOnBr8oyeBiYf0TejrE6WB4nzCduhimv1fFUqS6tHDbEaBD5RQZVljWo6+R7x33hDY6A7HtRn5 KKfEaOgex+HxJaMGPCIv7ViSC9srpiHtgTDhSfhepcbft+R7ysb27Kx53R0tvjc4AQWW6/PJMgwVV 7qvIjjimzA2IdAyOaLORk/cIGgvoWukRNP9cEPRztsKDY58cfh4P0KxRiXJGMu0AIwleNhVogCZdF XsVftxaPxRdnvQBZVuYCDH4SP+kQ9kPept01acoSGKa2XDHbuh6N1LRy5WO8twU1cXXPpucyACavv z5U2gTaQ==; From: "J.P." To: bug-gnu-emacs@gnu.org Subject: 30.0.91; ERC 5.6.0.30.1: Customizing erc-modules loads ERC when starting Emacs X-Debbugs-CC: emacs-erc@gnu.org, Eli Zaretskii Date: Mon, 14 Oct 2024 19:57:00 -0700 Message-ID: <87o73mgjk3.fsf@neverwas.me> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Authenticated-Id: masked@neverwas.me Received-SPF: pass client-ip=136.175.108.80; envelope-from=jp@neverwas.me; helo=mail-108-mta80.mxroute.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.4 (-) X-Debbugs-Envelope-To: submit 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: -2.4 (--) --=-=-= Content-Type: text/plain Tags: patch >From emacs -Q 1. $ mkdir /tmp/fake-home 2. $ echo "(custom-set-variables '(erc-modules ()))" > /tmp/fake-home/.emacs 3. $ HOME=/tmp/fake-home ./src/emacs 4. M-: (featurep 'erc) RET Eli, can we add this patch to the release branch? It removes a single line containing an autoload cookie that's new in Emacs 30. (I'm running the check-expensive suite with the patch now.) Thanks. In GNU Emacs 30.0.91 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.43, cairo version 1.18.0) of 2024-10-14 built on localhost Repository revision: b87fda63dd4a29c3c28e235904405f2d6709239e Repository branch: emacs-30 Windowing system distributor 'The X.Org Foundation', version 11.0.12401002 System Description: Fedora Linux 40 (Workstation Edition) Configured features: ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS WEBP X11 XDBE XIM XINPUT2 XPM GTK3 ZLIB Important settings: value of $LANG: en_US.UTF-8 value of $XMODIFIERS: @im=ibus 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 epa epg rfc6068 epg-config gnus-util time-date mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils compile text-property-search comint ansi-osc ansi-color ring comp-run comp-common erc derived auth-source eieio eieio-core icons password-cache json map format-spec erc-backend erc-networks easy-mmode byte-opt bytecomp byte-compile erc-common inline cl-extra help-mode erc-compat cl-seq cl-macs gv pcase rx compat subr-x cl-loaddefs cl-lib erc-loaddefs 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 lcms2 dynamic-setting system-font-setting font-render-setting cairo gtk x-toolkit xinput2 x multi-tty move-toolbar make-network-process native-compile emacs) Memory information: ((conses 16 166001 9858) (symbols 48 11695 0) (strings 32 30570 5080) (string-bytes 1 1067417) (vectors 16 19000) (vector-slots 8 192763 8903) (floats 8 35 1) (intervals 56 339 0) (buffers 984 11)) --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=0001-Don-t-autoload-erc-modules.patch >From 560390753c087a8e0dd8e6e1d2803ff8fff4cf24 Mon Sep 17 00:00:00 2001 From: "F. Jason Park" Date: Mon, 14 Oct 2024 19:32:16 -0700 Subject: [PATCH] Don't autoload erc-modules * lisp/erc/erc.el (erc-modules): Remove autoload because it caused customizations for this option to load the main library. This reverts the thrust of bb894845 "Teach customize-option about erc-modules", which was added in ERC 5.6 and Emacs 30. The motivation for the original offending change was to allow new users to run M-x customize-option RET erc-modules RET immediately after start up instead of M-x customize-group RET, followed by an I-search. --- lisp/erc/erc.el | 2 -- 1 file changed, 2 deletions(-) diff --git a/lisp/erc/erc.el b/lisp/erc/erc.el index 30641c2bd88..688d2f4b1ae 100644 --- a/lisp/erc/erc.el +++ b/lisp/erc/erc.el @@ -2263,8 +2263,6 @@ erc--sort-modules (cl-pushnew mod (if (get mod 'erc--module) built-in third-party))) `(,@(sort built-in #'string-lessp) ,@(nreverse third-party)))) -;;;###autoload(custom-autoload 'erc-modules "erc") - (defcustom erc-modules '( autojoin button completion fill imenu irccontrols list match menu move-to-prompt netsplit networks readonly ring stamp track) -- 2.46.2 --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Tue Oct 15 08:08:06 2024 Received: (at 73812) by debbugs.gnu.org; 15 Oct 2024 12:08:06 +0000 Received: from localhost ([127.0.0.1]:54353 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t0gLO-0007Q6-65 for submit@debbugs.gnu.org; Tue, 15 Oct 2024 08:08:06 -0400 Received: from eggs.gnu.org ([209.51.188.92]:60192) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t0gLM-0007PX-9e for 73812@debbugs.gnu.org; Tue, 15 Oct 2024 08:08:05 -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 1t0gKx-00011s-Gz; Tue, 15 Oct 2024 08:07:40 -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=Eaf8v18jkmz9VUQRgdkvFrMXQTM3IKQGszuUbYSQRJw=; b=ca7iBJt6JUSJ z0rBgbUaRIbRmv7mRqPmHR5bUOqDLlw/mPRcRfUG+96kKVSci48WrdoRkea6v0cI4TJ1zrhFd+A+K jR4qoA+ltnlIPAalr4OdsGyXwcKzqdM048OKth8kko9nWteGQKeMdlXYfLApBIBHrpJlnhHzZTOQV kgDOezqpjulgRe8tMkxqvzYtl7fG1Ebu16SnV0LVXYtopwsFmk6tzT2mLuLKcI1hmScULlT7ZfgPr dpflT6xrX7qWFrzD76ttCqb0ZNesA8Ch93o+vor/ZpB0KJBq7C8uzmuQ0gx+GbRTnHD12NfMbCbkK f106l1f1j2HYuwpRZDtmOw==; Date: Tue, 15 Oct 2024 15:07:36 +0300 Message-Id: <865xptsh6f.fsf@gnu.org> From: Eli Zaretskii To: "J.P." In-Reply-To: <87o73mgjk3.fsf@neverwas.me> (jp@neverwas.me) Subject: Re: bug#73812: 30.0.91; ERC 5.6.0.30.1: Customizing erc-modules loads ERC when starting Emacs References: <87o73mgjk3.fsf@neverwas.me> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 73812 Cc: 73812@debbugs.gnu.org, emacs-erc@gnu.org 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: emacs-erc@gnu.org, Eli Zaretskii > From: "J.P." > Date: Mon, 14 Oct 2024 19:57:00 -0700 > > >From emacs -Q > > 1. $ mkdir /tmp/fake-home > 2. $ echo "(custom-set-variables '(erc-modules ()))" > /tmp/fake-home/.emacs > 3. $ HOME=/tmp/fake-home ./src/emacs > 4. M-: (featurep 'erc) RET > > Eli, can we add this patch to the release branch? It removes a single > line containing an autoload cookie that's new in Emacs 30. (I'm running > the check-expensive suite with the patch now.) Thanks. Are we sure this doesn't break any customization scenarios? Why was this line added in the first place? And why is it urgent to remove it before Emacs 30 is released? From debbugs-submit-bounces@debbugs.gnu.org Tue Oct 15 14:01:07 2024 Received: (at 73812) by debbugs.gnu.org; 15 Oct 2024 18:01:08 +0000 Received: from localhost ([127.0.0.1]:57372 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t0lr1-0000Vc-ER for submit@debbugs.gnu.org; Tue, 15 Oct 2024 14:01:07 -0400 Received: from mail-108-mta126.mxroute.com ([136.175.108.126]:36907) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t0lqz-0000VT-7x for 73812@debbugs.gnu.org; Tue, 15 Oct 2024 14:01:06 -0400 Received: from filter006.mxroute.com ([136.175.111.3] filter006.mxroute.com) (Authenticated sender: mN4UYu2MZsgR) by mail-108-mta126.mxroute.com (ZoneMTA) with ESMTPSA id 1929156d8f90003e01.001 for <73812@debbugs.gnu.org> (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Tue, 15 Oct 2024 18:00:40 +0000 X-Zone-Loop: d2bb27905f0f7027253207dc6e8814c7b2ac3ffb5156 X-Originating-IP: [136.175.111.3] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=neverwas.me ; s=x; h=Content-Type:MIME-Version:Message-ID:Date:References:In-Reply-To: Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=NexnMhgVjngwCBJG2gIDCP7yJBfT2Q1/Oi+MU7mNcas=; b=YDEglR7z8nN+V3o4UluKJokyct gk6e5ksJy9SzgM4ISVYRICQyzC8FWoDVzI0H0yim4rapzTRRjS0lbWQaMdQ29EdR/iT5HgLyGf7kM m8GQ7pRFx3ovizVwNuWXUTyBizYfaQhw0m1DcGbGqM/bDvTvVRucRHemJQN9dqUByEI6Z5J+qs7p8 CoLTLLwk+NidWfy/kvPEKmD5fvOLzKzIK7abK11ELA6DWKQJfYcj/NVa5quatufN7R0bs/J4Trug2 2nyJZHu7wKmWvRN5XzmOwEGVzwYWyeqadFkJ6DZuOPL1rh5LR3mM980xcskwKZB02uO17LmYWEn5c V4IU9cxw==; From: "J.P." To: Eli Zaretskii Subject: Re: bug#73812: 30.0.91; ERC 5.6.0.30.1: Customizing erc-modules loads ERC when starting Emacs In-Reply-To: <865xptsh6f.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 15 Oct 2024 15:07:36 +0300") References: <87o73mgjk3.fsf@neverwas.me> <865xptsh6f.fsf@gnu.org> Date: Tue, 15 Oct 2024 11:00:38 -0700 Message-ID: <87h69ddz5l.fsf@neverwas.me> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Authenticated-Id: masked@neverwas.me X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 73812 Cc: 73812@debbugs.gnu.org, emacs-erc@gnu.org 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: >> Cc: emacs-erc@gnu.org, Eli Zaretskii >> From: "J.P." >> Date: Mon, 14 Oct 2024 19:57:00 -0700 >> >> >From emacs -Q >> >> 1. $ mkdir /tmp/fake-home >> 2. $ echo "(custom-set-variables '(erc-modules ()))" > /tmp/fake-home/.emacs >> 3. $ HOME=/tmp/fake-home ./src/emacs >> 4. M-: (featurep 'erc) RET >> >> Eli, can we add this patch to the release branch? It removes a single >> line containing an autoload cookie that's new in Emacs 30. (I'm running >> the check-expensive suite with the patch now.) Thanks. > > Are we sure this doesn't break any customization scenarios? The worst case is probably someone unaware of the implicit loading who recently added code referring to symbols defined in erc.el after an Emacs-managed `custom-set-variables' form in their `custom-file' (or a `:custom' section in a `use-package' declaration). These customizations would necessarily have to contain an entry for `erc-modules', but this is perhaps the most common ERC customization. However, the user would have to be running the pre-release or master. > Why was this line added in the first place? The line was initially added in a misguided attempt to allow new users unfamiliar with Emacs to run M-x customize-option RET erc-modules RET without first having to run M-: (require 'erc) RET. > And why is it urgent to remove it before Emacs 30 is released? ERC has a great many symbols, which people won't want to see in completion tables, etc. Longtime ERC users trying Emacs 30 for the first time may find ERC loading whenever they start Emacs, which may not be desirable in all Emacs sessions. And since, as mentioned, `erc-modules' is likely among the most commonly customized of ERC's options, this may also affect non-ERC users who perhaps only tried it once many years ago or even folks using a shared config containing such a customization. For these reasons, I suspect we'll start noticing ERC-related pollution in the automated evidence collection for bug reports filed with M-x report-emacs-bug RET once Emacs 30 goes mainstream. From debbugs-submit-bounces@debbugs.gnu.org Thu Oct 17 15:38:39 2024 Received: (at 73812) by debbugs.gnu.org; 17 Oct 2024 19:38:39 +0000 Received: from localhost ([127.0.0.1]:35734 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t1WKU-0000OR-Pk for submit@debbugs.gnu.org; Thu, 17 Oct 2024 15:38:39 -0400 Received: from mail-108-mta100.mxroute.com ([136.175.108.100]:43715) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t1WKR-0000OF-GB for 73812@debbugs.gnu.org; Thu, 17 Oct 2024 15:38:37 -0400 Received: from filter006.mxroute.com ([136.175.111.3] filter006.mxroute.com) (Authenticated sender: mN4UYu2MZsgR) by mail-108-mta100.mxroute.com (ZoneMTA) with ESMTPSA id 1929bfcc9f40003e01.001 for <73812@debbugs.gnu.org> (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Thu, 17 Oct 2024 19:38:08 +0000 X-Zone-Loop: dd19a091ebb39addd541d9936953fa0c6ad6bb4913b1 X-Originating-IP: [136.175.111.3] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=neverwas.me ; s=x; h=Content-Type:MIME-Version:Message-ID:Date:References:In-Reply-To: Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=uwSpgjA1WDIYrzoUZbDTPJ9FOiazuJVOTvQddiSvkTU=; b=YEyRlt40oAThK6S0rUm/d6wYUc JfZv1+USIAZAFaYx7DlL9Wltn1cA4IRBn8aIxMYhaAa+nPoGjSWDnfMxv30+CJ7EvOfd2iMKiHukH B1ibASn1ifKBhTFZBF6eYWYZI4jIakLiI0zERcvDMSvzY0ISZ8w813oyuhSbSKi9oz2XXnuBuDsRw x6eKpnS1XM4WqltYJKQAH8HzKG9K17v970vCarid/qkg0iIMjaGgRkjInVLX7XnEFIo38DqIOl60E nN1KxJraEtOse4FMHQJeqc3Q3nsVyvQdKH4HOwrAK+tQ/9SOq4UL5M/3QZvKNrX+xWuzO45FTmo8R 2c+zWYLg==; From: "J.P." To: Eli Zaretskii Subject: Re: bug#73812: 30.0.91; ERC 5.6.0.30.1: Customizing erc-modules loads ERC when starting Emacs In-Reply-To: <87h69ddz5l.fsf@neverwas.me> (J. P.'s message of "Tue, 15 Oct 2024 11:00:38 -0700") References: <87o73mgjk3.fsf@neverwas.me> <865xptsh6f.fsf@gnu.org> <87h69ddz5l.fsf@neverwas.me> Date: Thu, 17 Oct 2024 12:38:05 -0700 Message-ID: <87zfn28qqq.fsf@neverwas.me> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Authenticated-Id: masked@neverwas.me X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 73812 Cc: 73812@debbugs.gnu.org, emacs-erc@gnu.org 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 (-) "J.P." writes: >>> Eli, can we add this patch to the release branch? It removes a single >>> line containing an autoload cookie that's new in Emacs 30. (I'm running >>> the check-expensive suite with the patch now.) Thanks. >> >> Are we sure this doesn't break any customization scenarios? > > The worst case is probably someone unaware of the implicit loading who > recently added code referring to symbols defined in erc.el after an > Emacs-managed `custom-set-variables' form in their `custom-file' (or a > `:custom' section in a `use-package' declaration). These customizations > would necessarily have to contain an entry for `erc-modules', but this > is perhaps the most common ERC customization. However, the user would > have to be running the pre-release or master. > >> Why was this line added in the first place? > > The line was initially added in a misguided attempt to allow new users > unfamiliar with Emacs to run M-x customize-option RET erc-modules RET > without first having to run M-: (require 'erc) RET. > >> And why is it urgent to remove it before Emacs 30 is released? > > ERC has a great many symbols, which people won't want to see in > completion tables, etc. Longtime ERC users trying Emacs 30 for the first > time may find ERC loading whenever they start Emacs, which may not be > desirable in all Emacs sessions. And since, as mentioned, `erc-modules' > is likely among the most commonly customized of ERC's options, this may > also affect non-ERC users who perhaps only tried it once many years ago > or even folks using a shared config containing such a customization. For > these reasons, I suspect we'll start noticing ERC-related pollution in > the automated evidence collection for bug reports filed with M-x > report-emacs-bug RET once Emacs 30 goes mainstream. While we await a ruling on this... Here's an example of how `erc-modules' customizations inadvertently creep into a person's `custom-file' (for any curious future victims of this bug). >From emacs -Q (using Emacs 27 as an example): 0. Connect to a server 1. M-x customize-group RET erc RET 2. Twirl open the "Erc Modules" section 3. In an ERC buffer: M-x erc-scrolltobottom-mode RET 4. In the Custom buffer, edit an option, like "Erc Email Userid" 5. C-x C-s 6. Notice that your `custom-file' now contains an entry for `erc-modules' Among those who've ever done the above or similar, only the lucky few to have since cleaned up their `custom-file' will be spared ERC invasively loading when next they fire up Emacs 30. As may be obvious, ERC is guilty of the familiar anti-pattern of mutating user options silently behind the scenes. For reasons of compatibility, we've put off addressing this until a major release. FWIW, new modules following the recommended practice of declaring themselves `local' do not exhibit this malignant behavior. From debbugs-submit-bounces@debbugs.gnu.org Fri Oct 18 03:15:15 2024 Received: (at 73812) by debbugs.gnu.org; 18 Oct 2024 07:15:15 +0000 Received: from localhost ([127.0.0.1]:36843 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t1hCd-0007Q9-4w for submit@debbugs.gnu.org; Fri, 18 Oct 2024 03:15:15 -0400 Received: from eggs.gnu.org ([209.51.188.92]:37084) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t1hCb-0007Px-M6 for 73812@debbugs.gnu.org; Fri, 18 Oct 2024 03:15:14 -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 1t1hCA-0001rb-5G; Fri, 18 Oct 2024 03:14:46 -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=QHdMGpQ+wF324UfhF1Ybq5MHGrpAE9hQobyU2EeXiNM=; b=ANu/F4NcY3VQ j13F/7JSetnE6mkjWTLKtvnZXIl5CY32n8GNr6nu/so2SiPKdJmTfowxcPFUnay1Ny2lWt2tl7h1v yWnSE8QCAneAgneOHedGnhjGPD2/ys37nrG1tchI85CHM04zjJItQLl0bKSOmSJADwm+tVLkKQv7k Xqv6eXcEbgSbsOKVpS2jW/SyDN6xbplzQ55dTTbyZ++A2xpYI8X316xrEBFEGW0G6O2F8XsssQzPF zAiyLUzNIhH5jtr8htQcGpnq8SSYq8fLza7WxhpkXGh590QwZFvQXVR3IzT18Elw9q3Q7Vf3ARWjJ Q7QX+KUmkeFyBDSEgYTDPg==; Date: Fri, 18 Oct 2024 10:14:44 +0300 Message-Id: <86bjzhopaz.fsf@gnu.org> From: Eli Zaretskii To: "J.P." In-Reply-To: <87h69ddz5l.fsf@neverwas.me> (jp@neverwas.me) Subject: Re: bug#73812: 30.0.91; ERC 5.6.0.30.1: Customizing erc-modules loads ERC when starting Emacs References: <87o73mgjk3.fsf@neverwas.me> <865xptsh6f.fsf@gnu.org> <87h69ddz5l.fsf@neverwas.me> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 73812 Cc: 73812@debbugs.gnu.org, emacs-erc@gnu.org 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: "J.P." > Cc: 73812@debbugs.gnu.org, emacs-erc@gnu.org > Date: Tue, 15 Oct 2024 11:00:38 -0700 > > Eli Zaretskii writes: > > > Are we sure this doesn't break any customization scenarios? > > The worst case is probably someone unaware of the implicit loading who > recently added code referring to symbols defined in erc.el after an > Emacs-managed `custom-set-variables' form in their `custom-file' (or a > `:custom' section in a `use-package' declaration). These customizations > would necessarily have to contain an entry for `erc-modules', but this > is perhaps the most common ERC customization. However, the user would > have to be running the pre-release or master. > > > Why was this line added in the first place? > > The line was initially added in a misguided attempt to allow new users > unfamiliar with Emacs to run M-x customize-option RET erc-modules RET > without first having to run M-: (require 'erc) RET. The commit log message says: * lisp/erc/erc.el (erc-modules): Make good on decades old language in info node "(erc) Modules" by ensuring `customize-option' can find this option before its containing library is loaded. Like `gnus-select-method', this option serves as an entry point for configuring the application and is presented that way in tutorials and library front matter. Moreover, it can't be reasonably autoloaded in the traditional way because of its many dependencies and large textual footprint. So there was some reasonable rationale to this change. > > And why is it urgent to remove it before Emacs 30 is released? > > ERC has a great many symbols, which people won't want to see in > completion tables, etc. Longtime ERC users trying Emacs 30 for the first > time may find ERC loading whenever they start Emacs, which may not be > desirable in all Emacs sessions. And since, as mentioned, `erc-modules' > is likely among the most commonly customized of ERC's options, this may > also affect non-ERC users who perhaps only tried it once many years ago > or even folks using a shared config containing such a customization. For > these reasons, I suspect we'll start noticing ERC-related pollution in > the automated evidence collection for bug reports filed with M-x > report-emacs-bug RET once Emacs 30 goes mainstream. All in all, I'd prefer to leave this alone in Emacs 30. We have time to try reverting this on master and seeing whether it's a net win or a net loss, given the past history of the issue. (AFAIU, if you remove this line, some change is pertinent in the manual?) Thanks. From debbugs-submit-bounces@debbugs.gnu.org Fri Oct 18 13:55:41 2024 Received: (at 73812) by debbugs.gnu.org; 18 Oct 2024 17:55:41 +0000 Received: from localhost ([127.0.0.1]:39977 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t1rCP-0003mN-3Z for submit@debbugs.gnu.org; Fri, 18 Oct 2024 13:55:41 -0400 Received: from mail-108-mta120.mxroute.com ([136.175.108.120]:40911) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t1rCM-0003mE-HK for 73812@debbugs.gnu.org; Fri, 18 Oct 2024 13:55:39 -0400 Received: from filter006.mxroute.com ([136.175.111.3] filter006.mxroute.com) (Authenticated sender: mN4UYu2MZsgR) by mail-108-mta120.mxroute.com (ZoneMTA) with ESMTPSA id 192a0c4e4770003e01.001 for <73812@debbugs.gnu.org> (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Fri, 18 Oct 2024 17:55:11 +0000 X-Zone-Loop: d96e00f65394939c14e7411196d6ab4a1aa6833c7bd2 X-Originating-IP: [136.175.111.3] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=neverwas.me ; s=x; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date: References:In-Reply-To:Subject:Cc:To:From:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=FYo6fp4hMBxdRd/IjEGXqsdvRp6EdK/W8xLCZSkbcQo=; b=eV1rhdHEBtzFawFUOWu3Xd2u41 zJBTJqT4ImME60sfdwmb/flOjPqozJ1AYIMyOOglXbZxC6VDVERyU97+XtTSY9ECOESyKns265OlP nLLf2g2OdyVCFdU8G5hHkUyD92Xb6DrTBkrnnP7b5vq+HvOhwDeq7UroFPTeeQvAJOZVpzJsAwqRA bq8pv7Z7TBTy0ifXUzFG3R0sZ3xLVPLfgudpziMoDouqUEZGHAadY4r7S2FXFD29zdEmIr4UjhbQB GAYu6AmV2Woq8uP+8lxlPaevqK46i9MJv91iy+fayFVqCW2tYlsWXB2d06idPf4PXQMQOu9huLUIG AiEsLDGw==; From: "J.P." To: Eli Zaretskii Subject: Re: bug#73812: 30.0.91; ERC 5.6.0.30.1: Customizing erc-modules loads ERC when starting Emacs In-Reply-To: <86bjzhopaz.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 18 Oct 2024 10:14:44 +0300") References: <87o73mgjk3.fsf@neverwas.me> <865xptsh6f.fsf@gnu.org> <87h69ddz5l.fsf@neverwas.me> <86bjzhopaz.fsf@gnu.org> Date: Fri, 18 Oct 2024 10:55:07 -0700 Message-ID: <87ttd947pg.fsf@neverwas.me> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Authenticated-Id: masked@neverwas.me X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 73812 Cc: 73812@debbugs.gnu.org, emacs-erc@gnu.org 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: >> > Why was this line added in the first place? >>=20 >> The line was initially added in a misguided attempt to allow new users >> unfamiliar with Emacs to run M-x customize-option RET erc-modules RET >> without first having to run M-: (require 'erc) RET. > > The commit log message says: > > * lisp/erc/erc.el (erc-modules): Make good on decades old language in > info node "(erc) Modules" by ensuring `customize-option' can find this > option before its containing library is loaded. Like > `gnus-select-method', this option serves as an entry point for > configuring the application and is presented that way in tutorials and > library front matter. Moreover, it can't be reasonably autoloaded in > the traditional way because of its many dependencies and large textual > footprint. > > So there was some reasonable rationale to this change. What the commit message doesn't mention is that its author (me) was ignorant of the fact that customizing the option and saving it would result in ERC being loaded unconditionally on startup rather than only when summoned. > >> > And why is it urgent to remove it before Emacs 30 is released? >>=20 >> ERC has a great many symbols, which people won't want to see in >> completion tables, etc. Longtime ERC users trying Emacs 30 for the first >> time may find ERC loading whenever they start Emacs, which may not be >> desirable in all Emacs sessions. And since, as mentioned, `erc-modules' >> is likely among the most commonly customized of ERC's options, this may >> also affect non-ERC users who perhaps only tried it once many years ago >> or even folks using a shared config containing such a customization. For >> these reasons, I suspect we'll start noticing ERC-related pollution in >> the automated evidence collection for bug reports filed with M-x >> report-emacs-bug RET once Emacs 30 goes mainstream. > > All in all, I'd prefer to leave this alone in Emacs 30. We have time > to try reverting this on master and seeing whether it's a net win or a > net loss, given the past history of the issue. (AFAIU, if you remove > this line, some change is pertinent in the manual?) The manual currently says: 4 Modules ********* =20=20 One way to add functionality to ERC is to customize which of its many modules are loaded. =20=20 There is a spiffy customize interface, which may be reached by typing =E2=80=98M-x customize-option erc-modules =E2=80=99. We could instead say something like: The main way to impact ERC's functionality is by choosing which modules it loads. Do this by typing =E2=80=98C-h v erc-modules RET=E2=80= =99 to view that option's help buffer, then click =E2=80=98customize=E2=80=99 near th= e bottom, where it says "You can _customize_ this variable." (This assumes anyone needing detailed instructions hasn't disabled `help-enable-completion-autoload'.) In any case, I don't anticipate much blowback beyond the complaints we used to get re "it says [no match]", etc. But I will make the change on master for now, as suggested. Thanks. From debbugs-submit-bounces@debbugs.gnu.org Mon Oct 28 23:16:48 2024 Received: (at 73812) by debbugs.gnu.org; 29 Oct 2024 03:16:48 +0000 Received: from localhost ([127.0.0.1]:55408 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t5ciu-0004jm-8O for submit@debbugs.gnu.org; Mon, 28 Oct 2024 23:16:48 -0400 Received: from mail-108-mta227.mxroute.com ([136.175.108.227]:36243) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t5cir-0004jb-Kz for 73812@debbugs.gnu.org; Mon, 28 Oct 2024 23:16:46 -0400 Received: from filter006.mxroute.com ([136.175.111.3] filter006.mxroute.com) (Authenticated sender: mN4UYu2MZsgR) by mail-108-mta227.mxroute.com (ZoneMTA) with ESMTPSA id 192d6469c390003e01.001 for <73812@debbugs.gnu.org> (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Tue, 29 Oct 2024 03:16:44 +0000 X-Zone-Loop: 5d7683c736da13eff4d70a3daf504176e55d015c149a X-Originating-IP: [136.175.111.3] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=neverwas.me ; s=x; h=Content-Type:MIME-Version:Message-ID:Date:References:In-Reply-To: Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=wbyPbKIbCYwAEoWlnhcVj+MlZPFFhVzi7TjYt6WwoTs=; b=Pj6G+MGb/EyNVs+qPV3IO1e9xT BKi2r7FDz0aNYFmmWWvWaq/8ZQOd3+kW111poLKuIvH79eAcxfXRuIIjP33uU45UXhKQ+WKdygNWD 0dAn+TSMk3xkDBVR2g8jLxmDk+/jka1VAhKdOGgpubRvz0ynhHPuFsz0dkn5Ar4ZTQUZeeltjcntB Gm9LmV7HFoTS+EfGbZ8jGMrIOiFvxF9Dkr1j0XDiBIZt1q6OReucWD2TF8AmrHqPuRv6Z9EWT9UDn SB00gbEj1ZsmPrj4Mgq/QkweCqE4tqpCoqehlIwKddbJwEKOQE0bjlrKFWG6pY4C/m+C/UQZkTwQc ufPHkKYA==; From: "J.P." To: Eli Zaretskii Subject: Re: bug#73812: 30.0.91; ERC 5.6.0.30.1: Customizing erc-modules loads ERC when starting Emacs In-Reply-To: <87ttd947pg.fsf@neverwas.me> (J. P.'s message of "Fri, 18 Oct 2024 10:55:07 -0700") References: <87o73mgjk3.fsf@neverwas.me> <865xptsh6f.fsf@gnu.org> <87h69ddz5l.fsf@neverwas.me> <86bjzhopaz.fsf@gnu.org> <87ttd947pg.fsf@neverwas.me> Date: Mon, 28 Oct 2024 20:16:42 -0700 Message-ID: <87ed3z1tut.fsf@neverwas.me> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Authenticated-Id: masked@neverwas.me X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 73812 Cc: 73812@debbugs.gnu.org, emacs-erc@gnu.org 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 (-) "J.P." writes: >> All in all, I'd prefer to leave this alone in Emacs 30. We have time >> to try reverting this on master and seeing whether it's a net win or a >> net loss, given the past history of the issue. (AFAIU, if you remove >> this line, some change is pertinent in the manual?) It's been reverted on master for ten days now with no complaints: https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=1854f275 If that's long enough to qualify as a net win, can we proceed with a backport? From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 01 20:49:57 2024 Received: (at 73812) by debbugs.gnu.org; 2 Nov 2024 00:49:58 +0000 Received: from localhost ([127.0.0.1]:52536 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t72Kz-0004xH-E9 for submit@debbugs.gnu.org; Fri, 01 Nov 2024 20:49:57 -0400 Received: from mail-108-mta19.mxroute.com ([136.175.108.19]:34369) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t72Ks-0004x2-Ih for 73812@debbugs.gnu.org; Fri, 01 Nov 2024 20:49:55 -0400 Received: from filter006.mxroute.com ([136.175.111.3] filter006.mxroute.com) (Authenticated sender: mN4UYu2MZsgR) by mail-108-mta19.mxroute.com (ZoneMTA) with ESMTPSA id 192ea59845e0003e01.001 for <73812@debbugs.gnu.org> (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Sat, 02 Nov 2024 00:49:48 +0000 X-Zone-Loop: a480b7b971bb07e974733aa260a43e3a8c00a8376be2 X-Originating-IP: [136.175.111.3] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=neverwas.me ; s=x; h=Content-Type:MIME-Version:Message-ID:Date:References:In-Reply-To: Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=RyfDnD1HOYfmBmNBi+chJZf5wCgUUYdCfqEtRrAHCbQ=; b=Tk3gGGD6GIWNrteS9IEpVDUhsM SzscLx9kGvWnwNcwLRN2J8HtBXdV0kShaeYe9HOOva9M/mSp8H9gPrKWVQuBM4WLKwyEOWWG6CPu2 rh2I1c3B5Ylr2d7u2CdgN11CvlP6GshJYvfyUCq4+OMTerpAlFYHK8hSRajIyjWT2esK4VZn/lPpM 9xurk4y5wCvBv8pzlZUBFyvg62zA0IGFA+QaLuZx8DLieEObhtrp7oy81fsIUj0YLzeCfvfnMRvvw mWvEX0RMji6dlAtsW4iIc9nvE6cD4tp6r1gLGrdTTIPy025vi8k6lPiA7P0ycVj5bFEXbyIxgNSNp WAg4OBuQ==; From: "J.P." To: Stefan Kangas , Andrea Corallo Subject: Re: bug#73812: 30.0.91; ERC 5.6.0.30.1: Customizing erc-modules loads ERC when starting Emacs In-Reply-To: <87ed3z1tut.fsf@neverwas.me> (J. P.'s message of "Mon, 28 Oct 2024 20:16:42 -0700") References: <87o73mgjk3.fsf@neverwas.me> <865xptsh6f.fsf@gnu.org> <87h69ddz5l.fsf@neverwas.me> <86bjzhopaz.fsf@gnu.org> <87ttd947pg.fsf@neverwas.me> <87ed3z1tut.fsf@neverwas.me> Date: Fri, 01 Nov 2024 17:49:43 -0700 Message-ID: <87cyjepihk.fsf@neverwas.me> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Authenticated-Id: masked@neverwas.me X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 73812 Cc: 73812@debbugs.gnu.org, Eli Zaretskii , emacs-erc@gnu.org 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 (-) Dear auxiliary maintainers, It seems Eli has tired of my nagging or is otherwise indisposed when it comes to this issue. To summarize: - Due to my own stupidity, the version of ERC in Emacs 30 autoloads the option `erc-modules', which is the most important of ERC's options and among the first that users typically customize. - Because of this change, the very presence of `erc-modules' in one's `custom-file' now loads all of ERC at startup, including any library housing a member module, be it built-in or third-party. - Users who no longer use ERC but still have a customization entry lying around will also be affected. Likewise for users who prefer running multiple Emacs instances to segregate concerns. - This issue won't be solvable by installing ERC 5.6.1 from ELPA, where the problematic line will have been removed, because the autoload is permanently baked into lisp/ldefs-boot.el. - The problematic change will be new in Emacs 30.1. "J.P." writes: > Eli Zaretskii writes: > >>> All in all, I'd prefer to leave this alone in Emacs 30. We have time >>> to try reverting this on master and seeing whether it's a net win or a >>> net loss, given the past history of the issue. (AFAIU, if you remove >>> this line, some change is pertinent in the manual?) > > It's been reverted on master for ten days now with no complaints: > > https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=1854f275 > > If that's long enough to qualify as a net win, can we proceed with a > backport? It's been two weeks now since I was tasked with reverting this on master in order to assess the damage, of which none has since been reported. Apologies if I'm out of line in pressing the issue, but I'm driven by a need to advocate for ERC's users, who've suffered greatly in the past due to my cowardliness in similar situations [1]. As such, I would very much appreciate a final verdict on this matter. Thanks, J.P. [1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=62833#14 From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 01 22:06:26 2024 Received: (at 73812) by debbugs.gnu.org; 2 Nov 2024 02:06:26 +0000 Received: from localhost ([127.0.0.1]:52609 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t73Wz-0007O3-Io for submit@debbugs.gnu.org; Fri, 01 Nov 2024 22:06:25 -0400 Received: from mail-ej1-f42.google.com ([209.85.218.42]:55417) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t73Wx-0007Nv-4R for 73812@debbugs.gnu.org; Fri, 01 Nov 2024 22:06:24 -0400 Received: by mail-ej1-f42.google.com with SMTP id a640c23a62f3a-a9a628b68a7so363995566b.2 for <73812@debbugs.gnu.org>; Fri, 01 Nov 2024 19:06:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1730513117; x=1731117917; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:mime-version:references:in-reply-to :from:from:to:cc:subject:date:message-id:reply-to; bh=j+nvm37j50WLre/Ri3D6EUbFzqtFcBD0sH3hpn86l58=; b=PY6zMmd/ZRSKV78zm9LSLOsijB8cv+bP7UZzM4kavkTbVLXQPDCnqjCDnTMyieFNB2 IdNAvuHxMO9lsu67R6wgpHJ7V9oKD7OH38pWXXMiqnAYAW3Klq2nwAFdiku0WG1vEdjf FXPgQ4Zf2wdT/osVG33BD6+IMZj8RdDajq7IDIznsDfw+ZVEpMh+CZTuKhNFsVDUqTUN 1R/Y755aWBG54XHnx2bAQ7+b+Gji1Aqma6IkfOeJ8sANRUqk6V0BxGtAr+1gCLhrKWDL JizoZmv0jPLqdT2Ke+W7AYuOvFgBGHtiEoIBHXxcd1ueDPGF13QDfUzJNbzV3SNwPtIk lIAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1730513117; x=1731117917; h=cc:to:subject:message-id:date:mime-version:references:in-reply-to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=j+nvm37j50WLre/Ri3D6EUbFzqtFcBD0sH3hpn86l58=; b=kejQk42xh2SBkpquiGLtWThq4eXxWIbXKPnydVz0mF/Wp6+xnrArMiQG1rz8U6K+R/ O5Rcz8M4qrZlMxb45D9AGFeQnzKtBiV/MwTpab508DHraaEnzutyxUBgaj3eNv54yL/q A4BUzycDfgvvMAuIPZniJyuE1giuyKUsSPz2GKDCt7kl1seOvZWQT6le+kUNugp9RkZC h69/3ZGKQVH4yhiWuBYyqOwOxhVLtsoobMPu5kshZUVz4t616CljpuUWVkKhjUZEN0ck atM7OunGZS+tA3SfwygZpW0v6Rck0hKq8jDcnJDvR8/0NGonAj8B60H+r9vLQcf0zxQQ oIeA== X-Gm-Message-State: AOJu0YxamHbSfVctrhTjz5OHXdcfdg64hOO0JT3YRqI3UeZNm0XGQzvq 8uuRpBjFAoD/bzFGkE//L9J6IS4S+Qw2Gy2ii1S0e0sNsDAUhtOBZA6qyVa8t1Ee2Eiod76Uqo3 98y96POmFXowUgJ3Ll2rWZpkMeVc= X-Google-Smtp-Source: AGHT+IGNQljtA+2qHNRBOO5ghCNN8oRKoTM+Xa1IhbqoaIhIn/v0nR4/KQy0Ym1YL3sg/tGTkovD3nAKqYx3iYir2E0= X-Received: by 2002:a17:907:1c02:b0:a99:ef5d:443e with SMTP id a640c23a62f3a-a9e6548f7e4mr504477466b.13.1730513116913; Fri, 01 Nov 2024 19:05:16 -0700 (PDT) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Fri, 1 Nov 2024 19:05:16 -0700 From: Stefan Kangas In-Reply-To: <87cyjepihk.fsf@neverwas.me> References: <87o73mgjk3.fsf@neverwas.me> <865xptsh6f.fsf@gnu.org> <87h69ddz5l.fsf@neverwas.me> <86bjzhopaz.fsf@gnu.org> <87ttd947pg.fsf@neverwas.me> <87ed3z1tut.fsf@neverwas.me> <87cyjepihk.fsf@neverwas.me> MIME-Version: 1.0 Date: Fri, 1 Nov 2024 19:05:16 -0700 Message-ID: Subject: Re: bug#73812: 30.0.91; ERC 5.6.0.30.1: Customizing erc-modules loads ERC when starting Emacs To: "J.P." , Andrea Corallo Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 73812 Cc: 73812@debbugs.gnu.org, Eli Zaretskii , emacs-erc@gnu.org 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 (-) "J.P." writes: > - Due to my own stupidity, the version of ERC in Emacs 30 autoloads the > option `erc-modules', which is the most important of ERC's options and > among the first that users typically customize. > > - Because of this change, the very presence of `erc-modules' in one's > `custom-file' now loads all of ERC at startup, including any library > housing a member module, be it built-in or third-party. > > - Users who no longer use ERC but still have a customization entry lying > around will also be affected. Likewise for users who prefer running > multiple Emacs instances to segregate concerns. > > - This issue won't be solvable by installing ERC 5.6.1 from ELPA, where > the problematic line will have been removed, because the autoload is > permanently baked into lisp/ldefs-boot.el. > > - The problematic change will be new in Emacs 30.1. This does not sound ideal, indeed. I can only add that some of our users are very concerned with Emacs's startup time, and spend a lot of time optimizing it. Unexpectedly pulling in all of ERC in some cases certainly won't help them. > "J.P." writes: > >> Eli Zaretskii writes: >> >>>> All in all, I'd prefer to leave this alone in Emacs 30. We have time >>>> to try reverting this on master and seeing whether it's a net win or a >>>> net loss, given the past history of the issue. (AFAIU, if you remove >>>> this line, some change is pertinent in the manual?) >> >> It's been reverted on master for ten days now with no complaints: >> >> https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=1854f275 >> >> If that's long enough to qualify as a net win, can we proceed with a >> backport? > > It's been two weeks now since I was tasked with reverting this on master > in order to assess the damage, of which none has since been reported. > > Apologies if I'm out of line in pressing the issue, but I'm driven by a > need to advocate for ERC's users, who've suffered greatly in the past > due to my cowardliness in similar situations [1]. As such, I would very > much appreciate a final verdict on this matter. I assume that we are talking about cherry-picking commit 1854f2751e3f to the emacs-30 branch. Can removing the autoload cookie cause an issue outside of ERC, or for non-users of ERC? If it cannot, I don't know that I'm in a better position than you, being the ERC maintainer, to determine what kind of negative impact removing it might have. If anything, it sounds like it is more risky for non-users of ERC to leave things as is? In summary, my view is that removing it should be low risk, and it fixes a known bug. It's arguably minor, but does affect startup performance. So I think it sounds good to have the patch on emacs-30. Let's see if Eli or Andrea has anything to add here first, though. From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 01 22:37:25 2024 Received: (at 73812) by debbugs.gnu.org; 2 Nov 2024 02:37:26 +0000 Received: from localhost ([127.0.0.1]:52659 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t740z-0008L6-Dz for submit@debbugs.gnu.org; Fri, 01 Nov 2024 22:37:25 -0400 Received: from mail-oo1-f44.google.com ([209.85.161.44]:41117) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t740w-0008Ky-MY for 73812@debbugs.gnu.org; Fri, 01 Nov 2024 22:37:23 -0400 Received: by mail-oo1-f44.google.com with SMTP id 006d021491bc7-5ebbf8a7d0dso54684eaf.0 for <73812@debbugs.gnu.org>; Fri, 01 Nov 2024 19:37:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1730515037; x=1731119837; 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=iV45H4fMlnqDNyQslzjs2kisy2wu8RuOJvvwWLin26E=; b=Xo5EzAYxcJrOGdXMa/YAaXaLVrFLnXXMWhpgQP1ddyspnXxi/qG3GrI0IL4Zu0v55J Bl/xxiIDfGKAD6+Ejd3XszdY5dQCR1YsJngmfQFH264wTYeEFiYXsqe+3TlTSG/bbeMQ GUQTDaSLpLVKudgeT+vArPBuiXpZ4+mHiY8uoq0CDm9rc+gfEQHe3XDophxzBrCs6CoY gIwSdj6G8Vt4tahhB//pSSdVSpRnFJ0YFHihWamLQZ4JPfxeV/MKVLeZ4D7IsMXw3EDN ntuV8flrvwRCWUkAC2znwsta5JcITtBNBlfvcLfBzQXZWjdw/Bi9dT8BV9aFYJmYLKYN ePig== X-Forwarded-Encrypted: i=1; AJvYcCVV/jpq9wtjfIYGjE3UP26R8h+SoefkW3gus3p6h6L7EZKmw9TZCwsKh5FFEKVLL2kHBJ4eAQ==@debbugs.gnu.org X-Gm-Message-State: AOJu0YzWwEl+8Xl2aa0540xnD9I2Qwrh5vaxlVOIq1ZfR3ApUe8/6hQE +V2IwpKl4lzsmkoWiVqBE2KmdU0SEHDZnD450bzDOn1YkrJI8nf5D6rvx24DRggO2TZdcilonkq R2F/6cvgC5z6IFYxEnclQsdE830I= X-Google-Smtp-Source: AGHT+IHoCvqzJmRcEFYl2ny68hS07hqnefuPe82fl1OCrRsuqzkVoZznPB+0+plR0nqV9TxIE6jBQyDRqmJEvgp5YR0= X-Received: by 2002:a05:6830:43a6:b0:717:f7b9:e22b with SMTP id 46e09a7af769-718682b09f5mr7950519a34.7.1730515036897; Fri, 01 Nov 2024 19:37:16 -0700 (PDT) MIME-Version: 1.0 References: <87o73mgjk3.fsf@neverwas.me> <865xptsh6f.fsf@gnu.org> <87h69ddz5l.fsf@neverwas.me> <86bjzhopaz.fsf@gnu.org> <87ttd947pg.fsf@neverwas.me> <87ed3z1tut.fsf@neverwas.me> <87cyjepihk.fsf@neverwas.me> In-Reply-To: From: Corwin Brust Date: Fri, 1 Nov 2024 21:37:06 -0500 Message-ID: Subject: Re: bug#73812: 30.0.91; ERC 5.6.0.30.1: Customizing erc-modules loads ERC when starting Emacs To: Stefan Kangas Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 73812 Cc: 73812@debbugs.gnu.org, Eli Zaretskii , Andrea Corallo , emacs-erc@gnu.org, "J.P." 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.7 (/) Hi All, On Fri, Nov 1, 2024 at 9:05=E2=80=AFPM Stefan Kangas wrote: > > "J.P." writes: > > I can only add that some of our users are very concerned with Emacs's > startup time, and spend a lot of time optimizing it. Unexpectedly > pulling in all of ERC in some cases certainly won't help them. > > > "J.P." writes: > > > >> Eli Zaretskii writes: > >> > >>>> All in all, I'd prefer to leave this alone in Emacs 30. We have tim= e > >>>> to try reverting this on master and seeing whether it's a net win or= a > >>>> net loss, given the past history of the issue. (AFAIU, if you remov= e > >>>> this line, some change is pertinent in the manual?) > >> > >> It's been reverted on master for ten days now with no complaints: > >> > >> https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=3D1854f275 > >> > >> If that's long enough to qualify as a net win, can we proceed with a > >> backport? > > > > It's been two weeks now since I was tasked with reverting this on maste= r > > in order to assess the damage, of which none has since been reported. > > > > Apologies if I'm out of line in pressing the issue, but I'm driven by a > > need to advocate for ERC's users, who've suffered greatly in the past > > due to my cowardliness in similar situations [1]. As such, I would very > > much appreciate a final verdict on this matter. > > I assume that we are talking about cherry-picking commit 1854f2751e3f to > the emacs-30 branch. > > Can removing the autoload cookie cause an issue outside of ERC, or for > non-users of ERC? If it cannot, I don't know that I'm in a better > position than you, being the ERC maintainer, to determine what kind of > negative impact removing it might have. If anything, it sounds like it > is more risky for non-users of ERC to leave things as is? > > In summary, my view is that removing it should be low risk, and it fixes > a known bug. It's arguably minor, but does affect startup performance. > So I think it sounds good to have the patch on emacs-30. > > Let's see if Eli or Andrea has anything to add here first, though. > Thank you JP and Stefan for diligence on this. I had flagged this for a reply but did not manage to make one before now. (Two weeks already? Good grief.) Perhaps importantly: I strongly suspect this bug is responsible for corruption of my customize file. (Unfortunately I had a bunch of stuff in there and wasn't good and pushed my changes to that particular file to the repo where I version my config, so I've lost a bit of work. On the plus side: it's generally of a cosmetic nature, mostly face tweaks which I found it convenient to "try out" using customize and then, because they were good, never got around to encoding into proper elisp.) I didn't/haven't completed any sort of minimal reproducer: I could be completely wrong that this bug is what caused my configuration settings to get blown away. But the timing is right. I will also mention, back to the "known issue" caused by this, that I maintain separate "desktop shortcuts" for launching Emacs with and without automatically launching ERC connections. It would be nice if this arrangement (once again) had the intended effect of not loading ERC when I'm not going to need it in the given session. In any event: +1 I'd be grateful to see this resolved before cutting 30.1 From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 02 02:43:53 2024 Received: (at 73812) by debbugs.gnu.org; 2 Nov 2024 06:43:53 +0000 Received: from localhost ([127.0.0.1]:52930 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t77rU-0007Vr-Tf for submit@debbugs.gnu.org; Sat, 02 Nov 2024 02:43:53 -0400 Received: from mail-108-mta187.mxroute.com ([136.175.108.187]:35999) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t77rS-0007Vl-R3 for 73812@debbugs.gnu.org; Sat, 02 Nov 2024 02:43:52 -0400 Received: from filter006.mxroute.com ([136.175.111.3] filter006.mxroute.com) (Authenticated sender: mN4UYu2MZsgR) by mail-108-mta187.mxroute.com (ZoneMTA) with ESMTPSA id 192eb9d9a630003e01.002 for <73812@debbugs.gnu.org> (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Sat, 02 Nov 2024 06:43:47 +0000 X-Zone-Loop: 9c1f3921287faf15dc0aa99e0d6ae55a4e02b2d60cc5 X-Originating-IP: [136.175.111.3] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=neverwas.me ; s=x; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date: References:In-Reply-To:Subject:Cc:To:From:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=Wy2+Sbvcb190dyE8kbnWtgQ/b3cJMbtRLM0G5BT31G8=; b=P1dYMyRkwxWa4WFRVI3hlg9sol HqHrngiosxAhirJt/AnYOJufF9w8Zf4BzJRSAeoMRnxAt6xRtmoRiN/mxpogM1/gvEbLhPJ4i0jjE V8LlCRW7YzHKOqXE1PwLZE06Aqhyc8Gf6SuuJK/pBFt+kntG7fjIC9q3ry9T+MZPRQ6IaZcLhS17R gHA3JZev4Yvg8VG8HLKEnZ2kX+qAoMZSQBp0w09zBNVJUw+jUa6/17hxxjK+DcARA98YpGRaxJr2l UIo7pck+bPtDlJ/w6tLmWg+64J372L1yPrbSN6wiGVFfYCnhOTZh73fPQxH6hHqvHe+baOK1Mw0eW +fscMaaQ==; From: "J.P." To: Corwin Brust Subject: Re: bug#73812: 30.0.91; ERC 5.6.0.30.1: Customizing erc-modules loads ERC when starting Emacs In-Reply-To: (Corwin Brust's message of "Fri, 1 Nov 2024 21:37:06 -0500") References: <87o73mgjk3.fsf@neverwas.me> <865xptsh6f.fsf@gnu.org> <87h69ddz5l.fsf@neverwas.me> <86bjzhopaz.fsf@gnu.org> <87ttd947pg.fsf@neverwas.me> <87ed3z1tut.fsf@neverwas.me> <87cyjepihk.fsf@neverwas.me> Date: Fri, 01 Nov 2024 23:43:43 -0700 Message-ID: <87sesakue8.fsf@neverwas.me> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Authenticated-Id: masked@neverwas.me X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 73812 Cc: 73812@debbugs.gnu.org, Eli Zaretskii , Andrea Corallo , emacs-erc@gnu.org, Stefan Kangas 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 (-) Hi Stefan, Corwin, all, Corwin Brust writes: > Hi All, > > On Fri, Nov 1, 2024 at 9:05=E2=80=AFPM Stefan Kangas wrote: >> >> "J.P." writes: >> >> I can only add that some of our users are very concerned with Emacs's >> startup time, and spend a lot of time optimizing it. Unexpectedly >> pulling in all of ERC in some cases certainly won't help them. >> >> > "J.P." writes: >> > >> >> Eli Zaretskii writes: >> >> >> >>>> All in all, I'd prefer to leave this alone in Emacs 30. We have ti= me >> >>>> to try reverting this on master and seeing whether it's a net win o= r a >> >>>> net loss, given the past history of the issue. (AFAIU, if you remo= ve >> >>>> this line, some change is pertinent in the manual?) >> >> >> >> It's been reverted on master for ten days now with no complaints: >> >> >> >> https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=3D1854f275 >> >> >> >> If that's long enough to qualify as a net win, can we proceed with a >> >> backport? >> > >> > It's been two weeks now since I was tasked with reverting this on mast= er >> > in order to assess the damage, of which none has since been reported. >> > >> > Apologies if I'm out of line in pressing the issue, but I'm driven by a >> > need to advocate for ERC's users, who've suffered greatly in the past >> > due to my cowardliness in similar situations [1]. As such, I would very >> > much appreciate a final verdict on this matter. >> >> I assume that we are talking about cherry-picking commit 1854f2751e3f to >> the emacs-30 branch. Yes, exactly. FWIW, something like diff --git a/lisp/erc/erc.el b/lisp/erc/erc.el index 30641c2bd88..807ca81ed6b 100644 --- a/lisp/erc/erc.el +++ b/lisp/erc/erc.el @@ -2263,7 +2263,7 @@ erc--sort-modules (cl-pushnew mod (if (get mod 'erc--module) built-in third-party))) `(,@(sort built-in #'string-lessp) ,@(nreverse third-party)))) -;;;###autoload(custom-autoload 'erc-modules "erc") +;;;###autoload(custom-autoload 'erc-modules "erc" 'noset) (defcustom erc-modules '( autojoin button completion fill imenu irccontr= ols list match menu move-to-prompt netsplit does appear to suppress autoloading on startup while still fulfilling our original M-x customize-option RET mission (IOW, exactly what we want). However, I'd sooner just revert to the way things have been for 20+ years. ("Once bitten," as they say.) >> >> Can removing the autoload cookie cause an issue outside of ERC, or for >> non-users of ERC? If it cannot, I don't know that I'm in a better >> position than you, being the ERC maintainer, to determine what kind of >> negative impact removing it might have. If anything, it sounds like it >> is more risky for non-users of ERC to leave things as is? >> >> In summary, my view is that removing it should be low risk, and it fixes >> a known bug. It's arguably minor, but does affect startup performance. >> So I think it sounds good to have the patch on emacs-30. >> >> Let's see if Eli or Andrea has anything to add here first, though. >> > > Thank you JP and Stefan for diligence on this. I had flagged this for > a reply but did not manage to make one before now. (Two weeks > already? Good grief.) > > Perhaps importantly: I strongly suspect this bug is responsible for > corruption of my customize file. (Unfortunately I had a bunch of > stuff in there and wasn't good and pushed my changes to that > particular file to the repo where I version my config, so I've lost a > bit of work. On the plus side: it's generally of a cosmetic nature, > mostly face tweaks which I found it convenient to "try out" using > customize and then, because they were good, never got around to > encoding into proper elisp.) I didn't/haven't completed any sort of > minimal reproducer: I could be completely wrong that this bug is what > caused my configuration settings to get blown away. But the timing is > right. So sorry about your data loss and for whatever hand my sloppiness might have played in such a tragedy. It does indeed sound like a serious issue that bears investigating. Unfortunately, I'm still a certified dunce when it comes to all things Customize (but I do pledge to rectify this situation eventually). > > I will also mention, back to the "known issue" caused by this, that I > maintain separate "desktop shortcuts" for launching Emacs with and > without automatically launching ERC connections. It would be nice if > this arrangement (once again) had the intended effect of not loading > ERC when I'm not going to need it in the given session. > > In any event: +1 > > I'd be grateful to see this resolved before cutting 30.1 Appreciate the input as always. From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 02 03:23:26 2024 Received: (at 73812) by debbugs.gnu.org; 2 Nov 2024 07:23:26 +0000 Received: from localhost ([127.0.0.1]:52985 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t78Tl-0000EP-KC for submit@debbugs.gnu.org; Sat, 02 Nov 2024 03:23:25 -0400 Received: from eggs.gnu.org ([209.51.188.92]:49246) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t78Tj-0000EH-Kp for 73812@debbugs.gnu.org; Sat, 02 Nov 2024 03:23: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 1t78RX-0004dE-Qg; Sat, 02 Nov 2024 03:21:07 -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=idkQgzKGvPSAiFJUoK3GdCvPeCvFRwuqgDGhP2bguDk=; b=hk0DyteM2/7k iuyMySE70ANBdMEpwX6xEYiBmEWjSli9AIOfAjJkBwbRTCxds1Og4/OM5ufYPdDxqS/b2plR8U4NP TNnxJpqI4tpUXSjklHMvLfekOcdMlPkOhGgDuTUm5HTitg+8XV8ys3HElSVb/76bkItYjVTqAsqqp 3GR2POphH+YiqMBXxphiMnBSdeArOZNBlJu0fL4JSHoDanueGqahhkm9+77G++r0K2L2fTZQ5gAS4 1puIY5RPFsolLrxdGYJEOpt+gTEyVuoADjXBocKHeHr8SA3Ng8fWH5D9XY4hmKTATlLOa5CTLspvM fGxv+DwLvD2IrjS2Y3bDjg==; Date: Sat, 02 Nov 2024 09:21:03 +0200 Message-Id: <86ttcqyucg.fsf@gnu.org> From: Eli Zaretskii To: "J.P." In-Reply-To: <87cyjepihk.fsf@neverwas.me> (jp@neverwas.me) Subject: Re: bug#73812: 30.0.91; ERC 5.6.0.30.1: Customizing erc-modules loads ERC when starting Emacs References: <87o73mgjk3.fsf@neverwas.me> <865xptsh6f.fsf@gnu.org> <87h69ddz5l.fsf@neverwas.me> <86bjzhopaz.fsf@gnu.org> <87ttd947pg.fsf@neverwas.me> <87ed3z1tut.fsf@neverwas.me> <87cyjepihk.fsf@neverwas.me> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 73812 Cc: 73812@debbugs.gnu.org, acorallo@gnu.org, emacs-erc@gnu.org, stefankangas@gmail.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 (---) > From: "J.P." > Cc: 73812@debbugs.gnu.org, emacs-erc@gnu.org, Eli Zaretskii > Date: Fri, 01 Nov 2024 17:49:43 -0700 > > Dear auxiliary maintainers, > > It seems Eli has tired of my nagging or is otherwise indisposed when it > comes to this issue. I have not. But you made the mistake of quoting only a little bit from the previous message, from which I couldn't even understand those were my words. And I generally avoid commenting on changes related to ERC because I don't use it and am not familiar with its code. In the future, if it's my/our decision that you are seeking, please quote more of the context and ask for our response explicitly, to avoid these misunderstandings. > > Eli Zaretskii writes: > > > >>> All in all, I'd prefer to leave this alone in Emacs 30. We have time > >>> to try reverting this on master and seeing whether it's a net win or a > >>> net loss, given the past history of the issue. (AFAIU, if you remove > >>> this line, some change is pertinent in the manual?) > > > > It's been reverted on master for ten days now with no complaints: > > > > https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=1854f275 > > > > If that's long enough to qualify as a net win, can we proceed with a > > backport? > > It's been two weeks now since I was tasked with reverting this on master > in order to assess the damage, of which none has since been reported. > > Apologies if I'm out of line in pressing the issue, but I'm driven by a > need to advocate for ERC's users, who've suffered greatly in the past > due to my cowardliness in similar situations [1]. As such, I would very > much appreciate a final verdict on this matter. I'd prefer to wait a little longer for any fallout of reverting this on master. IME, two weeks is not long enough, as many people take several weeks to update their builds. Emacs 30 is not going to be released tomorrow, so we still have time. Let's talk about this in two more weeks, ok? From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 02 11:41:07 2024 Received: (at 73812) by debbugs.gnu.org; 2 Nov 2024 15:41:07 +0000 Received: from localhost ([127.0.0.1]:54052 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t7GFP-0007KH-0x for submit@debbugs.gnu.org; Sat, 02 Nov 2024 11:41:07 -0400 Received: from mail-108-mta12.mxroute.com ([136.175.108.12]:45113) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t7GFJ-0007Jn-TO for 73812@debbugs.gnu.org; Sat, 02 Nov 2024 11:41:05 -0400 Received: from filter006.mxroute.com ([136.175.111.3] filter006.mxroute.com) (Authenticated sender: mN4UYu2MZsgR) by mail-108-mta12.mxroute.com (ZoneMTA) with ESMTPSA id 192ed8966a30003e01.001 for <73812@debbugs.gnu.org> (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Sat, 02 Nov 2024 15:40:57 +0000 X-Zone-Loop: a7f33a4055e23fcb746187d227ebb7931e5c3f42f0a5 X-Originating-IP: [136.175.111.3] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=neverwas.me ; s=x; h=Content-Type:MIME-Version:Message-ID:Date:References:In-Reply-To: Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=zhK7g6p+Y/dV7PUqlb7+qiam7G3VJgMEWM3F3kjwmog=; b=gKSblldibK+9Dk4phQl9diIFmP 9thrXW0AlyYRwSEUYYxjIapb4yUpOGuqdXyOhJ4civH1DBg64oi5Rw3SviWBRcSZxgcm8T0DNG2gJ mA/MNqyQNG9l7GupufG5O9D4Mi6RxZI+/Xxn7IRbmUp7mU4mpF2QeS9DA4Oi7KAG++0pLZH9XswDt 6JyjSvjsyIJe4c4r3H+bY46My7YN3QGXFGptgN3FXvAuD3uMH20ZhYXi1OjBB2rBRtEQ+5EFey6EO qrMtTZhvW31GMTjGcV0JGNoMyDwQgb2dNUTAiHzt7m7vzRC4vsHZj/ycx65VsjwzBf8/ninN/3O3E /dkKebhQ==; From: "J.P." To: Eli Zaretskii Subject: Re: bug#73812: 30.0.91; ERC 5.6.0.30.1: Customizing erc-modules loads ERC when starting Emacs In-Reply-To: <86ttcqyucg.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 02 Nov 2024 09:21:03 +0200") References: <87o73mgjk3.fsf@neverwas.me> <865xptsh6f.fsf@gnu.org> <87h69ddz5l.fsf@neverwas.me> <86bjzhopaz.fsf@gnu.org> <87ttd947pg.fsf@neverwas.me> <87ed3z1tut.fsf@neverwas.me> <87cyjepihk.fsf@neverwas.me> <86ttcqyucg.fsf@gnu.org> Date: Sat, 02 Nov 2024 08:40:54 -0700 Message-ID: <8734k9fxtl.fsf@neverwas.me> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Authenticated-Id: masked@neverwas.me X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 73812 Cc: 73812@debbugs.gnu.org, acorallo@gnu.org, emacs-erc@gnu.org, stefankangas@gmail.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: -1.0 (-) Eli Zaretskii writes: >> From: "J.P." >> Cc: 73812@debbugs.gnu.org, emacs-erc@gnu.org, Eli Zaretskii >> Date: Fri, 01 Nov 2024 17:49:43 -0700 >> >> Dear auxiliary maintainers, >> >> It seems Eli has tired of my nagging or is otherwise indisposed when it >> comes to this issue. > > I have not. But you made the mistake of quoting only a little bit > from the previous message, from which I couldn't even understand those > were my words. And I generally avoid commenting on changes related to > ERC because I don't use it and am not familiar with its code. > > In the future, if it's my/our decision that you are seeking, please > quote more of the context and ask for our response explicitly, to > avoid these misunderstandings. Makes sense. My apologies. > >> > Eli Zaretskii writes: >> > >> >>> All in all, I'd prefer to leave this alone in Emacs 30. We have time >> >>> to try reverting this on master and seeing whether it's a net win or a >> >>> net loss, given the past history of the issue. (AFAIU, if you remove >> >>> this line, some change is pertinent in the manual?) >> > >> > It's been reverted on master for ten days now with no complaints: >> > >> > https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=1854f275 >> > >> > If that's long enough to qualify as a net win, can we proceed with a >> > backport? >> >> It's been two weeks now since I was tasked with reverting this on master >> in order to assess the damage, of which none has since been reported. >> >> Apologies if I'm out of line in pressing the issue, but I'm driven by a >> need to advocate for ERC's users, who've suffered greatly in the past >> due to my cowardliness in similar situations [1]. As such, I would very >> much appreciate a final verdict on this matter. > > I'd prefer to wait a little longer for any fallout of reverting this > on master. IME, two weeks is not long enough, as many people take > several weeks to update their builds. Emacs 30 is not going to be > released tomorrow, so we still have time. > > Let's talk about this in two more weeks, ok? Sounds good. Thanks. From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 16 08:48:37 2024 Received: (at 73812) by debbugs.gnu.org; 16 Nov 2024 13:48:38 +0000 Received: from localhost ([127.0.0.1]:52543 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tCJAD-0003VK-IB for submit@debbugs.gnu.org; Sat, 16 Nov 2024 08:48:37 -0500 Received: from eggs.gnu.org ([209.51.188.92]:45696) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tCJA9-0003Uu-Gp for 73812@debbugs.gnu.org; Sat, 16 Nov 2024 08:48:35 -0500 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 1tCJA4-0003sC-2E; Sat, 16 Nov 2024 08:48:28 -0500 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=JPojVPAzfm5bf9caDpT41LAX6H5Y8BzXAVfiGGCf7A0=; b=AKOWCNbHsLNs 9XQ/K8/N5uNlFOn6GZXmpPJyysl2HmUM04yD9hzowdCB3UNguFeMG0mTPioRCbqys3MIfy3HneRwN BhWqR5Zx9EXKWi/NhUShZx7kDZ2IguJHw/T7eMUhynvckC00VaZHmG94A9SFoYUbVxOjW21Zgxhr1 QCFWWP2ufDenp9wv/QlRwboVTPTOeec9LlW6pZby9N7I73r3rgZZ/tW97M8V+uktz+rPyxu51MXSF NALzcjT3OaJ964b/cmKfPe+o8km610jFp9iLUnuLhAOzne81KCiNCqmloBtGA92xrFhI1lril4+jS gka/XLSP2uLgPj/+DaS6Nw==; Date: Sat, 16 Nov 2024 15:48:21 +0200 Message-Id: <868qtjguhm.fsf@gnu.org> From: Eli Zaretskii To: "J.P." In-Reply-To: <8734k9fxtl.fsf@neverwas.me> (jp@neverwas.me) Subject: Re: bug#73812: 30.0.91; ERC 5.6.0.30.1: Customizing erc-modules loads ERC when starting Emacs References: <87o73mgjk3.fsf@neverwas.me> <865xptsh6f.fsf@gnu.org> <87h69ddz5l.fsf@neverwas.me> <86bjzhopaz.fsf@gnu.org> <87ttd947pg.fsf@neverwas.me> <87ed3z1tut.fsf@neverwas.me> <87cyjepihk.fsf@neverwas.me> <86ttcqyucg.fsf@gnu.org> <8734k9fxtl.fsf@neverwas.me> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 73812 Cc: 73812@debbugs.gnu.org, acorallo@gnu.org, emacs-erc@gnu.org, stefankangas@gmail.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 (---) > From: "J.P." > Cc: stefankangas@gmail.com, acorallo@gnu.org, 73812@debbugs.gnu.org, > emacs-erc@gnu.org > Date: Sat, 02 Nov 2024 08:40:54 -0700 > > Eli Zaretskii writes: > > >> Apologies if I'm out of line in pressing the issue, but I'm driven by a > >> need to advocate for ERC's users, who've suffered greatly in the past > >> due to my cowardliness in similar situations [1]. As such, I would very > >> much appreciate a final verdict on this matter. > > > > I'd prefer to wait a little longer for any fallout of reverting this > > on master. IME, two weeks is not long enough, as many people take > > several weeks to update their builds. Emacs 30 is not going to be > > released tomorrow, so we still have time. > > > > Let's talk about this in two more weeks, ok? > > Sounds good. Thanks. If no issues were reported on master due to this change, feel free to backport to the emacs-30 branch. Thanks. From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 16 11:28:03 2024 Received: (at 73812-done) by debbugs.gnu.org; 16 Nov 2024 16:28:03 +0000 Received: from localhost ([127.0.0.1]:54497 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tCLeV-0003Ey-4K for submit@debbugs.gnu.org; Sat, 16 Nov 2024 11:28:03 -0500 Received: from mail-108-mta127.mxroute.com ([136.175.108.127]:38743) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tCLeS-0003EQ-HK for 73812-done@debbugs.gnu.org; Sat, 16 Nov 2024 11:28:01 -0500 Received: from filter006.mxroute.com ([136.175.111.3] filter006.mxroute.com) (Authenticated sender: mN4UYu2MZsgR) by mail-108-mta127.mxroute.com (ZoneMTA) with ESMTPSA id 19335cd6ef40003e01.001 for <73812-done@debbugs.gnu.org> (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Sat, 16 Nov 2024 16:27:56 +0000 X-Zone-Loop: 97072f5e9b04c405879df39733a7aa1d17e4182d5be9 X-Originating-IP: [136.175.111.3] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=neverwas.me ; s=x; h=Content-Type:MIME-Version:Message-ID:Date:References:In-Reply-To: Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=eN31DwYrldUVXEjTUETOIgzMhpWkP6LHFTEpiU+BMYU=; b=UK2BuIU5D5CERY7GB3xNEEreqe skW3PegVFGuztVFZZhWkJ1guPzCSAZLqYc65kXv20l6BUKqUjqzlfnWYi5c+xOrtadw83uIVabbcU V2pL4Zro/DDF0SmBwvZRhBVEkfrXufGE0H/56/9SjcblJNgp/amPGWNvvfFmZUpZbhTykSey/lXyA +a7u2N9woPeU8g5p0CclbemvhR415JOvNIjYle1rJjVzfiQ4rp2GATy0Gbkxvpag5Fq1SsrsoiYHq kLZbDGpsWlTrxU3BAo2/M8OYHtgrUHXou/SgQekNyYjMyFxlHOHmRdfK4EuBNRcAPBX6TRbVq6X+3 T/K1iLYw==; From: "J.P." To: Eli Zaretskii Subject: Re: bug#73812: 30.0.91; ERC 5.6.0.30.1: Customizing erc-modules loads ERC when starting Emacs In-Reply-To: <868qtjguhm.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 16 Nov 2024 15:48:21 +0200") References: <87o73mgjk3.fsf@neverwas.me> <865xptsh6f.fsf@gnu.org> <87h69ddz5l.fsf@neverwas.me> <86bjzhopaz.fsf@gnu.org> <87ttd947pg.fsf@neverwas.me> <87ed3z1tut.fsf@neverwas.me> <87cyjepihk.fsf@neverwas.me> <86ttcqyucg.fsf@gnu.org> <8734k9fxtl.fsf@neverwas.me> <868qtjguhm.fsf@gnu.org> Date: Sat, 16 Nov 2024 08:27:52 -0800 Message-ID: <87iksnrvnb.fsf@neverwas.me> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Authenticated-Id: masked@neverwas.me X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 73812-done Cc: 73812-done@debbugs.gnu.org, acorallo@gnu.org, emacs-erc@gnu.org, stefankangas@gmail.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: -1.0 (-) Eli Zaretskii writes: >> From: "J.P." >> Cc: stefankangas@gmail.com, acorallo@gnu.org, 73812@debbugs.gnu.org, >> emacs-erc@gnu.org >> Date: Sat, 02 Nov 2024 08:40:54 -0700 >> >> Eli Zaretskii writes: >> >> >> Apologies if I'm out of line in pressing the issue, but I'm driven by a >> >> need to advocate for ERC's users, who've suffered greatly in the past >> >> due to my cowardliness in similar situations [1]. As such, I would very >> >> much appreciate a final verdict on this matter. >> > >> > I'd prefer to wait a little longer for any fallout of reverting this >> > on master. IME, two weeks is not long enough, as many people take >> > several weeks to update their builds. Emacs 30 is not going to be >> > released tomorrow, so we still have time. >> > >> > Let's talk about this in two more weeks, ok? >> >> Sounds good. Thanks. > > If no issues were reported on master due to this change, feel free to > backport to the emacs-30 branch. Done. Thanks and closing. From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 16 13:05:22 2024 Received: (at 73812) by debbugs.gnu.org; 16 Nov 2024 18:05:22 +0000 Received: from localhost ([127.0.0.1]:54723 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tCNAg-0007js-16 for submit@debbugs.gnu.org; Sat, 16 Nov 2024 13:05:22 -0500 Received: from mail-108-mta12.mxroute.com ([136.175.108.12]:38209) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tCNAe-0007jj-4D for 73812@debbugs.gnu.org; Sat, 16 Nov 2024 13:05:21 -0500 Received: from filter006.mxroute.com ([136.175.111.3] filter006.mxroute.com) (Authenticated sender: mN4UYu2MZsgR) by mail-108-mta12.mxroute.com (ZoneMTA) with ESMTPSA id 1933626868f0003e01.001 for <73812@debbugs.gnu.org> (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Sat, 16 Nov 2024 18:05:14 +0000 X-Zone-Loop: b41fca8b73d6734b57925a689cb93b27a51f9674c9ca X-Originating-IP: [136.175.111.3] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=neverwas.me ; s=x; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date: References:In-Reply-To:Subject:Cc:To:From:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=ZpHs3XbkDpKV/RBxlvA8liwo6UlsN07OUBpYFW2SmPs=; b=Y0DPIi4OpNj6sMlZq7OeTlVSAY +lHphwW1joGHZqDjJmOHPrz94kLR5nRKOEedvUYlBBZK6UX00rs8BcnG3HiM/wiwf+g6rNjxcVRRl WfhAVXvdGS34zdEeBKEzp782TDSCwoE/pf2RP2HSE2xj5uDKmFbV6o2aIfiYN7WlMorbMnSWIWhyx kH9KNUDyZEZAZGwLT6C4hAjeaVg4bsGixJjcsNc8ulPSmR1napk0HSidxmbwH3MJ+jvWNW/j8/auU BgdSKU6h50g2FODBh2JeeriFk6Lkf718hvuDI36XpwGWS+J3tUtbQYEskRh8ukv5oDgf7SMdnfm+G v+t/TKJA==; From: "J.P." To: 73812@debbugs.gnu.org Subject: Re: bug#73812: 30.0.91; ERC 5.6.0.30.1: Customizing erc-modules loads ERC when starting Emacs In-Reply-To: <87o73mgjk3.fsf@neverwas.me> (J. P.'s message of "Mon, 14 Oct 2024 19:57:00 -0700") References: <87o73mgjk3.fsf@neverwas.me> Date: Sat, 16 Nov 2024 10:05:12 -0800 Message-ID: <878qtjnjfr.fsf@neverwas.me> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Authenticated-Id: masked@neverwas.me X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 73812 Cc: emacs-erc@gnu.org 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 (-) Some additional notes for future people investigating similar problems. To recap, when trying to autoload the option `erc-modules' for the purpose of getting M-x customize-option RET to work OOTB (a common request), I found that ;;;###autoload (defcustom erc-modules ...) meant we needed to migrate symbols used in the option's complicated :set function to the main library or else suffer an error during loaddefs generation. In ERC's case, such a migration would have defied the purpose of keeping a common base library in erc-common.el. I also noticed that adding the cookie placed the entire, massive `defcustom' definition in lisp/loaddefs.el, which seemed rather unsightly. And it also worried me, perhaps irrationally so, that such an inclusion might one day potentially interfere with newer versions installed from ELPA, though this is likely dubious. So I instead opted for a manual ;;;###autoload(custom-autoload 'erc-modules "erc") which "worked" but caused ERC to load on startup for anyone with a (custom-set-variables '(erc-modules ())) in their `custom-file'. As mentioned in this ticket's main thread, one possible interpretation is that I merely forgot to include a non-nil `noset' argument to `custom-autoload', which does indeed produce the desired behavior: ERC only loads when a user actually customizes the option. (This has been observed both on master as well as on upgrades installed atop 27+.) Unfortunately (for ERC), it seems `loaddefs-generate--make-autoload' omits `noset' for options that have a `:set' function, which may seem rather obvious. Despite this, it's still unclear to me whether our use case aligns fully with those semantics, at least as laid out in the initial discussions that led to the parameter's introduction [1] (as well as various mentions that have followed over the years [2]). Rather than press the issue, I figured we might as well abide by the guidelines set forth in the info node `(elisp) When to Autoload' =E2=80=A2 Don't autoload a user option just so that a user can set it. which makes it sound like autoloading options for our use case is basically deprecated nowadays. Anyway, if new users continue to complain, we could perhaps add a new autoloaded entry-point command, something like a `erc-customize-modules', that would basically do (require 'erc) (customize-option 'erc-modules) However, the current workaround of recommending C-h v erc-modules RET doesn't seem too strenuous a detour IMO. [1] https://lists.gnu.org/archive/html/emacs-devel/2006-07/msg00270.html [2] https://lists.gnu.org/archive/html/emacs-devel/2009-01/msg00128.html From unknown Wed Jun 18 23:18:10 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Sun, 15 Dec 2024 12:24:05 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator