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 16:34:46 -0400 Message-ID: References: <5857ab7e-e85c-c6ae-ba1a-b1337ae57f2c@dancol.org> <83fupmm9ul.fsf@gnu.org> <67e1e007-c944-b91e-6c4b-b06b51beddc1@dancol.org> <20160830180139.GC6672@acm.fritz.box> <0d2edb1c-8b51-8114-d121-386322b1a1f6@dancol.org> <20160830183009.GE6672@acm.fritz.box> <20160830184749.GF6672@acm.fritz.box> <20160830191443.GH6672@acm.fritz.box> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1472589170 30116 195.159.176.226 (30 Aug 2016 20:32:50 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 30 Aug 2016 20:32:50 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) Cc: Daniel Colascione , emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Aug 30 22:32:47 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 1bepi8-0007AT-Pz for ged-emacs-devel@m.gmane.org; Tue, 30 Aug 2016 22:32:44 +0200 Original-Received: from localhost ([::1]:51107 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bepi6-0000vo-Dg for ged-emacs-devel@m.gmane.org; Tue, 30 Aug 2016 16:32:42 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41028) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bephF-0000tc-6S for emacs-devel@gnu.org; Tue, 30 Aug 2016 16:31:50 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bephB-0006MK-6r for emacs-devel@gnu.org; Tue, 30 Aug 2016 16:31:49 -0400 Original-Received: from alt42.smtp-out.videotron.ca ([23.233.128.29]:39123) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bephB-0006MG-27 for emacs-devel@gnu.org; Tue, 30 Aug 2016 16:31:45 -0400 Original-Received: from ceviche.home ([184.161.231.20]) by Videotron with SMTP id eph7bfuKj6cTKeph8bnFcr; Tue, 30 Aug 2016 16:31:43 -0400 X-Authority-Analysis: v=2.1 cv=TfA2zUkh c=1 sm=1 tr=0 a=RXLRw6V2y9MFlfnpr5gyhA==:117 a=RXLRw6V2y9MFlfnpr5gyhA==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=7z1cN_iqozsA:10 a=QcKGceqtIgGzivxcZK0A:9 Original-Received: by ceviche.home (Postfix, from userid 20848) id 21BCE66274; Tue, 30 Aug 2016 16:34:46 -0400 (EDT) In-Reply-To: <20160830191443.GH6672@acm.fritz.box> (Alan Mackenzie's message of "Tue, 30 Aug 2016 19:14:43 +0000") X-CMAE-Envelope: MS4wfLPJ7HBIm6AlOdJGsQulA0yFhEVKxz+fZGB0B26Zbu7+iurrtPa86mPUnC5/k215pOd9Dzapqgz+3qcpX4lLkGodB2DDDy7Oenop2RXEGxkrZhc7iaU5 o+FWp4aPr8c3nsXdCWzgtdl97xd1sOfzZNyddNquQAfN+WGO9pJoHNvDl9g4vFNku0flJER3JosaiGFqTCuGxE69T+Q2AJdzEx20D7F92YmmZCv/rcrRk6Td zTRdY4oIDJ8fEw09hEBnsKio+D8l2Bqj/f0r3BPTLR4= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 23.233.128.29 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:207003 Archived-At: > There is software that cannot be written in any reasonable fashion > without the technique under discussion. I suspect, even if I don't know > for sure, that CC Mode comes into that category. It's trivial to demonstrate that it doesn't: - consider any change between START and END to the buffer. - you can always decompose it into: (a) delete everything from START to point-max. (b) insert at START (now point-max) the rest of the text. - clearly the above deletions and insertions *could* happen, so CC-mode has to handle them and since all changes could be decomposed this way, CC-mode does not *need* to handle any other case. - to handle (a) you don't need to know anything from b-c-f. - to handle (b) you don't need to know anything from b-c-f. CQFD > No, I quite clearly and accurately described the Emacs that does exist: > The technique works almost always, but you have to detect and handle > exceptions carefully, something that can be easily done. Daniel's description gives you the added info necessary to know how to detect that situation and what you might want to do about it. FWIW, I like Daniel's wording. It is about as precise as we can make it without imposing undue burden (IOW I think Emacs's implementation can reasonably (and should) obey that description) and I think it gives the right intuition. Stefan