From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Stefan Kangas Newsgroups: gmane.emacs.bugs Subject: bug#21563: 24.5; discourage load-hook variables Date: Thu, 16 Jan 2020 01:54:45 +0100 Message-ID: <87h80wz0dm.fsf@marxist.se> References: <39185.7955.374134.22021@gargle.gargle.HOWL> <87tv4w1poj.fsf@marxist.se> <87muaoz2qu.fsf@marxist.se> <320a9fa6-6419-420e-ac97-9dcbe54a04a6@default> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="118485"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: Roland Winkler , 21563@debbugs.gnu.org To: Drew Adams Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Jan 16 01:55:11 2020 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 1irtRH-000Ulw-4F for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 16 Jan 2020 01:55:11 +0100 Original-Received: from localhost ([::1]:34664 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1irtRG-0002HD-3E for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 15 Jan 2020 19:55:10 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:33735) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1irtR9-0002H6-Ee for bug-gnu-emacs@gnu.org; Wed, 15 Jan 2020 19:55:04 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1irtR8-0005DR-B9 for bug-gnu-emacs@gnu.org; Wed, 15 Jan 2020 19:55:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:58791) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1irtR8-0005DJ-7w for bug-gnu-emacs@gnu.org; Wed, 15 Jan 2020 19:55:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1irtR8-0001F2-6N for bug-gnu-emacs@gnu.org; Wed, 15 Jan 2020 19:55:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Kangas Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 16 Jan 2020 00:55:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 21563 X-GNU-PR-Package: emacs Original-Received: via spool by 21563-submit@debbugs.gnu.org id=B21563.15791360964754 (code B ref 21563); Thu, 16 Jan 2020 00:55:02 +0000 Original-Received: (at 21563) by debbugs.gnu.org; 16 Jan 2020 00:54:56 +0000 Original-Received: from localhost ([127.0.0.1]:36531 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1irtR1-0001Eb-Ox for submit@debbugs.gnu.org; Wed, 15 Jan 2020 19:54:56 -0500 Original-Received: from ted.gofardesign.uk ([67.225.143.91]:36578) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1irtQz-0001EO-Qw for 21563@debbugs.gnu.org; Wed, 15 Jan 2020 19:54:54 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=marxist.se; s=default; 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=xjme4ZI7mvGCZLR8w6ouc0jyD2Qx0oHvm2b2y8dziSo=; b=KF5UBSNjZ/UIVoagPD9T0qeU9D AX89GqjZVSMHM/JYDrtlr22eY+9Ihcad+1o1IOsYDHZ7cMsqGDKZyGRGxgrv1N1mK+T6gerByDCH2 81AK3+EvmI/6scSCcKntUk+6pM14XdJHjEVpoDmkkJgU3xJXj92CguauX2TfwhgyYo1hzKwyimtEi ypDlbc8nUwR6Rd5ZNfxwoNBlDK+z7ECvb6KdGODp059eXWAACc+v6egbqavfrGJ9ZVZI5LUl5Y8h9 CkUWRgm0XvIBBcjvuZffRjiE7z3WccYNVgCOUYeBXIv5dcqxdh/nWtkWVZ1RkFc/A2M3hcJJkNyII CFnuJSpg==; Original-Received: from h-70-69.a785.priv.bahnhof.se ([155.4.70.69]:51036 helo=localhost) by ted.gofardesign.uk with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1irtQt-0011R4-V4; Wed, 15 Jan 2020 19:54:48 -0500 In-Reply-To: <320a9fa6-6419-420e-ac97-9dcbe54a04a6@default> (Drew Adams's message of "Wed, 15 Jan 2020 16:24:10 -0800 (PST)") X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ted.gofardesign.uk X-AntiAbuse: Original Domain - debbugs.gnu.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - marxist.se X-Get-Message-Sender-Via: ted.gofardesign.uk: authenticated_id: stefan@marxist.se X-Authenticated-Sender: ted.gofardesign.uk: stefan@marxist.se X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 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" Xref: news.gmane.io gmane.emacs.bugs:174687 Archived-At: Drew Adams writes: > I said only that the behavior that a load hook isn't invoked > if the library has already been loaded can be realized by > using conditional code inside `(with-)?eval-after-load'. Thanks, you are correct. I didn't mean to misquote you. > A load hook is a function. Code can invoke it anytime, in > any context. It has no predefined behavior, on its own - > in particular, nothing like `(with-)?eval-after-load' > behavior. The only similarity is that by convention a load > hook is invoked at the end of a Lisp file. But nothing > prevents using a (funcall dired-load-hook) anywhere. > > This is not to say that we really need to be able to do > that. It's just to say that there's no way to claim that > `(with-)?eval-after-load' can be made to do what a load > hook does, in general. The question now though is more limited: is it useful to keep them or not? Glenn says that it is not useful, and I think I agree with him. > I don't have a giant objection to doing what you're talking > about doing. But I think it's unfortunate, and little, if > anything, is really gained. Well, Emacs is old. Like any old software, it has a certain amount of cruft and/or historical accidents. Getting rid of such things when we can makes Emacs easier to maintain in the long run. > Who knows what 3rd-party code out there makes use of such hooks? It should migrate to use (with-)eval-after-load. That should be backwards compatible through "Emacs version 19.29" according to C-h f. Note that the way these hooks have been obsoleted by Glenn is to still run them if they exist, but add an obsoletion warning. I think this is the correct approach. Given how long it takes for us to finally delete obsolete stuff, that should give ten years, give or take, before any third party code depending on these hooks would stop working. > And again, they're easy for users to discover. I think a general facility is even more discoverable and user friendly. In particular, it shows users that this could be used for any package, and not just packages which has defined a particular hook. > And I think they're likely to be used by code, and not just in init > files. That's not so true of `(with-)?eval-after-load' (explicitly > discouraged). Shouldn't use of these hooks in code be considered bad practice for the same reasons that eval-after-load is? Best regards, Stefan Kangas