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 11:06:06 -0700 Message-ID: References: <7e1478b6-cf00-fcbf-8c24-43bdaa57e2b6@dancol.org> <415d1cca-f32c-624e-a4be-9aadcf8a0f17@dancol.org> <83inujbpek.fsf@gnu.org> <20160830171222.GA6672@acm.fritz.box> <5857ab7e-e85c-c6ae-ba1a-b1337ae57f2c@dancol.org> <83fupmm9ul.fsf@gnu.org> <67e1e007-c944-b91e-6c4b-b06b51beddc1@dancol.org> <20160830180139.GC6672@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 1472580390 9472 195.159.176.226 (30 Aug 2016 18:06:30 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 30 Aug 2016 18:06:30 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 Cc: Eli Zaretskii , monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Aug 30 20:06:26 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 1benQX-00022K-RT for ged-emacs-devel@m.gmane.org; Tue, 30 Aug 2016 20:06:25 +0200 Original-Received: from localhost ([::1]:50592 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1benQV-0002xR-4r for ged-emacs-devel@m.gmane.org; Tue, 30 Aug 2016 14:06:23 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34053) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1benQO-0002xJ-Ob for emacs-devel@gnu.org; Tue, 30 Aug 2016 14:06:17 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1benQK-000382-Ez for emacs-devel@gnu.org; Tue, 30 Aug 2016 14:06:15 -0400 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:54358) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1benQK-00037u-5z; Tue, 30 Aug 2016 14:06:12 -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=tpClxus2tVfCTWBlxmKhJdL8Sj0QQUw3uCN3l+ZllgI=; b=eW3eqz1Y38aedIl9DxUmToTWV/4CkOFlGW6hG3IUR6TjvmuFFdlGAKF7AKl+AwyAYZRfJL7wu19lQPD6oUeixExSuIEpH8bB63ME2TwSWkassIRmRqb72wHiQTqywFf54bKrmDCCqIZnZsHf+z8Q6fDsZ/2/N/omdGeSDKg+6B8epcvKNu56ZFDfX79WATeQm3Q+N1EgBBj8e5BddfRbGuIpmwE9eHflAuQywb/l5eNJMtAOq/arRlRkyfMNnWUAn5EuREOH7/drOZgC8lB6vF2+dmOb1jsyEXdjkmeKkkVS5BANNJhU+oCAotTFLS7Qv5ctA8RGpnOlcArpb/Q2rA==; 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 1benQH-0007V2-VQ; Tue, 30 Aug 2016 11:06:10 -0700 In-Reply-To: <20160830180139.GC6672@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:206988 Archived-At: On 08/30/2016 11:01 AM, Alan Mackenzie wrote: > Hello, Daniel. > > On Tue, Aug 30, 2016 at 10:46:44AM -0700, Daniel Colascione wrote: >> On 08/30/2016 10:42 AM, Eli Zaretskii wrote: >>>> Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org >>>> From: Daniel Colascione >>>> Date: Tue, 30 Aug 2016 10:27:45 -0700 > >>>> +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 last sentence here is repeated afterwards, for no good reason. >>> (Also, the markup is missing, but that's just an aside.) > >> I figured it was a good idea to highlight this fact directly in the >> variable documentation blob. I can add a "see below" link. > > Why are you advocating this? It is not true. You _can_ expect b-c-f and > a-c-f to be balanced in all but, perhaps, one occurrence per million. It > happens so seldom that in practice, one can assume that b-c-f and a-c-f > match completely[*]. You are describing the exception as though it were the > typical case. > > [*] provided the exceptions are handled somehow. > > [ .... ] > I'd vastly prefer the calls to be balanced. It looks like it will be difficult to make them that way, so describing in the manual behavior that preserves most of the goodness and spells out the workarounds mode authors need to use seems like the least awful approach.