From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: "J.P." Newsgroups: gmane.emacs.bugs Subject: bug#73812: 30.0.91; ERC 5.6.0.30.1: Customizing erc-modules loads ERC when starting Emacs Date: Sat, 16 Nov 2024 10:05:12 -0800 Message-ID: <878qtjnjfr.fsf__26690.7058235788$1731780400$gmane$org@neverwas.me> References: <87o73mgjk3.fsf@neverwas.me> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="23964"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: emacs-erc@gnu.org To: 73812@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Nov 16 19:06:32 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1tCNBo-000673-6D for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 16 Nov 2024 19:06:32 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tCNBV-000283-31; Sat, 16 Nov 2024 13:06:13 -0500 Original-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 1tCNBL-00027R-AN for bug-gnu-emacs@gnu.org; Sat, 16 Nov 2024 13:06:05 -0500 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tCNBK-0006B8-OL for bug-gnu-emacs@gnu.org; Sat, 16 Nov 2024 13:06:03 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=MIME-Version:Date:References:In-Reply-To:From:To:Subject; bh=ZpHs3XbkDpKV/RBxlvA8liwo6UlsN07OUBpYFW2SmPs=; b=N8+ySnccjIvn4ClWqoUUcn9Hx9gdp0Od4891ZM0BbSOfwJ1LURxdO7BuLJCbfcksggF3QBC8A1jB5kfNbcrLbZtXapDyEvi5PyJRzuktmHPvGFXnpaScZbMv5oJPOOMBBLMrg592oYVih9qOO6fhu/0q0vW/j0rjChe3JNA0P+cVVhv7H9PwpkT55dm/bvS3Z98JRcbl2lyrcZfM6ozmFSIeg3VPaE52YZPWijhz+bmuPv+zioP3HsirvBC8AHhQOR85peDkOIpdkc9svmYHvsOkMbqATRqTouTnprNwcsM7g8a/EWLaGW6fh6J0xA1COBYeeU6N0ufE83GWaMU0Bw==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tCNBK-0007kv-J5 for bug-gnu-emacs@gnu.org; Sat, 16 Nov 2024 13:06:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: "J.P." Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 16 Nov 2024 18:06:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 73812 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 73812-submit@debbugs.gnu.org id=B73812.173178032229757 (code B ref 73812); Sat, 16 Nov 2024 18:06:02 +0000 Original-Received: (at 73812) by debbugs.gnu.org; 16 Nov 2024 18:05:22 +0000 Original-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 Original-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 Original-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==; In-Reply-To: <87o73mgjk3.fsf@neverwas.me> (J. P.'s message of "Mon, 14 Oct 2024 19:57:00 -0700") X-Authenticated-Id: masked@neverwas.me X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:295479 Archived-At: 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