From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.devel Subject: Re: Multiple next-error sources Date: Fri, 07 Nov 2014 18:22:34 +0000 Message-ID: <545D0DEA.1090003@dancol.org> 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: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="0VBQlQLMPTbeJDHViCRCDWlKSBPcIqk0r" X-Trace: ger.gmane.org 1415384589 26811 80.91.229.3 (7 Nov 2014 18:23:09 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 7 Nov 2014 18:23:09 +0000 (UTC) Cc: Jorgen Schaefer , Helmut Eller , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Nov 07 19:23:03 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 1XmoBZ-0003FI-4d for ged-emacs-devel@m.gmane.org; Fri, 07 Nov 2014 19:23:01 +0100 Original-Received: from localhost ([::1]:33341 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XmoBY-0006Ph-Lm for ged-emacs-devel@m.gmane.org; Fri, 07 Nov 2014 13:23:00 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52691) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XmoBQ-0006PV-F5 for emacs-devel@gnu.org; Fri, 07 Nov 2014 13:22:58 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XmoBK-0003YW-2f for emacs-devel@gnu.org; Fri, 07 Nov 2014 13:22:52 -0500 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:39477) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XmoBJ-0003YQ-PO for emacs-devel@gnu.org; Fri, 07 Nov 2014 13:22:46 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=Ynu0ZA3BG3Zdgd15ZTsN1NWACC+lp78fkXjAvpiBiVM=; b=CwbXRxphW986gz6yvW6o1eG7w+M37Q+h8qZ/YvACvINUamJHpKa4eQ2hLBRZ3ozNoStkUGkC6WjTuVeK3fN6kyvzAFW0J7DTI6kYCrVZWhkbtj7IT2im4Fjp82eUx2Jbg/dsyNXrmh+rnBBI47wCa0nK+sjUKE38iNyXpOW9/16ftx291bRK+5TE0QiMR6MDn67brD6H8co2JsrGVJ+sZ3RMlsBTW8igMJph2eH+CHbNHf1Uh5avj1YuT7Zwx7a479gLkurZ6pBeGNE6ZTIrO6xoBDBI4C4fVvhVMQdKe+Tw05tQzd6RG98flIKQnjlWQ6icQsODoEIvOxCa8DIFJg==; Original-Received: from [199.201.65.2] (helo=[172.30.31.126]) by dancol.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84) (envelope-from ) id 1XmoBG-0004Oz-Pp; Fri, 07 Nov 2014 10:22:43 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2600:3c01::f03c:91ff:fedf:adf3 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:176548 Archived-At: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --0VBQlQLMPTbeJDHViCRCDWlKSBPcIqk0r Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 11/07/2014 06:17 PM, Stefan Monnier wrote: >> The many add-function composition modes are useful for advice, but >> counterproductive for customization points: the great variety of optio= ns >> 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 th= at >> delegates to a global value. >=20 > 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. >=20 > As I said: >=20 > 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?). >=20 > 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) With the existing system, the hook runner gets to specify the "method combiner" (to use CLOS terminology); with add-function, each hook gets to specify a different method combiner. It's that possibility that bothers me, although the lack of a good default increases the risk of harmful diversity here. Can you come up with a concrete example of an instance where a hook-specified method combiner is actually useful? > (add-function nil next-error-function #'my-function) >=20 > and add-function would know to use :before-until. >=20 >> I don't see any compelling reason to avoid conventional hooks. >=20 > The extra flexibility. I'm not yet convinced that the flexibility is worth the cost. --0VBQlQLMPTbeJDHViCRCDWlKSBPcIqk0r Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJUXQ3qAAoJEN4WImmbpWBlIccP/3qKKO1icHMt/oNG/kPeFUxq Yp3YI7tlzuJ2iosub1NA+Zz1mSR5pbHVYWilniG2vFeDnD7EqgxOD2Lff0/0itYv SfzzIdPs5OZriaaUDJuOKhiD/1TYXKhPDdV4wOjuUdNbZDIp8987mC1kthWm/7PK xXiY6UsF672f28XlhQKaelmkx3TL06qg3ORY4WiLhXmAIEz9CO/74qt/cm0QJ8aW tIggGTIK4H/eYFLgQuiqybzV3f1WWkVEG4C1qQ/kHO+rb3a8835HvrJ6zLmT+zw6 ECVUo7PWOVe9VZWx61jUWVU8haxymbAQTdejXmHO+Z72Xg54pRn42Zr/FtkkA6H+ qbmBKLmy3aCqrcSV3Pta+6hgaE4URkEhfYiMRozjcv241GTKklLcdV+Eo51Y0Ywg vRA3+36/oHIru+MKXxyrf7F854CbqOLkTAUlUqVksjrVHgqda04NBeziq4BoDwcn iZt3GSCiuFCg6zABrOXn8Wd3JEe2GPIKhX9L00Hrd1ApFohoPf9EJ5WHIcYfP/by NjXOhMhuAmNo6W/9zLzzqDLiS9E8lITCnxOWt5sJQ7m0/ZBhyTSrcTPZ2BZ3PuXV lmvr1MGXoB5KzpUNojUxfbvIft0TWYRCTvGERVtAvjxx8d7ac4vGs4Lt6PHRPKH5 mGRPBLKFyRIsSLNDvAQk =4ISo -----END PGP SIGNATURE----- --0VBQlQLMPTbeJDHViCRCDWlKSBPcIqk0r--