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:17:09 -0500 Message-ID: References: <20141102151524.0d9c665c@forcix> <20141102172944.0f7944e3@forcix> <20141103084433.12117c03@forcix> <86fvdwgxqs.fsf@yandex.ru> <20141106180815.207bf7ad@forcix> <20141107104914.17f04967@forcix> <545CE443.50502@dancol.org> <545CEE87.3060909@dancol.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1415384260 20726 80.91.229.3 (7 Nov 2014 18:17:40 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 7 Nov 2014 18:17:40 +0000 (UTC) Cc: Jorgen Schaefer , Helmut Eller , emacs-devel@gnu.org To: Daniel Colascione Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Nov 07 19:17:29 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 1Xmo6C-0006Aq-69 for ged-emacs-devel@m.gmane.org; Fri, 07 Nov 2014 19:17:28 +0100 Original-Received: from localhost ([::1]:33315 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xmo6B-0004dc-LD for ged-emacs-devel@m.gmane.org; Fri, 07 Nov 2014 13:17:27 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51556) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xmo62-0004cH-4J for emacs-devel@gnu.org; Fri, 07 Nov 2014 13:17:25 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xmo5u-0001RC-Jk for emacs-devel@gnu.org; Fri, 07 Nov 2014 13:17:18 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:37634) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xmo5u-0001Qy-Fv for emacs-devel@gnu.org; Fri, 07 Nov 2014 13:17:10 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Au4MAOatTlRLd+sd/2dsb2JhbABcgw6DYoZ+y1MEAgKBHBcBAXyEAwEBAwFWIwULCw4mEhQYDSSISwnLcgEBAQEGAQEBAR6KcIYYB4RLBYtkhAWiN4FvhBYfgnoBAQE X-IPAS-Result: Au4MAOatTlRLd+sd/2dsb2JhbABcgw6DYoZ+y1MEAgKBHBcBAXyEAwEBAwFWIwULCw4mEhQYDSSISwnLcgEBAQEGAQEBAR6KcIYYB4RLBYtkhAWiN4FvhBYfgnoBAQE X-IronPort-AV: E=Sophos;i="5.04,797,1406606400"; d="scan'208";a="96223163" 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:17:09 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id 981738874; Fri, 7 Nov 2014 13:17:09 -0500 (EST) In-Reply-To: <545CEE87.3060909@dancol.org> (Daniel Colascione's message of "Fri, 07 Nov 2014 16:08:39 +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:176546 Archived-At: > The many add-function composition modes are useful for advice, but > counterproductive for customization points: the great variety of options > makes it hard to reason about the effect any particular effect. With a > hook, you have a simple list of functions, possibly with a sentinel that > delegates to a global value. It's a tradeoff, indeed. It gives you extra flexibility (instead of the hook specifying that the functions will be composed with "until-failure", each and every function gets to decide how it's composed with the others), which of course means more choices to make. As I said: 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?). So maybe we should arrange that the "typical" way to compose the functions for a particular variable be specified along with that variable, so that you can use (for example) (add-function nil next-error-function #'my-function) and add-function would know to use :before-until. > I don't see any compelling reason to avoid conventional hooks. The extra flexibility. > They've worked for many years. Obviously not completely, since there are occurrences of foo-function variables, and for several of those, packages have had to "stash the previous value, then install their own" on those vars, with latent bugs when several packages do that on the same var. > Requiring add-function for some customization and add-hook for others > will only confuse users. Yes, I'm not particularly happy about that part, admittedly. Stefan