From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: Unbalanced change hooks (part 2) [Documentation fix still remaining] Date: Tue, 30 Aug 2016 18:47:49 +0000 Message-ID: <20160830184749.GF6672@acm.fritz.box> 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> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1472582946 9920 195.159.176.226 (30 Aug 2016 18:49:06 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 30 Aug 2016 18:49:06 +0000 (UTC) User-Agent: Mutt/1.5.24 (2015-08-30) Cc: Eli Zaretskii , monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Daniel Colascione Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Aug 30 20:49:02 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 1beo5k-00021l-8D for ged-emacs-devel@m.gmane.org; Tue, 30 Aug 2016 20:49:00 +0200 Original-Received: from localhost ([::1]:50755 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1beo5h-0005Ct-TB for ged-emacs-devel@m.gmane.org; Tue, 30 Aug 2016 14:48:57 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45290) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1beo56-0005Bf-47 for emacs-devel@gnu.org; Tue, 30 Aug 2016 14:48:21 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1beo52-0003Mx-TP for emacs-devel@gnu.org; Tue, 30 Aug 2016 14:48:20 -0400 Original-Received: from mail.muc.de ([193.149.48.3]:37830) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1beo52-0003MO-J6 for emacs-devel@gnu.org; Tue, 30 Aug 2016 14:48:16 -0400 Original-Received: (qmail 38590 invoked by uid 3782); 30 Aug 2016 18:48:15 -0000 Original-Received: from acm.muc.de (p548C605C.dip0.t-ipconnect.de [84.140.96.92]) by colin.muc.de (tmda-ofmipd) with ESMTP; Tue, 30 Aug 2016 20:48:13 +0200 Original-Received: (qmail 7248 invoked by uid 1000); 30 Aug 2016 18:47:49 -0000 Content-Disposition: inline In-Reply-To: X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de X-detected-operating-system: by eggs.gnu.org: FreeBSD 9.x X-Received-From: 193.149.48.3 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:206994 Archived-At: 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? -- Alan Mackenzie (Nuremberg, Germany).