From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Unbalanced change hooks (part 2) Date: Tue, 02 Aug 2016 20:17:35 +0300 Message-ID: <83fuqnm6og.fsf@gnu.org> References: <20160731121642.GB2205@acm.fritz.box> <20160802101549.GA2328@acm.fritz.box> <83r3a7md69.fsf@gnu.org> <20160802165545.GD2328@acm.fritz.box> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1470159057 29291 195.159.176.226 (2 Aug 2016 17:30:57 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 2 Aug 2016 17:30:57 +0000 (UTC) Cc: ofv@wanadoo.es, rcopley@gmail.com, rms@gnu.org, emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Aug 02 19:30:52 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 1bUdWh-0007G7-7j for ged-emacs-devel@m.gmane.org; Tue, 02 Aug 2016 19:30:47 +0200 Original-Received: from localhost ([::1]:57950 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bUdWd-0001Qx-Mn for ged-emacs-devel@m.gmane.org; Tue, 02 Aug 2016 13:30:43 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:32828) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bUdKM-0007Ye-4y for emacs-devel@gnu.org; Tue, 02 Aug 2016 13:18:03 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bUdKH-0007Ri-3O for emacs-devel@gnu.org; Tue, 02 Aug 2016 13:18:01 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:35234) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bUdKG-0007Rd-WF; Tue, 02 Aug 2016 13:17:57 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2577 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bUdK9-0000up-GL; Tue, 02 Aug 2016 13:17:50 -0400 In-reply-to: <20160802165545.GD2328@acm.fritz.box> (message from Alan Mackenzie on Tue, 2 Aug 2016 16:55:45 +0000) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e 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:206360 Archived-At: > Date: Tue, 2 Aug 2016 16:55:45 +0000 > Cc: rms@gnu.org, ofv@wanadoo.es, rcopley@gmail.com, emacs-devel@gnu.org > From: Alan Mackenzie > > > (i) I disagree that the modification-hooks mechanism is broken. It > > works as designed; if you read the code, you see that very > > clearly. (Alan disagrees with the design, but that's another > > matter.) > > I thought we'd already agreed that no rational design would omit the > before-change-hooks call from an arbitrary subset of changes. No, I don't think there was such an agreement. The set of changes for which before-change-functions are not called is not arbitrary. > To me it's perfectly clear the original design was, for each buffer > modification there is exactly one invocation of b-c-f and one of a-c-f. If such an original design existed in the distant future, it was long ago (as in 20 years or more) replaced with what we basically see today, where every change always triggers a call to after-change-functions, but only some (the majority, but not all) trigger the call to before-change-functions. > (That's leaving aside precisely what qualifies as a "buffer > modification" and what doesn't.) I don't think it can be left aside, if you want to understand the rationale. > The fact that we're too scared to make the simple changes to adhere to > the design (as documented in the Elisp manual) is precisely what > "fragile code" means. And "call b-c-f for all changes" should be a > simple change. We are not scared. We (I) simply don't want to do that, at least not yet. When non-trivial changes were needed in insdel.c, they were done without fear, including lately by yours truly. > > Doing that for introducing some important new feature would be > > justified, but doing that because CC Mode made incorrect > > assumptions about how this mechanism works is IMO wrong. > > CC Mode didn't make incorrect assumptions - it followed rigourously the > feature as documented in the Elisp manual. The ELisp manual doesn't promise that these hooks will be called in balanced pairs. > The implication of your last paragraph is that before using any core > feature, a Lisp hacker should first examine its implementation to > make sure the documentation is correct. This is absurd. No, that's life. What do you think I did before embarking on writing the bidirectional display? A lot of code reading, a lot of discussions with Gerd Moellmann, more code reading, etc. All that was needed even though the display engine has much more detailed overview comments than almost any other part of Emacs. > Anyhow, it's not just CC Mode. As already discussed, there are 13 other > files which use before-change-functions, and some of these uses are > going to assume it works as documented, just as CC Mode did. Sporadic > failures are going to occur in some of these other places, due to those > hook functions sometimes not being called. I will believe that when I see specific bug reports about those other packages.