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 17:57:18 +0300 Message-ID: <83r3a7md69.fsf@gnu.org> References: <20160731121642.GB2205@acm.fritz.box> <20160802101549.GA2328@acm.fritz.box> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine X-Trace: blaine.gmane.org 1470149911 21621 195.159.176.226 (2 Aug 2016 14:58:31 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 2 Aug 2016 14:58:31 +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 16:58:26 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 1bUb9G-0005Fm-7C for ged-emacs-devel@m.gmane.org; Tue, 02 Aug 2016 16:58:26 +0200 Original-Received: from localhost ([::1]:57156 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bUb9C-0005zI-UO for ged-emacs-devel@m.gmane.org; Tue, 02 Aug 2016 10:58:22 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51470) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bUb8c-0005zB-4v for emacs-devel@gnu.org; Tue, 02 Aug 2016 10:57:47 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bUb8W-0001DA-Ll for emacs-devel@gnu.org; Tue, 02 Aug 2016 10:57:45 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:33036) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bUb8W-0001D2-IB; Tue, 02 Aug 2016 10:57:40 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2466 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bUb8N-0000xv-QV; Tue, 02 Aug 2016 10:57:32 -0400 In-reply-to: <20160802101549.GA2328@acm.fritz.box> (message from Alan Mackenzie on Tue, 2 Aug 2016 10:15:49 +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:206353 Archived-At: > 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.) (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. 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. > 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. The intent of the 'prepare' parameter is quite clear, and is consistently followed by all the callers of these functions. What we need is find the best way of fixing CC Mode based on this or some other mechanism.