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: Thu, 11 Aug 2016 12:43:08 -0400 Message-ID: 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> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1470933680 26400 195.159.176.226 (11 Aug 2016 16:41:20 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 11 Aug 2016 16:41:20 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Aug 11 18:41:16 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 1bXt2h-0006kr-Uf for ged-emacs-devel@m.gmane.org; Thu, 11 Aug 2016 18:41:16 +0200 Original-Received: from localhost ([::1]:49742 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bXt2e-0001dx-VW for ged-emacs-devel@m.gmane.org; Thu, 11 Aug 2016 12:41:12 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48406) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bXt2W-0001b4-0b for emacs-devel@gnu.org; Thu, 11 Aug 2016 12:41:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bXt2Q-0008UV-Mk for emacs-devel@gnu.org; Thu, 11 Aug 2016 12:41:02 -0400 Original-Received: from chene.dit.umontreal.ca ([132.204.246.20]:42378) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bXt2Q-0008UN-H2 for emacs-devel@gnu.org; Thu, 11 Aug 2016 12:40:58 -0400 Original-Received: from pastel.home (lechon.iro.umontreal.ca [132.204.27.242]) by chene.dit.umontreal.ca (8.14.7/8.14.1) with ESMTP id u7BGfQM3002535; Thu, 11 Aug 2016 12:41:27 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 7C9B96018E; Thu, 11 Aug 2016 12:43:08 -0400 (EDT) In-Reply-To: <20160811112951.GA2154@acm.fritz.box> (Alan Mackenzie's message of "Thu, 11 Aug 2016 11:29:51 +0000") X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV5763=0 X-NAI-Spam-Version: 2.3.0.9418 : core <5763> : inlines <5085> : streams <1682469> : uri <2264962> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 132.204.246.20 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:206562 Archived-At: > That is the current status, yes. In the bug which gave rise to this > discussion, bug #24094, a certain change did not call b-c-f at all. Right, but that's a bug, not a misfeature we want to document. > The Elisp manual, up until yesterday, documented implicitly that b-c-f > and a-c-f were paired. No: you read it as documenting this implicitly, but that's a misunderstanding. >> Furthermore there is no evidence that you "MUST". >> I gave various examples of ways you can live with only a-c-f. > Vague hand-waving is what I remember. That's because you don't want to think about it seriously: Of course it's not in the form of a patch to CC-mode that passes all your tests plus various performance assessments, no. But those "vague hand-waving" refer to techniques used in actual code in various major modes facing similar problems. > You know full well what I mean. By the time you get to a-c-f the > deletion as announced is a hollowed out husk, all its details except for > its position and size having been lost. As mentioned in my so-called "hand-waving", any details you may need can be stored somewhere for use. But there's no reason your code could *require* this data for correct behavior, since your code also has to handle the more general case where all the text after BEG has been replaced by something else which may or may not include similar contents and may or may not already include some text-properties like `syntax-table'. > What you and Eli are asserting is that one NEVER IN ANY CIRCUMSTANCES > needs to know the full details of a buffer modification, and no program > now or in the future ever will. Exactly. And that's because the code has to handle the previously mentioned general case anyway. > With the recent change in documentation, Emacs 25.1 has become a less > powerful programming system, one in which these details cannot > be determined. Nope. The documentation is just more honest than before. > If you want to try and construct a CC Mode which disregards deletions, > you are welcome. I won't stand in your way. But I will try and break it. I expect no less. >> .... and I understand that you might prefer to try and live with it >> than to go back and rethink it, but it's still a bad design (nor is it >> the only bad design we have in Emacs, of course). > You've been libelling my design for longer than I can remember. > It's different from how you'd try to do it, that's all. No, that's not all. It's based on an invalid assumption about b-c-f and a-c-f, and even if that assumption was true I contend that it leads to more complex code. It probably has some performance advantages in some cases, of course. By I doubt it has a performance advantage "on average". > It's a straightforward and obvious distillation of requirements and > Emacs's documented features. No idea what you mean by that. > You recently admitted you'd never tried to build anything that way, so > you're just saying "my way is better". I also tried to replace in CC-mode "your way" with mine and found mine to be simpler. Stefan