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: Sun, 28 Aug 2016 18:36:33 -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 1472561697 4041 195.159.176.226 (30 Aug 2016 12:54:57 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 30 Aug 2016 12:54:57 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) Cc: Alan Mackenzie , emacs-devel@gnu.org To: Daniel Colascione Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Aug 30 14:54:50 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 1beiZ0-0000LF-5W for ged-emacs-devel@m.gmane.org; Tue, 30 Aug 2016 14:54:50 +0200 Original-Received: from localhost ([::1]:49017 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1beiYx-0005CF-SV for ged-emacs-devel@m.gmane.org; Tue, 30 Aug 2016 08:54:47 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52678) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1beiWF-0003R1-2i for emacs-devel@gnu.org; Tue, 30 Aug 2016 08:52:00 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1beiW9-00052v-Uz for emacs-devel@gnu.org; Tue, 30 Aug 2016 08:51:59 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:11826) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1beiW9-00052e-RC for emacs-devel@gnu.org; Tue, 30 Aug 2016 08:51:53 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DPFACJI6tX/2V2oWxdHAEBJIMDhEuFULJahhcEAgKBXTwRAQEBAQEBAV0nhF8BAQMBVg8UBQsLDiYSFBgNJIg8CMFcATCJdIEDhB2FYR0FmTyQfYRbgwExhUuOcIE8NCCCEhyBaCCGGoFEAQEB X-IPAS-Result: A0DPFACJI6tX/2V2oWxdHAEBJIMDhEuFULJahhcEAgKBXTwRAQEBAQEBAV0nhF8BAQMBVg8UBQsLDiYSFBgNJIg8CMFcATCJdIEDhB2FYR0FmTyQfYRbgwExhUuOcIE8NCCCEhyBaCCGGoFEAQEB X-IronPort-AV: E=Sophos;i="5.28,500,1464667200"; d="scan'208";a="269787426" Original-Received: from 108-161-118-101.dsl.teksavvy.com (HELO pastel.home) ([108.161.118.101]) by smtp.teksavvy.com with ESMTP; 30 Aug 2016 08:51:53 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 35B74615F4; Sun, 28 Aug 2016 18:36:33 -0400 (EDT) In-Reply-To: (Daniel Colascione's message of "Sun, 28 Aug 2016 04:23:32 -0700") X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.181 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:206926 Archived-At: >> 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. If you say so. I must say I don't know/understand what is his interpretation, so if you can give details it would help. E.g. give us a concrete scenario that currently happens in Emacs and which you think is incompatible with the description. [ Tho, please note that we already know about 1 such scenario (the lack of b-c-f from insert-file-contents with `replace' non-nil and where the new content has no new text but has simply some part of the file deleted) which we all agree is a bug. ] > What pieces of code could conceivably break if Emacs balances > currently-unbalanced a-c-f calls? That's the wrong question. A more interesting question could be: how can we make those hooks always perfectly balanced even in the most twisted cases (e.g. when a b/a-c-f call itself makes a change to the buffer), and without undue performance penalty. Another one would be: who would write such a patch and then make sure that this patch doesn't introduce other bugs? On the sideline: the only known case which would benefit, really, is that of Phillip Lord (because, as best I can see, Alan's case would benefit much more from getting rid of this assumption altogether (although Alan himself wouldn't benefit as much because he'd first have to learn to appreciate this other way to deal with the problem)). > Is it really better to force that complexity (which, in the limit, amounts > to full shadow buffers) What complexity? Compare the complexity of CC-mode with that of cperl-mode or perl-mode. I can guarantee you that it's actually *simpler* to give up on the idea of perfectly matched b/a-c-f calls for purposes of syntax highlighting and parsing. > legitimately has an after-change-function, violates the rule that we use one > set of functions or another. There's no such rule. Stefan