From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: 1) (elisp) `Advising Named Functions', 2) search filtering example Date: Mon, 17 Oct 2016 11:41:56 -0700 (PDT) Message-ID: References: <5a44a850-e4fc-4c9f-a266-c74766810ba1@default> <1807679d-1125-4afe-81b7-b8d8e78aa2c6@default> <9f1cf1a7-6f05-449a-a4a2-c013cf326e9c@default> <6c7a705c-c810-49ec-a70c-376ba150205e@default> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1476732330 24318 195.159.176.226 (17 Oct 2016 19:25:30 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 17 Oct 2016 19:25:30 +0000 (UTC) To: Stefan Monnier , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Oct 17 21:25:26 2016 Return-path: Envelope-to: ged-emacs-devel@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 1bwDX9-0004Sc-2Q for ged-emacs-devel@m.gmane.org; Mon, 17 Oct 2016 21:25:15 +0200 Original-Received: from localhost ([::1]:35321 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bwDXB-0005e1-3l for ged-emacs-devel@m.gmane.org; Mon, 17 Oct 2016 15:25:17 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39288) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bwCrP-0002Ok-6v for emacs-devel@gnu.org; Mon, 17 Oct 2016 14:42:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bwCrL-0001lv-TH for emacs-devel@gnu.org; Mon, 17 Oct 2016 14:42:07 -0400 Original-Received: from userp1040.oracle.com ([156.151.31.81]:46559) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1bwCrL-0001lO-Ln for emacs-devel@gnu.org; Mon, 17 Oct 2016 14:42:03 -0400 Original-Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u9HIg1Pt001037 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 17 Oct 2016 18:42:02 GMT Original-Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0022.oracle.com (8.14.4/8.13.8) with ESMTP id u9HIg0ps032532 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 17 Oct 2016 18:42:00 GMT Original-Received: from abhmp0004.oracle.com (abhmp0004.oracle.com [141.146.116.10]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u9HIfvw7005145; Mon, 17 Oct 2016 18:41:58 GMT In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 12.0.6753.5000 (x86)] X-Source-IP: aserv0022.oracle.com [141.146.126.234] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 156.151.31.81 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:208379 Archived-At: > >> If you do this, then you will break the callers, which expect the > >> value of this variable to be a single function. > > > > Tell that to the doc string for `add-hook', which has said what it > > says in this regard for a very long time. >=20 > There is no contradiction between the two. `add-hook's doc talks about > the case where a "multiple-function hook" has a value which happens to > be a single function (which is an acceptable value for those hooks, for > historical reasons). That's one interpretation. There is no mention of the fact that the hook it is talking about is necessarily a "multiple-function hook" that happens to have a single function as value. > Whereas we're here talking about "single-function hooks", i.e. variables > which should only ever hold a single function and not a list of functions= . > > You can use (add-hook ) on them, just like you can use > (setq 5) on them. That doesn't mean that it's correct to do so. If you say so. Who decided it is incorrect, and why? As I noted, previously it was not a no-no to use `add-hook' on such a hook, and `add-hook' was specifically designed to handle the case of a single function (whether "'multiple-function hook' that happens to have a single function as value" or "single-function hook"). And unlike what you just said (you can but it is not correct to do so - or is it just not necessarily correct?), the doc now says: "=E2=80=98add-hook=E2=80=99 cannot be used to modify such a _single functi= on ^^^^^^^^^^^^^^ hook_, and you have to use =E2=80=98add-function=E2=80=99 instead (*note ^^^^^^^^^^^ Advising Functions::)." I wonder who added that sentence. ;-)