From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.devel Subject: Re: Unbalanced change hooks (part 2) [Documentation fix still remaining] Date: Tue, 30 Aug 2016 11:55:41 -0700 Message-ID: References: <83inujbpek.fsf@gnu.org> <20160830171222.GA6672@acm.fritz.box> <5857ab7e-e85c-c6ae-ba1a-b1337ae57f2c@dancol.org> <83fupmm9ul.fsf@gnu.org> <67e1e007-c944-b91e-6c4b-b06b51beddc1@dancol.org> <20160830180139.GC6672@acm.fritz.box> <0d2edb1c-8b51-8114-d121-386322b1a1f6@dancol.org> <20160830183009.GE6672@acm.fritz.box> <20160830184749.GF6672@acm.fritz.box> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1472583373 6047 195.159.176.226 (30 Aug 2016 18:56:13 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 30 Aug 2016 18:56:13 +0000 (UTC) User-Agent: K-9 Mail for Android Cc: Eli Zaretskii , monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Aug 30 20:56:09 2016 Return-path: Envelope-to: ged-emacs-devel@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 1beoCc-0000q2-KM for ged-emacs-devel@m.gmane.org; Tue, 30 Aug 2016 20:56:06 +0200 Original-Received: from localhost ([::1]:50777 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1beoCa-0008Fg-Ao for ged-emacs-devel@m.gmane.org; Tue, 30 Aug 2016 14:56:04 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47389) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1beoCS-0008Fb-In for emacs-devel@gnu.org; Tue, 30 Aug 2016 14:55:57 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1beoCR-00058o-NN for emacs-devel@gnu.org; Tue, 30 Aug 2016 14:55:56 -0400 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:54896) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1beoCM-000588-JA; Tue, 30 Aug 2016 14:55:50 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Message-ID:CC:To:Date:From:Subject:Content-Type:Content-Transfer-Encoding:MIME-Version:References:In-Reply-To; bh=8+ivgWdZzudu5mUjUjHJNZ60psSp6hfQu0ltKTQUZSg=; b=Zttn/zpPkP1HiOuxUviiBIKWmnmdHN5ATNRP3G/Xdm7ID4Xjr6bgUdJyGKGtmkBd2q3ENqNeEdwQdZBfamo7Ysc5MbHcZVgKwjaYbZzlL2dn+hi0LazSaCwzpmNCCk56aKUeJBkafjb6qBGN+lvIr8arIXOf6oDCA8xvj/i7ikOTb6w173xAr8BT8HmjwTa1Z7ElhVTdrT0DFWFDD/Tm2UcTGdO+RlXqXxs2BBIrX8uVYM0xls9DnU3Ign8Ack77ZqqLImTWazzRKVl5KoXdC5eIyW5cLLr3zt6lz3rTA5VJs/jdyzeypH5bv0GmsV1jhjt06U+4mMHfDiTkC3mxMw==; Original-Received: from [73.109.62.216] (helo=[10.228.92.212]) by dancol.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1beoCK-0007rR-Mr; Tue, 30 Aug 2016 11:55:48 -0700 In-Reply-To: <20160830184749.GF6672@acm.fritz.box> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2600:3c01::f03c:91ff:fedf:adf3 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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" Xref: news.gmane.org gmane.emacs.devel:206997 Archived-At: On August 30, 2016 11:47:49 AM PDT, Alan Mackenzie wrote: >Hello, Daniel. > >On Tue, Aug 30, 2016 at 11:32:42AM -0700, Daniel Colascione wrote: > > >> On August 30, 2016 11:30:09 AM PDT, Alan Mackenzie >wrote: > >[ .... ] > >> >> Programs need to be written for the world we inhabit, not the one >> >> we want. Relying on behavior that's usually but not always the >case >> >> is antithetical to software robustness. > >We build error handling into software. Coping with non-matching b-c-f >and a-c-f calls is simply error handling. > >> >Coming back to the concrete, your proposed way of expressing things >> >would prevent future hackers from using b-c-f and a-c-f together the >> >way that we do. Is that what you want? > >> It doesn't prevent them per second: it just forces them to be more >careful. > >Your wording would prevent such use, so clearly does it express that >b-c-f and a-c-f frequently don't match. > >> I'd prefer that these hooks work the way we both want, but if that's >> not the case, I'd rather not mislead developers. It's not the >> documentation that prevents this use, but the Emacs core > >CC Mode works. The Emacs core does not prevent it working. Nor does >it >prevent your or Phillip's software from working. > >You evaded the question, so I'll put it to you again: do you want to >prevent future hackers from using b-c-f and a-c-f together the way we >do? Yes, because the approach we use today is broken and there's little hope in fixing it. The language in the documentation doesn't change what Emacs does. I don't understand what's so hard to see. You want to lead developers into writing code against an Emacs that doesn't exist