From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#33601: 26; Add macro `with-hook-added' Date: Tue, 4 Dec 2018 13:22:41 -0800 (PST) Message-ID: References: <20181204184614.2049.qmail@mail.muc.de> <20181204201048.GA13646@ACM> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1543958471 18677 195.159.176.226 (4 Dec 2018 21:21:11 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 4 Dec 2018 21:21:11 +0000 (UTC) Cc: 33601@debbugs.gnu.org To: Alan Mackenzie Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Dec 04 22:21:07 2018 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gUI7u-0004l7-5g for geb-bug-gnu-emacs@m.gmane.org; Tue, 04 Dec 2018 22:21:06 +0100 Original-Received: from localhost ([::1]:59016 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gUIA0-0000hK-Oj for geb-bug-gnu-emacs@m.gmane.org; Tue, 04 Dec 2018 16:23:16 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38834) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gUI9s-0000b4-Hc for bug-gnu-emacs@gnu.org; Tue, 04 Dec 2018 16:23:09 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gUI9m-0007hS-IM for bug-gnu-emacs@gnu.org; Tue, 04 Dec 2018 16:23:08 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:56791) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gUI9m-0007hB-AX for bug-gnu-emacs@gnu.org; Tue, 04 Dec 2018 16:23:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1gUI9m-00049l-58 for bug-gnu-emacs@gnu.org; Tue, 04 Dec 2018 16: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: Tue, 04 Dec 2018 21:23:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 33601 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 33601-submit@debbugs.gnu.org id=B33601.154395857515944 (code B ref 33601); Tue, 04 Dec 2018 21:23:02 +0000 Original-Received: (at 33601) by debbugs.gnu.org; 4 Dec 2018 21:22:55 +0000 Original-Received: from localhost ([127.0.0.1]:32816 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gUI9e-000496-VP for submit@debbugs.gnu.org; Tue, 04 Dec 2018 16:22:55 -0500 Original-Received: from aserp2130.oracle.com ([141.146.126.79]:48362) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gUI9c-00048q-RQ for 33601@debbugs.gnu.org; Tue, 04 Dec 2018 16:22:53 -0500 Original-Received: from pps.filterd (aserp2130.oracle.com [127.0.0.1]) by aserp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id wB4LJLlJ098940; Tue, 4 Dec 2018 21:22:46 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-2018-07-02; bh=ne9TGVAp1ulEAZB04O/MdbNUxDZE3wbAt/mIKV8GjoU=; b=rygYEXy3ToAZdcHjUDErCnB+m2//yL1NhDVpHncgUYJmw8i0WTxO5Yc1yXXdEc/bQh4P ExBImvKjo6A8UnjmCQVZszpcs//T37yHxg2kUXNAxkpsHIgfty72zEVYqBSyzJhFCj7z dpUyDaA1wdTSdZ0mK764eh+cdpHv9K/G9xjQ0n1czFBTxcNLKX/rkVGzpDFa4JR1k9/L dmHq8+QTmhV3wBKIEzE2egTFgvxUzuuDobKwGZ7QRHNwJ88rhY8AKuhD2sz40ySLggyk zsVnfx0Y8sztVEVaDW91bj1R3ihYLYy69natCx5r2/UXgF68o80PrSVQd+zSvGrYLqzH XA== Original-Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp2130.oracle.com with ESMTP id 2p3ftf2wh4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 04 Dec 2018 21:22:46 +0000 Original-Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id wB4LMjWU028783 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 4 Dec 2018 21:22:46 GMT Original-Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id wB4LMgAj027909; Tue, 4 Dec 2018 21:22:42 GMT In-Reply-To: <20181204201048.GA13646@ACM> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4771.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9097 signatures=668686 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-1810050000 definitions=main-1812040182 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: 208.118.235.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.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:153081 Archived-At: > > > Just a big point: you need to test whether FUNCTION is already on > > > HOOK at the start, and if so, not remove it at the end. >=20 > > A big point? Need to? >=20 > I think so, yes. The essence of the `with-...' macros is that they > temporarily change something, then evaluate ,@body, and at the end, the > something is restored to what it was. >=20 > If with-hook-added didn't preserve the hook, it would > be an anomaly, an outlier, and quite possibly a PITA. If there's an unwritten rule that `with-*' macros preserve and restore everything then clearly the macro I proposed was not a `with-*' macro. Another name for it would be fine, if that's the rule. ;-) > > That wasn't the behavior I had in mind for this, but it's > > another possibility. I intended to provide only for the > > behavior of always removing at the end. >=20 > Why? What's the use case? The kind of thing I showed (with two examples). Yes, I would use them where I either know that the function is not on the hook already or I don't care - cases where I would want it removed at the end in any case. And yes, given your question, the doc of such a macro would need to make clear that it always removes FUNCTION from the hook afterward. > > Choices: > > 1. Provide a single macro for all such possibilities, with > > 3 (mandatory) args for APPEND, LOCAL and whether to remove > > FUNCTION at the end if it was already present at the outset. > > 2. Provide multiple macros, each specific for a given case. > > > > #2 would mean 8 macros, to cover all the combinations > > (nil or t for each of the 3 args). >=20 > How many of these would actually be of any use? All of the behaviors are useful. If you meant to ask whether it is useful to have 8 individual macros, then my answer is probably not. > > Another possibility would be to accept a single arg for > > the BODY code, instead of that being a &rest parameter, > > and so be able to provide those 3 behavior-specifying > > args as optional. In that case, we'd want to decide on > > the best order among those args, e.g., based on which we > > expect to be used most often. >=20 > > I'm not sure what the right approach is. I think the > > most common use case would be the one I wrote up (but > > I don't know that): > > > > . Always remove FUNCTION at the end > > . Prepend, not append. > > . Global, not local. I really have no problem with what you requested: not removing FUNCTION at the end if it was present beforehand. However, now you've gone beyond that to suggest that we should restore the original hook value: "preserve the hook". Should it preserve the hook? Maybe, maybe not. How strict is your unwritten `with-*' rule? Does it apply only to undoing the particular change _it_ makes, or does it also undo changes that might be made by the BODY? In this case, the BODY might itself make changes to the hook. If I had to choose only one macro, it would probably be a general one. I guess it would, as you first requested, remove FUNCTION only if it was not already present. And it would accept args for APPEND and LOCAL. But it would not restore the original hook value. Whether it should require args APPEND and LOCAL or it should instead make you wrap body sexps in a progn is another choice. Dunno which I'd prefer, but probably the former (probably less error prone). Other ideas are welcome. What is your preference (besides always restoring the original hook value)?