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) Date: Sun, 07 Aug 2016 20:55:37 -0400 Message-ID: References: <83shuoocwp.fsf@gnu.org> <20160801165323.GB15055@acm.fritz.box> <20160801171552.GC15055@acm.fritz.box> <838twgnuso.fsf@gnu.org> <20160801205223.GD15055@acm.fritz.box> <83ziovmdrh.fsf@gnu.org> <20160802160913.GB2328@acm.fritz.box> <20160807144920.GA27625@acm.fritz.box> <20160807214813.GB3690@acm.fritz.box> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1470617761 22810 195.159.176.226 (8 Aug 2016 00:56:01 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 8 Aug 2016 00:56:01 +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 Mon Aug 08 02:55:57 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 1bWYrE-00054J-JD for ged-emacs-devel@m.gmane.org; Mon, 08 Aug 2016 02:55:56 +0200 Original-Received: from localhost ([::1]:54365 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bWYrB-0001Li-BL for ged-emacs-devel@m.gmane.org; Sun, 07 Aug 2016 20:55:53 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41829) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bWYr4-0001LR-MP for emacs-devel@gnu.org; Sun, 07 Aug 2016 20:55:47 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bWYr0-0005Xj-Hr for emacs-devel@gnu.org; Sun, 07 Aug 2016 20:55:45 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:13347) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bWYr0-0005Xd-Ax for emacs-devel@gnu.org; Sun, 07 Aug 2016 20:55:42 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0A2FgA731xV/2/xd0tcgxCEAoVVwwsEAgKBPDwRAQEBAQEBAYEKQQWDXQEBAwFWIwULCw4mEhQYDSSINwjPIwEBCAIBH4s6hQUHhC0BBJ8Xg2uOKYIUgUUjgWYkHIFuIoJ4AQEB X-IPAS-Result: A0A2FgA731xV/2/xd0tcgxCEAoVVwwsEAgKBPDwRAQEBAQEBAYEKQQWDXQEBAwFWIwULCw4mEhQYDSSINwjPIwEBCAIBH4s6hQUHhC0BBJ8Xg2uOKYIUgUUjgWYkHIFuIoJ4AQEB X-IronPort-AV: E=Sophos;i="5.13,465,1427774400"; d="scan'208";a="250526910" Original-Received: from 75-119-241-111.dsl.teksavvy.com (HELO fmsmemgm.homelinux.net) ([75.119.241.111]) by ironport2-out.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Aug 2016 20:55:37 -0400 Original-Received: by fmsmemgm.homelinux.net (Postfix, from userid 20848) id 25EA5AE080; Sun, 7 Aug 2016 20:55:37 -0400 (EDT) In-Reply-To: <20160807214813.GB3690@acm.fritz.box> (Alan Mackenzie's message of "Sun, 7 Aug 2016 21:48:13 +0000") 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:206473 Archived-At: > For some types of information this would be easy (such as putting text > properties over C++ raw strings), for others it would be difficult (such > as maintaining the integrity of the c-parse-state cache (yes, _that_ > thing)). For this one, you don't need to know what changed either. You just restart from some point before BEG and compare the resulting state at some point after END (after potentially adjusting the old state's positions based on LENGTH). > I now have an idea (see my recent post to Eli) to _make_ these hook > calls properly paired. This should be reliable and easy to implement. I personally can't see any way you can make them properly paired in 100% of the cases (including the case where one of the hooks itself makes a buffer modification, for example). > You seem to be arguing that using all the information about a change is > more complicated than ignoring some of it. Oh, yes. And my attempt at using syntax-propertize in CC-mode comforts me in this belief (even tho, I obviously only did the easy part). > I can't see how that can be the case. If one is missing part of the > information, it is surely going to be rather complicated to work > around that lack. As Eli pointed out several times already, your code *has* to handle the case where you have no prior knowledge, because that's what happens when you open the file (or when you insert a new chunk of text). So actually trying to use the information about "what was there before" is extra effort. > Have you ever tried doing things the "CC Mode way", i.e. using > information from before-change-functions in an essential fashion? No, because I know it's based on an invalid assumption. > If so, please tell me about it, and what it was that brought you to > giving up on it. But as mentioned above, I've since had a look at what it takes to go from "the CC-mode way" to "the usual way", and it mostly involves removing (somewhat duplicate) code. Stefan