From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Davis Herring Newsgroups: gmane.emacs.devel Subject: Re: Unbalanced change hooks (part 2) [Documentation fix still remaining] Date: Thu, 1 Sep 2016 15:25:01 -0600 Organization: XCP-1 Message-ID: <8f54985c-09f9-ad1f-6132-43e7c04fc2a9@lanl.gov> 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> <7e1478b6-cf00-fcbf-8c24-43bdaa57e2b6@dancol.org> <415d1cca-f32c-624e-a4be-9aadcf8a0f17@dancol.org> <83inujbpek.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1472765161 3016 195.159.176.226 (1 Sep 2016 21:26:01 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 1 Sep 2016 21:26:01 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2 Cc: emacs-devel@gnu.org To: Eli Zaretskii , Daniel Colascione , monnier@iro.umontreal.ca Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Sep 01 23:25:57 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 1bfZUh-0000Dw-MA for ged-emacs-devel@m.gmane.org; Thu, 01 Sep 2016 23:25:55 +0200 Original-Received: from localhost ([::1]:39010 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bfZUf-0002wU-27 for ged-emacs-devel@m.gmane.org; Thu, 01 Sep 2016 17:25:53 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52114) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bfZUY-0002wM-6O for emacs-devel@gnu.org; Thu, 01 Sep 2016 17:25:47 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bfZUR-0005hH-Sz for emacs-devel@gnu.org; Thu, 01 Sep 2016 17:25:45 -0400 Original-Received: from proofpoint5.lanl.gov ([2001:400:4210:400::a5]:38071) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bfZUR-0005gr-FI; Thu, 01 Sep 2016 17:25:39 -0400 Original-Received: from mailrelay1.lanl.gov (mailrelay1.lanl.gov [128.165.4.101]) by mailgate5.lanl.gov (8.15.0.59/8.15.0.59) with ESMTP id u81LP1Px022978; Thu, 1 Sep 2016 15:25:01 -0600 Original-Received: from localhost (localhost.localdomain [127.0.0.1]) by mailrelay1.lanl.gov (Postfix) with ESMTP id A092E141C31A; Thu, 1 Sep 2016 15:25:01 -0600 (MDT) X-NIE-2-Virus-Scanner: amavisd-new at mailrelay1.lanl.gov Original-Received: from chinstrap.lanl.gov (chinstrap.lanl.gov [128.165.123.246]) by mailrelay1.lanl.gov (Postfix) with ESMTP id 6F1FA141C316; Thu, 1 Sep 2016 15:25:01 -0600 (MDT) In-Reply-To: <83inujbpek.fsf@gnu.org> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.15.154, 1.0.3, 0.0.0000 definitions=2016-09-01_09:2016-09-01, 2016-09-01, 1970-01-01 signatures=0 X-MIME-Autoconverted: from 8bit to quoted-printable by mailgate5.lanl.gov id u81LP1Px022978 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [generic] X-Received-From: 2001:400:4210:400::a5 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:207103 Archived-At: > This is a na=C3=AFve interpretation of what a "change" means and entail= s. > In reality, some changes are done with a single call to an insdel > function, while others need multiple calls that delete and insert text > piecemeal. Thus the need to call the hooks before and after each > insdel call only sometimes. Indeed, no one knows what we mean by "change". To make progress, we=20 must introduce a formal definition for it, in particular in conjunction=20 with the word "before" -- preferably a definition that the current=20 implementation satisfies but that allows useful reasoning. As has been said, some of the proposed documentation that disclaims=20 "pairing" produces a definition that is satisfied but is uselessly vague=20 -- allowing the implementation to simply call b-c-f once with=20 (point-min) and (point-max) when the buffer is created, and never again.=20 (Changes beyond the initial (point-max) are simply insertions into=20 that interval!) However, we intuitively know that b-c-f is supposed to be called=20 "immediately before" a change; what does that mean? Certainly it is not=20 a statement about the real passage of time or function calls. It has to=20 be based on an ordering of relevant events -- b-c-f calls, a-c-f calls,=20 and the changes themselves. The "properly paired" ideal defines=20 "immediately before" as "with no change intervening" (and similarly for=20 a-c-f), disallowing the implementation from reporting what Dan calls=20 "fine-grained" changes only via a-c-f. We can offer a weaker (but still useful) formal guarantee that the=20 current implementation does satisfy phrased instead in terms of=20 _absence_ of change: a call to a-c-f "publishes" an interval of text=20 where changes have been completed and which shall not be altered until=20 after a subsequent b-c-f call that "unlocks" it. (These intervals act=20 like rear-advancing overlays: a zero-length interval must be unlocked to=20 allow an insertion, and an a-c-f call that covers an unlocked interval=20 entirely destroys it without any zero-length remainder.) Lack of=20 alteration is easier to define than change (because it is a state=20 function, not a path function), and it is what all caching clients rely=20 on for the validity of their caches. There remains a gap in the information provided by this guarantee (and=20 the current implementation): when no a-c-f region corresponds exactly to=20 a preceding b-c-f call, clients are left to wonder whether more changes=20 may yet occur. At the least, we must publish all text before redisplay=20 (to prevent the user from observing text not yet processed by a-c-f),=20 but we can leave redisplay out of it by having each function which=20 currently makes "unpaired" calls do one of several things when it exits: 1. Make an additional call to a-c-f that covers the whole region (which,=20 in this interpretation, is not a violation because a-c-f is a promise=20 not to modify in the future rather than a statement about modifications=20 in the past). This destroys the utility of the smaller a-c-f regions,=20 of course. 2. Call some new hook to indicate that the remaining unlocked text has=20 been republished in its original state. (Note that it does not matter=20 if the text was actually changed and then changed back, so long as all=20 text properties and markers were restored and no other hooks were called.= ) 3. Make another call to b-c-f and a-c-f with, say, (point-max)=20 (point-max). We would then document that each call to b-c-f (for a=20 buffer) indicates that any text not covered by a-c-f since the last=20 b-c-f is republished unaltered. This fits the current implementation=20 and the intuitive idea that b-c-f is called before "each" change because=20 it separates changes into epochs demarcated by b-c-f. I therefore propose approach #3 as the minimal change to the current=20 implementation that provides a behavioral guarantee worth documenting.=20 Moreover, the demarcation of changes into epochs allows interested=20 clients to work with the "paired" behavior by deferring a-c-f operations=20 until the next b-c-f or precisely matching a-c-f. (If all functions=20 follow #3, then either the first a-c-f matches or the sequence will be=20 terminated by a b-c-f.) Davis --=20 This product is sold by volume, not by mass. If it appears too dense or=20 too sparse, it is because mass-energy conversion has occurred during=20 shipping.