From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Multiple next-error sources Date: Fri, 07 Nov 2014 13:48:25 -0500 Message-ID: References: <86fvdwgxqs.fsf@yandex.ru> <20141106180815.207bf7ad@forcix> <20141107104914.17f04967@forcix> <20141107165551.GA2865@acm.acm> <20141107182111.GC2865@acm.acm> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1415386141 21595 80.91.229.3 (7 Nov 2014 18:49:01 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 7 Nov 2014 18:49:01 +0000 (UTC) Cc: emacs-devel@gnu.org, Helmut Eller , Jorgen Schaefer To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Nov 07 19:48:54 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 1Xmoaa-0003a8-RL for ged-emacs-devel@m.gmane.org; Fri, 07 Nov 2014 19:48:52 +0100 Original-Received: from localhost ([::1]:33444 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xmoaa-0002z1-Gz for ged-emacs-devel@m.gmane.org; Fri, 07 Nov 2014 13:48:52 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58291) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XmoaH-0002yi-Vt for emacs-devel@gnu.org; Fri, 07 Nov 2014 13:48:41 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XmoaA-0003fc-Cv for emacs-devel@gnu.org; Fri, 07 Nov 2014 13:48:33 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:49614) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XmoaA-0003fY-9o for emacs-devel@gnu.org; Fri, 07 Nov 2014 13:48:26 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Au4MAOatTlRLd+sd/2dsb2JhbABcgw6DYoZ+y1MEAgKBHBcBAXyEAwEBAwFWIwULCw4mEhQYDSSISwnLcgEBAQEGAQEBAR6RCAeESwWLZKY8gW+EFh+CegEBAQ X-IPAS-Result: Au4MAOatTlRLd+sd/2dsb2JhbABcgw6DYoZ+y1MEAgKBHBcBAXyEAwEBAwFWIwULCw4mEhQYDSSISwnLcgEBAQEGAQEBAR6RCAeESwWLZKY8gW+EFh+CegEBAQ X-IronPort-AV: E=Sophos;i="5.04,797,1406606400"; d="scan'208";a="96225347" Original-Received: from 75-119-235-29.dsl.teksavvy.com (HELO pastel.home) ([75.119.235.29]) by ironport2-out.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Nov 2014 13:48:25 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id 1C1DC8874; Fri, 7 Nov 2014 13:48:25 -0500 (EST) In-Reply-To: <20141107182111.GC2865@acm.acm> (Alan Mackenzie's message of "Fri, 7 Nov 2014 18:21:11 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.181 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:176551 Archived-At: > Because "(add-hook 'next-error-functions #'my-function)" is shorter than > the `add-function' variant, The text I wrote and you quoted already said that it was shorter but not enough to warrant an additional variable. So you think saving 16 characters is worth an additional hook? Based on that, I guess I should just change the naming conventions: (add-hook 'next-error-functions #'my-function) (add-f :before-until next-error-f #'my-f) Look ma! We should change all hooks to be plain foo-f variables! > along with all the other good reasons which have been posted in > this thread. None of those reasons seem to apply the question of whether it's worth adding a next-error-functions hook (remember: next-error-function exists already, since long before add-function was born). > Let me repeat my question: in what respect is the `add-function' way of > doing things superior to the conventional hook mechanism? If the answer > is "in no respect", then I would suggest that the project continue to > use hooks in preference to `add-function' functions. At this point I feel like you're confusing me with an idiot. Stefan