From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.devel Subject: Re: Unbalanced change hooks (part 2) [Documentation fix still remaining] Date: Sun, 28 Aug 2016 04:23:32 -0700 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; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1472383478 15184 195.159.176.226 (28 Aug 2016 11:24:38 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 28 Aug 2016 11:24:38 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 Cc: emacs-devel@gnu.org To: Stefan Monnier , Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Aug 28 13:24:34 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 1bdyCX-0003Mk-9W for ged-emacs-devel@m.gmane.org; Sun, 28 Aug 2016 13:24:33 +0200 Original-Received: from localhost ([::1]:38877 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bdyCU-0004WB-Js for ged-emacs-devel@m.gmane.org; Sun, 28 Aug 2016 07:24:30 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47675) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bdyBw-0004W4-UH for emacs-devel@gnu.org; Sun, 28 Aug 2016 07:23:58 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bdyBr-00015a-RM for emacs-devel@gnu.org; Sun, 28 Aug 2016 07:23:56 -0400 Original-Received: from dancol.org ([96.126.100.184]:43862) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bdyBr-00014V-Hv for emacs-devel@gnu.org; Sun, 28 Aug 2016 07:23:51 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:Cc:References:To:Subject; bh=xmboU6vAOZ54R/xLFkm27Rqcn5okolZO0tQS8QGsvic=; b=StUAp3jRUI/IK95y+85Ja//kyLbD2HbkHUfXtulZdk+W8G43unpywLk4YXzq4cWxiPngZOR/Ldu4yogWmyaYosnwaRa4BWJhyjWMxEh8NngBGVZqIHeupHrsp7KZ/fXCzSa/YI8puUi/oHWo6L2H3DaHChgdQXWvnkj0W1l+1Z5n7p7kRBP5C+Ebm3o7kbrxqKQIs3YcGKEARc0S6wIFgup0zgS+ge/TJQRvVBjZ/Dwu7LC5X5Te4mCUeF0L42VW6TIijHymjezWeqYCS5ZV7KQsMVif2i3dNGK8QUHeYk/w42whfw4kmDa4Tf0GWqP4juf5DB73IX+W8hAgs1uTkg==; Original-Received: from c-73-97-199-232.hsd1.wa.comcast.net ([73.97.199.232] helo=[192.168.1.173]) by dancol.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1bdyBd-0002QE-Jc; Sun, 28 Aug 2016 04:23:37 -0700 In-Reply-To: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 96.126.100.184 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:206844 Archived-At: On 08/11/2016 09:43 AM, Stefan Monnier wrote: >> 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. Alan's interpretation is the text is the natural one, and it's the one I had as well. It's a technical specification, not some kind of allegory. It's meant to be taken literally. There is nothing in the old manual to hint at the more complex reality of the situation, and the additional text just confuses the issue. Besides, you haven't fixed the docstring, which still suggests that b-c-f is called before every change. (And a "change" must be anything that results in a-c-f being called.) Alan is absolutely correct that current Emacs behavior should count as a bug. The behavior Alan wants, which is also the behavior XEmacs provides, and the behavior the manual suggestions on plain reading, is also the most elegant and useful behavior for these hooks. Eli's original argument for not balancing b-c-f with a-c-f is the delicacy of other Emacs code, but this specific change is almost certainly safe, considering that b-c-f is almost always balanced with a-c-f already. Alan's given plenty examples of legitimate pieces of code that can break if b-c-f is not called for a given a-c-f. What pieces of code could conceivably break if Emacs balances currently-unbalanced a-c-f calls? > >>> 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. Is it really better to force that complexity (which, in the limit, amounts to full shadow buffers) onto mode authors instead of changing Emacs to balance b-c-f with a-c-f 100% of the time instead of 99%? > 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. It's also self-contradictory: upon calling syntax-ppss, Emacs installs a before-change-function, which in a mode that perfectly legitimately has an after-change-function, violates the rule that we use one set of functions or another.