From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Unbalanced change hooks (part 2) [Documentation fix still remaining] Date: Tue, 30 Aug 2016 13:57:31 -0400 Message-ID: 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> <834m62ntqs.fsf@gnu.org> <83lgzembwt.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1472579709 5592 195.159.176.226 (30 Aug 2016 17:55:09 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 30 Aug 2016 17:55:09 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Aug 30 19:55:05 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 1benFY-0000tr-Gn for ged-emacs-devel@m.gmane.org; Tue, 30 Aug 2016 19:55:04 +0200 Original-Received: from localhost ([::1]:50544 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1benFW-0004qB-6d for ged-emacs-devel@m.gmane.org; Tue, 30 Aug 2016 13:55:02 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57491) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1benFM-0004oj-Hz for emacs-devel@gnu.org; Tue, 30 Aug 2016 13:54:53 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1benFI-0008FC-Ig for emacs-devel@gnu.org; Tue, 30 Aug 2016 13:54:52 -0400 Original-Received: from [195.159.176.226] (port=44782 helo=blaine.gmane.org) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1benFI-0008Di-Av for emacs-devel@gnu.org; Tue, 30 Aug 2016 13:54:48 -0400 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1benF8-0006ng-Vs for emacs-devel@gnu.org; Tue, 30 Aug 2016 19:54:38 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 42 Original-X-Complaints-To: usenet@blaine.gmane.org Cancel-Lock: sha1:7fHZ1uQc4oEBxaazoxHZ/XyjTWs= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 195.159.176.226 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:206982 Archived-At: >> > 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. >> Actually, we do have some idea beforehand, as evidenced by the fact that >> we call b-c-f with valid data. It's just that after the fact we have >> a more precise knowledge of what has actually been changed, so a-c-f can >> give more precise bounds. > I was under the impression that Phillip wanted the data be accurate, > not just valid. More precise (i.e. tighter bounds) is better, but valid is indispensable (I used "valid" to mean that every change is covered by the bounds, even though those bounds may be too lose. I consider "invalid" to be a plain bug, as in insert-file-contents, for example). In Phillip's case he'd prefer to have suboptimal data than mispaired data since in the mispaired case he just falls back to "redo everything", which is equivalent to calling b/a-c-f with point-min/point-max. So the message you quoted just pointed out that as long as b/a-c-f are paired (actually, you just need the guarantee that to each b-c-f corresponds at most one a-c-f), you can manually make those pairs "proper" (i.e. with identical bounds) inside your own a-c-f. So I'm pretty sure he's more concerned about "proper pairing" than about "utmost tightness of the bounds". > Because if validity is the only requirement, we could always call the > before-change hook with the limits of the entire buffer, and be done. > Clearly, that would not be very useful, to say the least. Indeed. But in the case of subst-chars-in-region, what we pass to b-c-f is suboptimal but better than point-min/max, so there's a useful middle point between the difficult "tightest bound" and the degenerate "just pass point-min/max". Stefan