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#25581: 25.1; Incorrect statement in (elisp) `Hooks' Date: Thu, 9 Feb 2017 19:00:02 -0800 (PST) Message-ID: <6c1e04f3-8e41-4487-8d3a-567860dce473@default> References: <8e81acfe-ecaa-4fac-9484-24541b232ba1@default> <87k29cq68h.fsf@users.sourceforge.net> <4218ccf3-da3c-43e3-9901-183e4ec81f71@default> <87efzjrhi7.fsf@users.sourceforge.net> <1578ae0e-be68-47b0-a834-69da76fed9cd@default> <87zii6por2.fsf@users.sourceforge.net> <874m09pt6t.fsf@users.sourceforge.net> <87d1eqn7mk.fsf@users.sourceforge.net> 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 1486695671 17075 195.159.176.226 (10 Feb 2017 03:01:11 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 10 Feb 2017 03:01:11 +0000 (UTC) Cc: 25581@debbugs.gnu.org To: npostavs@users.sourceforge.net Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Feb 10 04:01:07 2017 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 1cc1SN-00046i-LK for geb-bug-gnu-emacs@m.gmane.org; Fri, 10 Feb 2017 04:01:07 +0100 Original-Received: from localhost ([::1]:41494 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cc1SR-0005o0-IT for geb-bug-gnu-emacs@m.gmane.org; Thu, 09 Feb 2017 22:01:11 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43579) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cc1SL-0005nR-FC for bug-gnu-emacs@gnu.org; Thu, 09 Feb 2017 22:01:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cc1SI-0004Tc-Ax for bug-gnu-emacs@gnu.org; Thu, 09 Feb 2017 22:01:05 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:35440) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cc1SI-0004TX-7L for bug-gnu-emacs@gnu.org; Thu, 09 Feb 2017 22:01:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1cc1SH-0001xh-Tn for bug-gnu-emacs@gnu.org; Thu, 09 Feb 2017 22:01:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 10 Feb 2017 03:01:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 25581 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 25581-submit@debbugs.gnu.org id=B25581.14866956157480 (code B ref 25581); Fri, 10 Feb 2017 03:01:01 +0000 Original-Received: (at 25581) by debbugs.gnu.org; 10 Feb 2017 03:00:15 +0000 Original-Received: from localhost ([127.0.0.1]:33639 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cc1RX-0001wa-2O for submit@debbugs.gnu.org; Thu, 09 Feb 2017 22:00:15 -0500 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:47383) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cc1RV-0001wL-Js for 25581@debbugs.gnu.org; Thu, 09 Feb 2017 22:00:14 -0500 Original-Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v1A306NJ025181 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 10 Feb 2017 03:00:07 GMT Original-Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id v1A305SZ013622 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 10 Feb 2017 03:00:06 GMT Original-Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id v1A303kJ014047; Fri, 10 Feb 2017 03:00:04 GMT In-Reply-To: <87d1eqn7mk.fsf@users.sourceforge.net> 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: userv0021.oracle.com [156.151.31.71] 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:129173 Archived-At: > >> +If the name of the variable ends in @samp{-predicate} or > >> +@samp{-function} (singular) then its value must be a function, not a > > > > Is this the (new) policy, adding the suffix `-predicate'? > > In my previous comments I was sticking to the old policy, and > > pointing out that `isearch-filter-predicate', now that it is > > being advised here and there with `add-function', is being used > > as a hook, and so it should be named accordingly, as `*-function'. >=20 > Not sure, I was under the impression that -predicate is the same idea as > -function, with the added implication about the return value's meaning. > No idea if this is "new" or not. It's one thing to say that a Boolean function is, in effect, a predicate. It's another thing to extend the convention of names that end in `-function' to apply to names that end in `-predicate'. Such a convention has never been pronounced before, AFAIK. I don't think we should make convention policy this way. Instead, I suggested in my report that the example I know about, `isearch-filter-predicate' is misnamed, precisely because it acts like a hook but is not named following the convention. It should be named `-function', IMO. Whether or not it is easy to rename it now (I think it's possible to deprecate the old name), the fact that it is misnamed should not, by itself, start a spread of `-predicate' as yet another possible hook-name suffix. If someone mistakenly adds another variable that is, in its behavior a hook, and it has suffix `-fn' or `-pred' or `-test', should we then willy nilly update the doc to extend the convention some more? > > But the addition of nadvice.el and subsequent encouragement > > of advising functions with it applies to all functions. It in > > effect makes every function-valued variable into a hook. >=20 > Yes. >=20 > > Can or should users expect that such variables will by > > convention have such a conventional suffix? >=20 > I guess? It's not my call, and as I said, I don't know what I think about this. I tend to lean at the moment toward saying that if we are advising people to `advice-add' variables whose value is expected to always be a function, and if we are calling that a hook of sorts, then we should stick with recommending a simple convention of suffix `-function'. I also think that we should probably point out explicitly somewhere why we have these naming conventions: to facilitate (human) readability. A variable whose name ends in `-function' is conventionally such a hook. That means that just seeing such a name makes us likely to think it is (whether or not it really is - it could be a variable whose value is not necessarily a function). It's an aid to reading, with no guarantees about how reliable/accurate it is. > > Now, since you can apply `add-function' to any function, it > > can happen that someone defines a variable - of whatever > > name - whose value can be a (single) function or nil (or > > a number or a symbol or a character or...). In a general > > sense, since the value CAN be a function, someone could > > call such a variable a "hook", if s?he wants. > > > > But that is, I think, NOT what we are talking about in > > this doc. We are talking here about naming conventions > > for variables whose values are either (1) a function > > whose name ends in `-function' (or `-predicate'?) and > > whose value MUST BE a function or (2) a list of functions > > (normal & abnormal hooks, for which you can use `add-hook'). >=20 > Hmm, I'm not sure if making this division is helpful. I do think we > need some kind of name for these kind of "hooks". Just not sure what it > should be... Please read my last paragraph that you just cited again. That's my point. Those are exactly the naming conventions we've had, up till now. IMO they are the naming conventions we should still have. A variable whose value can be anything, including possibly a function, is not a hook in the sense introduced by our naming conventions. Someone might want to call it a hook because _when its value is a function_, if code invokes that function then yes, it hooks into that function's code. But that's a far cry from the conventions talked about here, which are strict (clear) about what they apply to. If a variable can be anything then its name can be anything, and whether or not it might sometimes have a function value and be invoked is not a reason to dilute the helpful conventions. The point of such a convention (see above) is to help you read code, without analyzing it in detail to see what the use of such a variable is. If someone uses the a name `*-function' its a pretty safe bet that its value _is_ a function and that the code invokes it somewhere. If we start applying such a name to anything and everything that might sometimes have a function value then its power to help reading is reduced. Then, for EVERY variable named `*-function' a reader will need to read all of the code carefully, to see whether and where it might have a function value. It's better to have a good, quick first approximation based on the name, so that even without scrutinizing the code you can suppose that the value is a function. Otherwise, there is little point in having such a convention.