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 19:58:26 +0300 Message-ID: <83lgzembwt.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> <834m62ntqs.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1472576334 25934 195.159.176.226 (30 Aug 2016 16:58:54 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 30 Aug 2016 16:58:54 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Aug 30 18:58:51 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 1bemN5-00064l-VB for ged-emacs-devel@m.gmane.org; Tue, 30 Aug 2016 18:58:48 +0200 Original-Received: from localhost ([::1]:50244 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bemN3-00045o-M1 for ged-emacs-devel@m.gmane.org; Tue, 30 Aug 2016 12:58:45 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37503) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bemMy-00045V-1R for emacs-devel@gnu.org; Tue, 30 Aug 2016 12:58:41 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bemMt-0003D6-TY for emacs-devel@gnu.org; Tue, 30 Aug 2016 12:58:39 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:57479) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bemMt-0003D2-QO; Tue, 30 Aug 2016 12:58:35 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1770 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bemMr-0003Ak-PE; Tue, 30 Aug 2016 12:58:35 -0400 In-reply-to: (message from Stefan Monnier on Tue, 30 Aug 2016 12:01:22 -0400) 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:206967 Archived-At: > From: Stefan Monnier > Date: Tue, 30 Aug 2016 12:01:22 -0400 > > > 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. 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. > We could also change the C code to perform this "extension" of the > region passed to a-c-f so that the b-c-f region and the a-c-f region > match, but that would make the region passed to a-c-f less precise, so > those users of a-c-f which don't care about the pairing (the majority of > the users) would be penalized (tho they'd still work correctly: just > suboptimally) since there's no way for them to recover the > tighter region. Right.