From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#21563: 24.5; discourage load-hook variables Date: Wed, 15 Jan 2020 19:56:09 -0800 (PST) Message-ID: <80b979c0-0fdf-4b84-bf1b-cde0a596f8bb@default> References: <39185.7955.374134.22021@gargle.gargle.HOWL> <87tv4w1poj.fsf@marxist.se> <87muaoz2qu.fsf@marxist.se> <320a9fa6-6419-420e-ac97-9dcbe54a04a6@default> <87h80wz0dm.fsf@marxist.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="44953"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Roland Winkler , 21563@debbugs.gnu.org To: Stefan Kangas Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Jan 16 04:57:13 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 1irwHQ-000BeD-OK for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 16 Jan 2020 04:57:12 +0100 Original-Received: from localhost ([::1]:35938 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1irwHP-00082T-EB for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 15 Jan 2020 22:57:11 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53285) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1irwHH-000820-K5 for bug-gnu-emacs@gnu.org; Wed, 15 Jan 2020 22:57:04 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1irwHG-0002Ut-AS for bug-gnu-emacs@gnu.org; Wed, 15 Jan 2020 22:57:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:58853) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1irwHG-0002Uf-6P for bug-gnu-emacs@gnu.org; Wed, 15 Jan 2020 22:57:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1irwHG-0005lf-3y for bug-gnu-emacs@gnu.org; Wed, 15 Jan 2020 22:57:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 16 Jan 2020 03:57: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.157914698322126 (code B ref 21563); Thu, 16 Jan 2020 03:57:02 +0000 Original-Received: (at 21563) by debbugs.gnu.org; 16 Jan 2020 03:56:23 +0000 Original-Received: from localhost ([127.0.0.1]:36593 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1irwGd-0005kn-BK for submit@debbugs.gnu.org; Wed, 15 Jan 2020 22:56:23 -0500 Original-Received: from userp2120.oracle.com ([156.151.31.85]:59166) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1irwGa-0005kZ-Ih for 21563@debbugs.gnu.org; Wed, 15 Jan 2020 22:56:21 -0500 Original-Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.27/8.16.0.27) with SMTP id 00G3sBXP121293; Thu, 16 Jan 2020 03:56:14 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2019-08-05; bh=A6NFAvSG63Js9PfVKTLwu39q6O8d+P2rIyga3QHUvqY=; b=Jd38rO3lfTT/HspDoTFB/YdHPYL0sIud4wT0sgFuEIXVLGFEmBorRpp2q66samFtoU7Y 5BDO5JokzM5D7n9yxuPpC+pyqISPIOWLq7sJWP2VnoxwRkyPL1/c8GnsolfcK8DFk0HA yRyVe0Hk5Qtwcn0p2bkNRNrSuIUUMBSIFQmm/mKWdPQ/HgGTDOkUIECkScYA6+w0LbD3 q5NzTERZ1e7bj+etveASNW0lJmPt2IYFTriDrmVjnqZQFhXZL/+FnsPCBM87ms41bb4Q eypDXy8iQ2CJEJgoBk9wP+1YiHpc81mPxsof/0qsC+TSKUjTNAcWEHdrig8eBJFxPg6L mg== Original-Received: from aserp3030.oracle.com (aserp3030.oracle.com [141.146.126.71]) by userp2120.oracle.com with ESMTP id 2xf73yr1b0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 16 Jan 2020 03:56:14 +0000 Original-Received: from pps.filterd (aserp3030.oracle.com [127.0.0.1]) by aserp3030.oracle.com (8.16.0.27/8.16.0.27) with SMTP id 00G3sbOS169986; Thu, 16 Jan 2020 03:56:13 GMT Original-Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserp3030.oracle.com with ESMTP id 2xj61kukck-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 16 Jan 2020 03:56:13 +0000 Original-Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id 00G3uAVj028606; Thu, 16 Jan 2020 03:56:11 GMT In-Reply-To: <87h80wz0dm.fsf@marxist.se> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4939.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9501 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-2001160030 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9501 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-2001160030 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:174696 Archived-At: > > 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. >=20 > 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. So is the argument now that the existence of load hooks makes maintenance too complicated? What will be the next argument? `eval-after-load' is at least as old as load hooks. Probably both have been there since about Day One. Maybe ask RMS why. Maybe load hooks are just cruft, or maybe not. > > Who knows what 3rd-party code out there makes use of such hooks? >=20 > It should migrate to use (with-)eval-after-load. That should be > backwards compatible through "Emacs version 19.29" according to C-h f. Why should it migrate? That's my question. Why is it good now to toss load hooks, when that hasn't been needed before? 40 years of Emacs, and now there's a reason to toss them. What's so important about this now? A bug filed because someone set a hook too late in his init file? If that were a big problem, don't you think load hooks would have been removed long ago? > 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. >=20 > 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. Why delete them at all, finally or immediately? What's the real point? The only thing new (and that's several years old now) was the addition of `with-eval-after-load' (because some users were forgetting that `eval-after-load' is a function, and so evaluates its args). > > And again, they're easy for users to discover. >=20 > 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. The two aren't the same, as I pointed out. And see what I said earlier about discoverability. A hook named after a feature draws your attention to the possibility of hooking in some code there - at that spot, for that feature. A general facility to eval some code after loading a file, any file, isn't quite the same, in particular in terms of notice (discoverability). > > 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). >=20 > Shouldn't use of these hooks in code be considered bad practice for > the same reasons that eval-after-load is? Dunno. Why so? They haven't been introduced at the end of every single library. Someone presumably had a reason for introducing each one, or at least most. A hook is an explicit signal that you kinda expect someone (some code) to want to hook in some other code at that spot. A hook is an invitation: "Here's a place you might want to do something." There are no doubt specific hooks that no one has ever used and that could perhaps be removed. But why do so? Many load hooks are even user options (I don't argue they should be). Users who've customized them will eventually find that they've become no-ops. `dired-load-hook', for example, has this added to its doc string, to tell you about possible use cases: "You can customize key bindings or load extensions with this." Why do we still have _any_ hooks? Why not argue (maybe someone will - Stefan?) that nadvice makes all other hooks obsolete. Anyway, as I say, I don't care much, if no one else cares about this. Please be sure to take care of all places that might take such hooks into consideration. This comment in dired-x.el, for example (no idea whether it's important): ;; This is a no-op if dired-x is being loaded via `dired-load-hook', ;; but maybe not if a dired-x function is being autoloaded. (require 'dired) And there are some hooks with `-load-hook' in the name that don't seem to be hooks run after loading a file. `ff-pre-load-hook' and `ff-post-load-hook', for example. For them, "loading" a file apparently means something quite different (if so, that's a naming bug). And they are buffer-local variables.