From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: Multiple next-error sources Date: Fri, 7 Nov 2014 16:55:51 +0000 Message-ID: <20141107165551.GA2865@acm.acm> References: <20141103084433.12117c03@forcix> <86fvdwgxqs.fsf@yandex.ru> <20141106180815.207bf7ad@forcix> <20141107104914.17f04967@forcix> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1415379441 30047 80.91.229.3 (7 Nov 2014 16:57:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 7 Nov 2014 16:57:21 +0000 (UTC) Cc: emacs-devel@gnu.org, Helmut Eller , Jorgen Schaefer To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Nov 07 17:57:14 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XmmqX-0005wi-JJ for ged-emacs-devel@m.gmane.org; Fri, 07 Nov 2014 17:57:13 +0100 Original-Received: from localhost ([::1]:32831 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XmmqX-0003XR-5l for ged-emacs-devel@m.gmane.org; Fri, 07 Nov 2014 11:57:13 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59381) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xmmq1-0003Sf-SL for emacs-devel@gnu.org; Fri, 07 Nov 2014 11:56:49 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xmmpu-0006Nw-Ba for emacs-devel@gnu.org; Fri, 07 Nov 2014 11:56:41 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:15061 helo=mail.muc.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xmmpt-0006Iu-RZ for emacs-devel@gnu.org; Fri, 07 Nov 2014 11:56:34 -0500 Original-Received: (qmail 93257 invoked by uid 3782); 7 Nov 2014 16:56:30 -0000 Original-Received: from acm.muc.de (pD951BADF.dip0.t-ipconnect.de [217.81.186.223]) by colin.muc.de (tmda-ofmipd) with ESMTP; Fri, 07 Nov 2014 17:56:29 +0100 Original-Received: (qmail 3005 invoked by uid 1000); 7 Nov 2014 16:55:51 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de X-detected-operating-system: by eggs.gnu.org: FreeBSD 8.x X-Received-From: 193.149.48.1 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:176537 Archived-At: Hello, Stefan. On Fri, Nov 07, 2014 at 09:59:12AM -0500, Stefan Monnier wrote: > > The advantage of hooks is that it makes it easier for users to > > customize the behavior by adding and removing various entries. > While it's true that > (add-hook 'next-error-functions #'my-function) > is shorter than > (add-function :before-until next-error-function #'my-function) > I don't think it warrants the addition of a next-error-functions. Why not? > If the :before-until is the problematic part, then I guess we should > look for ways to improve that (e.g. a better name, or some way for > a variable to say that :before-until is the default when adding > functions to it?). > > Is add-function intended to replace hooks like this in general? > Somewhat, yes. I have no intention to go around and replace existing > hooks in the forseeable future (except for those rare hooks that used > with-wrapper-hook), but I'll favor new foo-function over new > foo-functions. Why? I'm adding my voice to the clamour of dissent. It would seem that the use of single functions, with `add-function' is inferior to the conventional hook mechanism in every way. What am I missing? In addition to the things cited by Daniel, there's: (i) the danger (near certainty) that somebody is going to use `setq' rather than `add-function' to configure it; (ii) the additional incompatibility with other Emacsen; (iii) the difficulty (or perhaps clumsiness) in looking at the contents of an advised function. There would seem to be nothing equivalent to M-: after-change-functions. So why are you changing from the conventional hook mechanism, which works so well? What is the advantage of the new scheme. Incidentally, I had a look at the documentation for add-advice, and there's a problem with it. "Advice" in English has no plural - there's no such word as "advices". If it's necessary to emphasize the plurality, then "pieces of advice" can be used. There's no such thing as "an advice", rather you'd say "some advice". It's a bit like you wouldn't refer to a lake as "a big water"; you'd say it contains "a lot of water". I think there's a term in linguistics for such a word, but I don't know it off hand. Incidentally 2, the verb corresponding to the noun "advice" is "to advise". > Stefan -- Alan Mackenzie (Nuremberg, Germany).