From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.devel Subject: Re: Unbalanced change hooks (part 2) [Documentation fix still remaining] Date: Tue, 30 Aug 2016 10:27:45 -0700 Message-ID: <5857ab7e-e85c-c6ae-ba1a-b1337ae57f2c@dancol.org> References: <20160811112951.GA2154@acm.fritz.box> <7e1478b6-cf00-fcbf-8c24-43bdaa57e2b6@dancol.org> <415d1cca-f32c-624e-a4be-9aadcf8a0f17@dancol.org> <83inujbpek.fsf@gnu.org> <20160830171222.GA6672@acm.fritz.box> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1472578095 32093 195.159.176.226 (30 Aug 2016 17:28:15 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 30 Aug 2016 17:28:15 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Alan Mackenzie , Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Aug 30 19:28:11 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 1bempV-0007dP-7J for ged-emacs-devel@m.gmane.org; Tue, 30 Aug 2016 19:28:09 +0200 Original-Received: from localhost ([::1]:50367 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bempS-00022m-TP for ged-emacs-devel@m.gmane.org; Tue, 30 Aug 2016 13:28:06 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46081) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bempL-0001vN-18 for emacs-devel@gnu.org; Tue, 30 Aug 2016 13:28:00 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bempE-0000zt-Vg for emacs-devel@gnu.org; Tue, 30 Aug 2016 13:27:57 -0400 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:53818) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bempE-0000zd-HM; Tue, 30 Aug 2016 13:27:52 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:Cc:References:To:Subject; bh=ocdzhfVqPUknDPtj0IA+eZdc7bCqzu64uBVnvWkacus=; b=BOEEcWK+Ad3CnLcRprB2zwJ0KgCs/FGm8yJVPQPtUdhDjLeSLF9taQ434kfD61BoaE3rhoXmghGDO49geUHsG5eei7ULXgYjvKMtdUGdGWwxGKUV6NAAdfBI63XWhJ4OAkc9EkPYldN3OJgWO4uc8wCow3JPIVkyKyCwPB9/vZ0PW/lKmgtQ3LBqfpUsieQpzui0FbhzsQbwylaMs5Lb/mU+HvPeMcvk2LYcqn6mR2a4FV7tGLTDCPWimPS/21r76LWl/MPbLgxCNllac9eHSbm8YT0VTt2broTMGlNdemFwtnlV9AXqwb4WdlM2qTRGEBfEKLGv3KAiz5y2DbcpgQ==; Original-Received: from c-73-97-199-232.hsd1.wa.comcast.net ([73.97.199.232] helo=[192.168.1.173]) by dancol.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1bempB-0007Cn-Dn; Tue, 30 Aug 2016 10:27:49 -0700 In-Reply-To: <20160830171222.GA6672@acm.fritz.box> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2600:3c01::f03c:91ff:fedf:adf3 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:206973 Archived-At: On 08/30/2016 10:12 AM, Alan Mackenzie wrote: > Hello, Eli. > > On Mon, Aug 29, 2016 at 05:50:11PM +0300, Eli Zaretskii wrote: >>> From: Daniel Colascione >>> Date: Sun, 28 Aug 2016 20:18:32 -0700 > >>> Please trust me that the documentation misleads. > >> You are welcome to suggest more accurate wording that describes the >> current implementation. > > I think it's only fair to point out that I did precisly this almost > three weeks ago (on 2016-08-10) and the welcome my efforts got was > somewhat less than wholeheartedly warm. > > The current documentation misleads in asserting that b-c-f and a-c-f > cannot be used together in balanced pairs. They most assuredly can, > with the exception of a tiny number of rarely occurring cases. If this > were not true, CC Mode would not work at all. > > Using b-c-f and a-c-f together is an essential technique - there are > things that cannot be done without it, or at least not in any reasonable > manner. In this sense, maintaining a duplicate shadow buffer, or > scanning from BOB at every buffer change, or maintaining a separate > record of all text properties on a buffer, don't fall into the category > of reasonable, from my point of view. > > Eliminating this technique from Emacs, whether by "polluting" the source > to stop it working altogether (as suggested by Stefan), or by forbidding > it in the documentation, has the effect of making Emacs a less powerful > programming system. I don't think this is what any of us should want. > > [ .... ] How about this? I think this revised text captures the intent of the current implementation and preserves the ability to use b-c-f and a-c-f together. (The current revert-buffer behavior is just a bug and is contrary to my proposed documentation.) diff --git a/doc/lispref/text.texi b/doc/lispref/text.texi index 213eec9..6511da8 100644 --- a/doc/lispref/text.texi +++ b/doc/lispref/text.texi @@ -4798,6 +4798,13 @@ Change Hooks has been changed is always the current buffer when the function is called. +The region given to each of these functions is a conservative +approximation of the region about to changed. After running the +before-change-functions, Emacs will make zero or more fine-grained +buffer changes and run after-change-functions for each. Do not expect +before-change-functions and after-change-functions to be called in +balanced pairs. + The length of the old text is the difference between the buffer positions before and after that text as it was before the change. As for the changed text, its length is simply the difference between the @@ -4809,14 +4816,14 @@ Change Hooks as changes in buffers created by Emacs internally for certain jobs, that should not be visible to Lisp programs. - Do @emph{not} expect the before-change hooks and the after-change -hooks be called in balanced pairs around each buffer change. Also -don't expect the before-change hooks to be called for every chunk of -text Emacs is about to delete. These hooks are provided on the -assumption that Lisp programs will use either before- or the -after-change hooks, but not both, and the boundaries of the region -where the changes happen might include more than just the actual -changed text, or even lump together several changes done piecemeal. + Do @emph{not} expect the before-change hooks and the after-change +hooks be called in balanced pairs around each buffer change. +The before-change-functions region is a conservative bound on the zero +or more fine-grained changes to follow. Emacs informs user code about +the actual changes to the buffer through calls to +after-change-functions; these fine-grained changes will always fall +inside the broad change region Emacs describes by calling +before-change-functions. @defmac combine-after-change-calls body@dots{} The macro executes @var{body} normally, but arranges to call the diff --git a/src/buffer.c b/src/buffer.c index 24c997f..60e448f 100644 --- a/src/buffer.c +++ b/src/buffer.c @@ -6027,6 +6027,13 @@ the beginning and end of the range of old text to be changed. \(For an insertion, the beginning and end are at the same place.) No information is given about the length of the text after the change. +The region given to each of these functions is a conservative +approximation of the region about to changed. After running the +before-change-functions, Emacs will make zero or more fine-grained +buffer changes and run `after-change-functions' for each. Do not +expect `before-change-functions' and `after-change-functions' to be +called in balanced pairs. + Buffer changes made while executing the `before-change-functions' don't call any before-change or after-change functions. That's because `inhibit-modification-hooks' is temporarily set non-nil.