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: Wed, 1 Feb 2017 09:01:44 -0800 (PST) Message-ID: 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> 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 1485968586 9188 195.159.176.226 (1 Feb 2017 17:03:06 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 1 Feb 2017 17:03:06 +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 Wed Feb 01 18:03:02 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 1cYyJB-00025b-37 for geb-bug-gnu-emacs@m.gmane.org; Wed, 01 Feb 2017 18:03:01 +0100 Original-Received: from localhost ([::1]:52122 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cYyJE-0003M3-Ow for geb-bug-gnu-emacs@m.gmane.org; Wed, 01 Feb 2017 12:03:04 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37771) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cYyIH-0002nQ-Gu for bug-gnu-emacs@gnu.org; Wed, 01 Feb 2017 12:02:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cYyIE-0003Hv-D1 for bug-gnu-emacs@gnu.org; Wed, 01 Feb 2017 12:02:05 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:55387) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cYyIE-0003Hr-8r for bug-gnu-emacs@gnu.org; Wed, 01 Feb 2017 12:02:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1cYyID-0006Tg-Vz for bug-gnu-emacs@gnu.org; Wed, 01 Feb 2017 12:02: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, 01 Feb 2017 17:02: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.148596851624889 (code B ref 25581); Wed, 01 Feb 2017 17:02:01 +0000 Original-Received: (at 25581) by debbugs.gnu.org; 1 Feb 2017 17:01:56 +0000 Original-Received: from localhost ([127.0.0.1]:53586 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cYyI8-0006TM-8G for submit@debbugs.gnu.org; Wed, 01 Feb 2017 12:01:56 -0500 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:29121) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cYyI6-0006T9-EQ for 25581@debbugs.gnu.org; Wed, 01 Feb 2017 12:01:54 -0500 Original-Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v11H1lVi027159 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 1 Feb 2017 17:01:48 GMT Original-Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v11H1lAu020813 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 1 Feb 2017 17:01:47 GMT Original-Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v11H1j2H001307; Wed, 1 Feb 2017 17:01:45 GMT In-Reply-To: <87zii6por2.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: userv0022.oracle.com [156.151.31.74] 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:128867 Archived-At: > > The changes needed, I think, are (1) clarify that the requirement > > of the value being a function applies only to `*-function' vars > > and (2) be clear that there are multiple ways to change the value, > > including plain old `setq' (as Mark O pointed out). >=20 > Hmm, do we really need to explain that variables can be changed with > setq (seems redundant)? I think we do here. Especially since we tell users that you "have to use" `add-function' to modify "such a single function hook". A hook is (still) a variable. It's not super clear from the doc that this is the case, IMO. Because we want to be clear that you should not try to modify the value using, e.g., `add-to-list' - so we recommend `add-hook' or `add-function', we kind of fall into the trap of not being clear that you can bind or set the value in the usual ways. I do think it's worth pointing out that you can do this. > Though it might be useful to compare and contrast setq vs > add-function (and maybe setq vs add-hook too?) OK. But there's not a lot of compare-and-contrast to do, IMO. All we need to say, I think, is that to change (replace) the whole value you can use `setq' (or `set' or `setq-local...), but to _modify_ the current value you should use `add-hook' or `add-function' (and similar), depending on whether the var name is `*-functions' or `*-hook', on the one hand (for `add-hook'), or `*-function', on the other (for `add-function' etc). > Also wondering if add-function needs a bit of "rebranding", > since I see it keeps getting referred to as "advice" (i.e., > something to be avoided). Good question! On the one hand, it does provide a replacement for the old advice system. On the other hand, it is something different and is quite general. I don't have a good suggestion about the best branding for it, but Stefan might have something to offer in this regard. Whatever branding is chosen, it might entail rewriting some of the manual. Part of the question you pose is whether and how much it is something to be avoided. Instead of just saying that or not saying anything at all, it would be helpful if we let users know about some of the consequences of using it, including possible pitfalls or other things to be aware of. Again, Stefan is likely the expert in this regard.