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: Sun, 7 Aug 2016 21:16:27 +0000 Message-ID: <20160807211626.GA3690@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> <20160802190024.GE2328@acm.fritz.box> <83d1lrm0qu.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 1470604712 19624 195.159.176.226 (7 Aug 2016 21:18:32 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 7 Aug 2016 21:18:32 +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 Sun Aug 07 23:18: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 1bWVSc-0002vJ-0U for ged-emacs-devel@m.gmane.org; Sun, 07 Aug 2016 23:18:18 +0200 Original-Received: from localhost ([::1]:53877 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bWVSY-0003DF-KQ for ged-emacs-devel@m.gmane.org; Sun, 07 Aug 2016 17:18:14 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39131) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bWVRX-0001mu-37 for emacs-devel@gnu.org; Sun, 07 Aug 2016 17:17:12 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bWVRU-00085N-0P for emacs-devel@gnu.org; Sun, 07 Aug 2016 17:17:11 -0400 Original-Received: from mail.muc.de ([193.149.48.3]:41243) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bWVRT-00084V-KB for emacs-devel@gnu.org; Sun, 07 Aug 2016 17:17:07 -0400 Original-Received: (qmail 24310 invoked by uid 3782); 7 Aug 2016 21:17:00 -0000 Original-Received: from acm.muc.de (p548C79F0.dip0.t-ipconnect.de [84.140.121.240]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 07 Aug 2016 23:17:00 +0200 Original-Received: (qmail 3796 invoked by uid 1000); 7 Aug 2016 21:16:27 -0000 Content-Disposition: inline In-Reply-To: <83d1lrm0qu.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:206469 Archived-At: Hello, Eli. On Tue, Aug 02, 2016 at 10:25:45PM +0300, Eli Zaretskii wrote: > > 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. You say the set of changes for which b-c-f isn't called isn't arbitrary. That means it follows some sort of scheme. Could a major mode, in an after-change function use this scheme to determine whether before-change-functions was called, for some particular change? (This won't be needed if my other idea (below) is workable.) > > > 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. OK. > > > 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. OK, things are as they are. I currently believe that most changes trigger before-change-functions but EVERY CHANGE triggers after-change-functions. Can you confirm that this is the case? If it isn't, could we fix Emacs so that it is? If it is indeed the case, then a solution to the problem would be to check that before- and after-c-f are called alternately. Any time after-c-f is called twice in a row, we could reverse the change just made (using the undo list), invoke before-c-f, redo the change, then let after-c-f continue to completion. If necessary, we can temporarily enable undo in a pre-command-hook function. Given how rarely b-c-f isn't called, this would have a negligible effect on performance and store usage. This would be a better solution than reversing and redoing every change. It will also work for older Emacsen, and will be relatively easy to implement. It will be much easier to implement than a solution which doesn't use before-change-functions at all. What do you think about this? -- Alan Mackenzie (Nuremberg, Germany).