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) Date: Tue, 2 Aug 2016 19:00:24 +0000 Message-ID: <20160802190024.GE2328@acm.fritz.box> References: <20160731121642.GB2205@acm.fritz.box> <20160802101549.GA2328@acm.fritz.box> <83r3a7md69.fsf@gnu.org> <20160802165545.GD2328@acm.fritz.box> <83fuqnm6og.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1470164496 31189 195.159.176.226 (2 Aug 2016 19:01:36 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 2 Aug 2016 19:01:36 +0000 (UTC) User-Agent: Mutt/1.5.24 (2015-08-30) Cc: ofv@wanadoo.es, rcopley@gmail.com, rms@gnu.org, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Aug 02 21:01:31 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 1bUewP-0007qm-Gy for ged-emacs-devel@m.gmane.org; Tue, 02 Aug 2016 21:01:25 +0200 Original-Received: from localhost ([::1]:58488 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bUewM-0007pF-1b for ged-emacs-devel@m.gmane.org; Tue, 02 Aug 2016 15:01:22 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48204) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bUewC-0007mg-1I for emacs-devel@gnu.org; Tue, 02 Aug 2016 15:01:13 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bUew7-00052T-OQ for emacs-devel@gnu.org; Tue, 02 Aug 2016 15:01:11 -0400 Original-Received: from mail.muc.de ([193.149.48.3]:48833) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bUew7-00051K-DD for emacs-devel@gnu.org; Tue, 02 Aug 2016 15:01:07 -0400 Original-Received: (qmail 27299 invoked by uid 3782); 2 Aug 2016 19:01:04 -0000 Original-Received: from acm.muc.de (p548C7CD5.dip0.t-ipconnect.de [84.140.124.213]) by colin.muc.de (tmda-ofmipd) with ESMTP; Tue, 02 Aug 2016 21:01:02 +0200 Original-Received: (qmail 4897 invoked by uid 1000); 2 Aug 2016 19:00:24 -0000 Content-Disposition: inline In-Reply-To: <83fuqnm6og.fsf@gnu.org> 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:206365 Archived-At: Hello, Eli. On Tue, Aug 02, 2016 at 08:17:35PM +0300, Eli Zaretskii wrote: > > 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. Would you please characterize these circumstances in a way useful for people considering the use of before-change-functions. If you like, I can then modify Elisp's "Change Hooks" with that information. > > 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 past, 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. >From the point of view of design, what is the benefit in not calling b-c-f for that subset of circumstances? > > (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. I do want to. Currently, I'm not terribly concerned about exactly whether some change qualifies as a buffer modification or not. Just that when it does, and only half of the change hooks are called, I'd like to know why. > > 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. OK. > > > 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. It does. before-change-functions is described as: .... a list of functions to call before any buffer modification. after-change-functions is likewise described as: .... a list of functions to call after any buffer modification. . It may not explicitly say they are paired, but it says each hook is called after every modification. This naturally pairs them up. As a native English speaker, the only alternative interpretation I see (which is absurd) is that Emacs will call each of these hooks once, after any buffer modification Emacs choses. I see no way out of the conclusion that both of these hooks are to be called after each and every buffer modification. > > 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. bidi is a somewhat special case. Somebody considering the use of the change hooks should be able to rely on their documentation, without having to read and understand fileio.c and insdel.c. > > 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. You won't see them, and neither will I, because they'll be sporadic bugs with wierd consequences, maybe the odd corrupted buffer once in a blue moon. Any that make it to a bug report will end up being closed as not reproducible. Other times, something will just fail to work, the user will gently curse Emacs and try again. We can just pretend those other files are OK, I suppose. A lot of them probably actually will be. -- Alan Mackenzie (Nuremberg, Germany).