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: Mon, 08 Aug 2016 18:38:08 +0300 Message-ID: <83oa53i84f.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> <83d1lrm0qu.fsf@gnu.org> <20160807211626.GA3690@acm.fritz.box> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1470674110 2994 195.159.176.226 (8 Aug 2016 16:35:10 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 8 Aug 2016 16:35:10 +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 Mon Aug 08 18:35:06 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 1bWnVv-000817-Gj for ged-emacs-devel@m.gmane.org; Mon, 08 Aug 2016 18:34:55 +0200 Original-Received: from localhost ([::1]:58570 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bWnVs-0004SP-BM for ged-emacs-devel@m.gmane.org; Mon, 08 Aug 2016 12:34:52 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52441) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bWmdS-0006q7-Kt for emacs-devel@gnu.org; Mon, 08 Aug 2016 11:38:39 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bWmdN-0006Ne-Jl for emacs-devel@gnu.org; Mon, 08 Aug 2016 11:38:37 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:34343) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bWmdN-0006NX-GE; Mon, 08 Aug 2016 11:38:33 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4667 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bWmdE-0001MS-Sf; Mon, 08 Aug 2016 11:38:25 -0400 In-reply-to: <20160807211626.GA3690@acm.fritz.box> (message from Alan Mackenzie on Sun, 7 Aug 2016 21:16:27 +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:206487 Archived-At: > Date: Sun, 7 Aug 2016 21:16:27 +0000 > Cc: rms@gnu.org, ofv@wanadoo.es, rcopley@gmail.com, emacs-devel@gnu.org > From: Alan Mackenzie > > 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? Not easily, not without some bookkeeping. > 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? Yes. > 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? I'm extremely uneasy about using undo for such purposes. You have already discovered one reason why. In general, applications are free to manipulate the undo records as they see fit, so you cannot expect that to work reliably.