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) [Documentation fix still remaining] Date: Tue, 30 Aug 2016 18:47:55 +0300 Message-ID: <834m62ntqs.fsf@gnu.org> References: <83inv9hkjd.fsf@gnu.org> <83h9ashfgx.fsf@gnu.org> <831t1wharr.fsf@gnu.org> <20160810161821.GB3413@acm.fritz.box> <83wpjofttf.fsf@gnu.org> <20160810185735.GD3413@acm.fritz.box> <20160811112951.GA2154@acm.fritz.box> <87a8fue656.fsf@russet.org.uk> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1472572142 9150 195.159.176.226 (30 Aug 2016 15:49:02 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 30 Aug 2016 15:49:02 +0000 (UTC) Cc: acm@muc.de, dancol@dancol.org, monnier@IRO.UMontreal.CA, emacs-devel@gnu.org To: phillip.lord@russet.org.uk (Phillip Lord) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Aug 30 17:48:52 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 1belHP-0001LL-F0 for ged-emacs-devel@m.gmane.org; Tue, 30 Aug 2016 17:48:51 +0200 Original-Received: from localhost ([::1]:49774 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1belHM-0004I5-SW for ged-emacs-devel@m.gmane.org; Tue, 30 Aug 2016 11:48:48 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40421) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1belGf-0004G8-3n for emacs-devel@gnu.org; Tue, 30 Aug 2016 11:48:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1belGa-0002cR-TR for emacs-devel@gnu.org; Tue, 30 Aug 2016 11:48:04 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:55942) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1belGa-0002cG-Q2; Tue, 30 Aug 2016 11:48:00 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1735 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1belGY-0004w7-Up; Tue, 30 Aug 2016 11:47:59 -0400 In-reply-to: <87a8fue656.fsf@russet.org.uk> (phillip.lord@russet.org.uk) 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:206948 Archived-At: > From: phillip.lord@russet.org.uk (Phillip Lord) > Date: Tue, 30 Aug 2016 14:30:13 +0100 > Cc: Alan Mackenzie , Stefan Monnier , > emacs-devel@gnu.org > > I think to really avoid the complexity for mode authors, b-c-f and a-c-f > need to not only balance, but also to be consistent. At the moment, they > are not that either -- they can signal different locations for a given > change. You are setting the bar impossibly high by expecting that. Implementing what you want would need significant changes in how the insdel functions are implemented and used. In particular, some complex changes will probably have to do things twice: once just to figure out which changes are needed, the other time to actually do that while calling the hooks in the way you want. That's because in some situations we discover the required changes as we go, and have no idea in advance what we will find. Read the code where these functions are called, and you will see what I mean. insert-file-contents as called by revert-buffer is a case in point: we don't know which parts of the old text will need to be deleted until we do the job by comparing the buffer with the file on disk; we delete each portion as we discover it. To keep this issue in its proper perspective, we have other hooks that are similarly "inconsistent". For example, window-scroll-functions can be called by the display engine any number of times during a single redisplay cycle, because the display engine many times plays "catch and loose", trying something, then falling back to some backup plan if plan A failed; but by the time it understands it needs to give up on plane A, it already have called the hooks. So I submit that this "inconsistency" is actually an inherent trait of the Emacs hooks, at least some of them, and at this point the only way to avoid that is completely rewrite the corresponding part(s) of the internals.