From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: Unbalanced change hooks (part 2) [Documentation fix still remaining] Date: Tue, 30 Aug 2016 20:53:36 +0000 Message-ID: <20160830205335.GI6672@acm.fritz.box> References: <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; charset=us-ascii X-Trace: blaine.gmane.org 1472590461 25964 195.159.176.226 (30 Aug 2016 20:54:21 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 30 Aug 2016 20:54:21 +0000 (UTC) User-Agent: Mutt/1.5.24 (2015-08-30) Cc: Daniel Colascione , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Aug 30 22:54:17 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 1beq2y-0006J8-05 for ged-emacs-devel@m.gmane.org; Tue, 30 Aug 2016 22:54:16 +0200 Original-Received: from localhost ([::1]:51235 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1beq2v-00026Q-Fd for ged-emacs-devel@m.gmane.org; Tue, 30 Aug 2016 16:54:13 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47778) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1beq2p-00026K-BG for emacs-devel@gnu.org; Tue, 30 Aug 2016 16:54:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1beq2l-0002qZ-4l for emacs-devel@gnu.org; Tue, 30 Aug 2016 16:54:06 -0400 Original-Received: from mail.muc.de ([193.149.48.3]:10162) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1beq2k-0002qD-RT for emacs-devel@gnu.org; Tue, 30 Aug 2016 16:54:03 -0400 Original-Received: (qmail 63166 invoked by uid 3782); 30 Aug 2016 20:54:01 -0000 Original-Received: from acm.muc.de (p548C605C.dip0.t-ipconnect.de [84.140.96.92]) by colin.muc.de (tmda-ofmipd) with ESMTP; Tue, 30 Aug 2016 22:54:00 +0200 Original-Received: (qmail 7757 invoked by uid 1000); 30 Aug 2016 20:53:36 -0000 Content-Disposition: inline In-Reply-To: X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de X-detected-operating-system: by eggs.gnu.org: FreeBSD 9.x X-Received-From: 193.149.48.3 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:207004 Archived-At: Hello, Stefan. On Tue, Aug 30, 2016 at 04:34:46PM -0400, Stefan Monnier wrote: > > 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. That's garbage. Pure garbage. I said above in any _REASONABLE_ fashion, specifically excluding, in the bit you snipped, scanning from BOB on every single change. Even you would start complaining if CC Mode slowed to the slowness it would have on implementing anything like you're suggesting. > 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. No, Daniel's description, also Eli's description, by any reasonable reading, completely exclude the use of the technique, using words like "expect", but using it to mean something different from its everyday meaning. I expect b-c-f and a-c-f to match in the same way I expect to cross the road without being knocked down by a lorry. It's the normal event, though not 100% guaranteed. Nowhere do Daniel or Eli document the reality, that b-c-f and a-c-f match very close to 100% of the time. The elisp manual places an upper limit on what hackers can do with Emacs. That limit is now lower than it was before 25.1. I find that a very sad state of affairs. > 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. I disagree with you totally. > Stefan -- Alan Mackenzie (Nuremberg, Germany).