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 22:25:45 +0300 Message-ID: <83d1lrm0qu.fsf@gnu.org> References: <20160731121642.GB2205@acm.fritz.box> <20160802101549.GA2328@acm.fritz.box> <83r3a7md69.fsf@gnu.org> <20160802165545.GD2328@acm.fritz.box> <83fuqnm6og.fsf@gnu.org> <20160802190024.GE2328@acm.fritz.box> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1470166031 19100 195.159.176.226 (2 Aug 2016 19:27:11 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 2 Aug 2016 19:27:11 +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 21:27:07 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 1bUfLG-0004ZR-9W for ged-emacs-devel@m.gmane.org; Tue, 02 Aug 2016 21:27:06 +0200 Original-Received: from localhost ([::1]:58586 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bUfLC-0002Zg-Sx for ged-emacs-devel@m.gmane.org; Tue, 02 Aug 2016 15:27:02 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57697) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bUfKf-0002ZK-Cw for emacs-devel@gnu.org; Tue, 02 Aug 2016 15:26:30 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bUfKa-0005LT-Vu for emacs-devel@gnu.org; Tue, 02 Aug 2016 15:26:28 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:36794) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bUfKa-0005Kq-SA; Tue, 02 Aug 2016 15:26:24 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2666 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bUfKP-0004jq-Uj; Tue, 02 Aug 2016 15:26:16 -0400 In-reply-to: <20160802190024.GE2328@acm.fritz.box> (message from Alan Mackenzie on Tue, 2 Aug 2016 19:00:24 +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:206366 Archived-At: > Date: Tue, 2 Aug 2016 19:00:24 +0000 > Cc: rms@gnu.org, ofv@wanadoo.es, rcopley@gmail.com, emacs-devel@gnu.org > From: Alan Mackenzie > > > > 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. Let's leave this for later, and focus on solving the immediate problem at hand. > > 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? I'm not yet 100% sure, but I'm getting there. In any case, the logic is very clear, although its rationale I only half-understand for now. > > 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. Like I said, sticking to such a strict interpretation would cause our code to be unnecessarily much too complex. The modification hooks are supposed to tell you that changes are about to be, or have been, made in a region, but that doesn't necessarily mean you will have a single call of before- and after- hook for each of the partial changes.