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 17:37:59 -0400 Message-ID: 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> <20160830205335.GI6672@acm.fritz.box> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1472721867 12611 195.159.176.226 (1 Sep 2016 09:24:27 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 1 Sep 2016 09:24:27 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Sep 01 11:24:23 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 1bfOEP-0002hk-R1 for ged-emacs-devel@m.gmane.org; Thu, 01 Sep 2016 11:24:21 +0200 Original-Received: from localhost ([::1]:35835 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bfOEQ-0005xM-R3 for ged-emacs-devel@m.gmane.org; Thu, 01 Sep 2016 05:24:22 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55698) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bfO8s-0001dL-8f for emacs-devel@gnu.org; Thu, 01 Sep 2016 05:18:44 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bfO8k-0005Aq-NZ for emacs-devel@gnu.org; Thu, 01 Sep 2016 05:18:38 -0400 Original-Received: from [195.159.176.226] (port=39233 helo=blaine.gmane.org) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bfO8k-0005AQ-G7 for emacs-devel@gnu.org; Thu, 01 Sep 2016 05:18:30 -0400 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1beqgN-0001RD-0F for emacs-devel@gnu.org; Tue, 30 Aug 2016 23:34:59 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 70 Original-X-Complaints-To: usenet@blaine.gmane.org Cancel-Lock: sha1:HvG9DGzYlkbb2iS5hebpZnE5r30= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 195.159.176.226 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:207051 Archived-At: >> 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. [ You said "written in any reasonable fashion", so I took it you referred to the complexity of the code-writing part, not the runtime complexity of the algorithm. As a matter of fact the above suggestion makes the code's writing *more* reasonable since you have to handle fewer distinct cases. ] Nothing in the above requires scanning from BOB. And it's reasonable enough (in terms of performance) for all other known major modes, BTW. > Even you would start complaining if CC Mode slowed to the slowness it > would have on implementing anything like you're suggesting. As a matter fact, my local CC-mode works just the way I describe above (via syntax-propertize), and I haven't noticed any slowness so far. >> 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, Daniel's wording (and Eli as well, tho maybe slightly less crisply) say precisely what might come up and does not exclude the technique you use. You could argue that it lacks an argument of what is *frequent*, which might influence the design choice, but it in no way restrict the *possible* designs. > Nowhere do Daniel or Eli document the reality, that b-c-f and a-c-f > match very close to 100% of the time. I think it's OK. As you and Daniel have argued, it's "natural" for the reader to presume that b-c-f and a-c-f will always come in perfect pairs (and that's also what they will quickly find out when testing or debugging their code), so there's no need to reinforce this natural assumption. Instead what the doc needs to focus on is the fact that this presumption is not always valid and clarify *how* it's invalid. > 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. Your CC-mode design is actually correct w.r.t Daniel's wording. Its good performance is not guaranteed by this wording since it handles the non-paired case suboptimally but we rarely (if ever) document performance-related specification anyway, so most code's performance design is based on experiments rather than on reading the doc. > I disagree with you totally. Wonderful! On the upside, you might like to take a look at the closely related bug#24340 where you might actually agree with me for once ;-) Stefan