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 12:21:41 -0800 (PST) Message-ID: References: <39185.7955.374134.22021@gargle.gargle.HOWL> <87tv4w1poj.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="45927"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 21563@debbugs.gnu.org To: Stefan Kangas , Roland Winkler Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Jan 15 21:23: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 1irpC4-000Btt-EZ for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 15 Jan 2020 21:23:12 +0100 Original-Received: from localhost ([::1]:60278 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1irpC3-0002Rv-6o for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 15 Jan 2020 15:23:11 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:44111) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1irpBv-0002Rk-Qa for bug-gnu-emacs@gnu.org; Wed, 15 Jan 2020 15:23:05 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1irpBu-0000V4-Iq for bug-gnu-emacs@gnu.org; Wed, 15 Jan 2020 15:23:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:57908) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1irpBu-0000Ut-FV for bug-gnu-emacs@gnu.org; Wed, 15 Jan 2020 15:23:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1irpBu-0002og-CF for bug-gnu-emacs@gnu.org; Wed, 15 Jan 2020 15:23: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: Wed, 15 Jan 2020 20:23: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.157911972210741 (code B ref 21563); Wed, 15 Jan 2020 20:23:02 +0000 Original-Received: (at 21563) by debbugs.gnu.org; 15 Jan 2020 20:22:02 +0000 Original-Received: from localhost ([127.0.0.1]:35646 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1irpAs-0002mp-CL for submit@debbugs.gnu.org; Wed, 15 Jan 2020 15:22:02 -0500 Original-Received: from userp2130.oracle.com ([156.151.31.86]:60552) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1irpAm-0002mY-Et for 21563@debbugs.gnu.org; Wed, 15 Jan 2020 15:21:57 -0500 Original-Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.27/8.16.0.27) with SMTP id 00FKHkX4021792; Wed, 15 Jan 2020 20:21:45 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=3atnFR9UHB8TGw1PGZY88CDBAR+UWcLLQqv4EwXBvuM=; b=r6lhjkpffitsC0PSkQojeHRTo3J6wFCkjbSkluUb44CGF2HC8oXAwq5pHm86vmHJTBEL O2uCStwijZrgjqV2+PuJEdHjiv4lnz/HweRJfDme7gPpfqMVN1vWTlS+BDJ5WtO9KnO9 pa6TY2pFHrZZaN6PT3tjNsdbAcQhaJjFFKDQai3BaSx/MBm9YsjMZUa5n4V56Qd5KS8x ZnAZdE6YXw9uoxNBlGfkt7hOSbPyCaFrpKS1Qrzmzjw4xKxKretcmvrVP7YPmsPpylXm 2RbCjPz1cRxUHPPj6uGuYsJvnRyPwghCIwMTwS03N7Aik/dWz2GnpsivNjs/tOhB0WDd Pg== Original-Received: from userp3020.oracle.com (userp3020.oracle.com [156.151.31.79]) by userp2130.oracle.com with ESMTP id 2xf74seh0s-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 15 Jan 2020 20:21:45 +0000 Original-Received: from pps.filterd (userp3020.oracle.com [127.0.0.1]) by userp3020.oracle.com (8.16.0.27/8.16.0.27) with SMTP id 00FKJD08040786; Wed, 15 Jan 2020 20:21:45 GMT Original-Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userp3020.oracle.com with ESMTP id 2xj1prsp19-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 15 Jan 2020 20:21:44 +0000 Original-Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id 00FKLg0a003970; Wed, 15 Jan 2020 20:21:43 GMT In-Reply-To: <87tv4w1poj.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-2001150154 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=1011 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-2001150154 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:174665 Archived-At: >> I had rearranged my init file so that dired got loaded >> before I was setting dired-load-hook. IOW, simple pilot error. > I would suggest to declare the above variables obsolete > and point users to eval-after-load instead. Why? If the only reason (only one given so far) is that a user set a hook after loading and expected the hook setting to be effective, then I'd say that's not a great reason. Pilot error can also happen for `(with-)eval-after-load'. And there was talk at one time of discouraging that as well, I believe. It's still discouraged for code that's to be included in Emacs - see (emacs) `Coding Standards'. (But see also (emacs) `Foldout'.) And see (elisp) `Hooks for Loading': "Normally, well-designed Lisp programs should not use 'with-eval-after-load'." Granted, that's about "Lisp programs" and not init files. Still... > Does anyone disagree with that? I think I do. I see something like `dired-load-hook' as a different tool than `(with-)eval-after-load'. Not worse or better, either generally or always. Setting or changing the explicit hook value has no effect if the library was already loaded, whereas `(with-)eval-after-load' has an immediate effect in=20 that case. (Sure, the latter could test in its body whether it's loaded and act conditionally...) I see no good reason why, because there is more than one way to do something, and some users might shoot themselves in the foot with some of those ways, we should remove those that let you do that. Emacs and Emacs Lisp provide tons of ways to do things, and many ways to shoot yourself in the foot. We can instead make clear in the doc anything that might need pointing out. In this case, I doubt that Roland was just lacking a statement that the load hook would have no effect if the library had already been loaded. But we could certainly make that fact explicit, if it helps in general. Note too that `C-h f dired-mode' explicitly lists the hooks: Hooks (use C-h v to see their documentation): 'dired-before-readin-hook' 'dired-after-readin-hook' 'dired-mode-hook' 'dired-load-hook' When you use apropos or similar to find a Dired hook you find one for after-loading. Removing that hook means you won't find it. This doc would then need to be changed to list the other hooks but also say that if you want a function to be invoked after loading then use `(with-)eval-after-load' and invoke the function in the body. IOW, no parallelism or discoverability. Many users won't know about `(with-)eval-after-load'. In addition, users can easily get confused between 'dired-after-readin-hook' and 'dired-load-hook'. Having both, with their documentation, helps users DTRT. What does it really hurt, to keep such hooks?