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 16:55:45 +0000 Message-ID: <20160802165545.GD2328@acm.fritz.box> References: <20160731121642.GB2205@acm.fritz.box> <20160802101549.GA2328@acm.fritz.box> <83r3a7md69.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 1470157048 26203 195.159.176.226 (2 Aug 2016 16:57:28 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 2 Aug 2016 16:57:28 +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 18:57:24 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 1bUd0M-0006Tv-Fg for ged-emacs-devel@m.gmane.org; Tue, 02 Aug 2016 18:57:22 +0200 Original-Received: from localhost ([::1]:57781 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bUd0J-0003vl-4b for ged-emacs-devel@m.gmane.org; Tue, 02 Aug 2016 12:57:19 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54619) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bUczX-0003tj-Tc for emacs-devel@gnu.org; Tue, 02 Aug 2016 12:56:33 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bUczS-0001ZP-9u for emacs-devel@gnu.org; Tue, 02 Aug 2016 12:56:30 -0400 Original-Received: from mail.muc.de ([193.149.48.3]:16924) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bUczS-0001Yx-0Z for emacs-devel@gnu.org; Tue, 02 Aug 2016 12:56:26 -0400 Original-Received: (qmail 5140 invoked by uid 3782); 2 Aug 2016 16:56:25 -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 18:56:23 +0200 Original-Received: (qmail 4350 invoked by uid 1000); 2 Aug 2016 16:55:45 -0000 Content-Disposition: inline In-Reply-To: <83r3a7md69.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:206359 Archived-At: Hello, Eli. On Tue, Aug 02, 2016 at 05:57:18PM +0300, Eli Zaretskii wrote: > > Date: Tue, 2 Aug 2016 10:15:49 +0000 > > From: Alan Mackenzie > > Cc: ofv@wanadoo.es, rcopley@gmail.com, emacs-devel@gnu.org > > I think the particular instance IS grossly and conspicuously bad. The > > resulting code is so difficult to maintain that (i) our > > before-change-functions/after-change-functions mechanism is broken, in > > that the b-c-f hook is only called for some changes, not all changes; > > (ii) Eli Z. has forcefully declined my offer to fix this, on the grounds > > that the pertinent code (in .../src/insdel.c) is so fragile that any > > attempt to fix it will inevitably introduce hidden bugs elsewhere. > I'm sorry, but the above doesn't match my views and opinions on this > matter, so I would like to express them as clearly as possible: > (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. I have read the code, and what I see is not "works as designed" but "failure consequently to adhere to the design". b-c-f is used infrequently enough that it took CC Mode to expose the failure. > (ii) I never said the code which implements the support for these > hooks is "so fragile that any attempt to fix it will inevitably > introduce hidden bugs". The code in insdel.c is rock-solid, > and I feel confident when I make changes there (as indeed I did > several times during the last year). What I fear is not the > fragility of insdel.c, it's the unintended consequences of > changing the aspects of it and of its callers that are clearly > against the original design. 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. (That's leaving aside precisely what qualifies as a "buffer modification" and what doesn't.) 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. > 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 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. 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. > > This `prepare' parameter is central to the difficulties of fixing/not > > being able to fix the b-c-f/a-c-f mechanism. > I don't think the mechanism needs fixing. We'll have to carry on disagreeing about this. For what it's worth, I accept that it's not going to get fixed. > The intent of the 'prepare' parameter is quite clear, and is > consistently followed by all the callers of these functions. I don't find the intent clear, since prepare_to_modify_buffer is a mishmash of miscellaneous things, rather than a "do one thing and do it well". If this `prepare' mechanism hadn't been used, but instead the functions simply called where they were needed, then adding in the b-c-f calls could have been trivial. > What we need is find the best way of fixing CC Mode based on this or > some other mechanism. Yes. CC Mode and the other 13 files.el too. -- Alan Mackenzie (Nuremberg, Germany).