From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: Unbalanced change hooks (part 2) Date: Sun, 7 Aug 2016 21:48:13 +0000 Message-ID: <20160807214813.GB3690@acm.fritz.box> 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> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1470606559 28480 195.159.176.226 (7 Aug 2016 21:49:19 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 7 Aug 2016 21:49:19 +0000 (UTC) User-Agent: Mutt/1.5.24 (2015-08-30) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Aug 07 23:49:15 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 1bWVwS-0005gG-AO for ged-emacs-devel@m.gmane.org; Sun, 07 Aug 2016 23:49:08 +0200 Original-Received: from localhost ([::1]:53969 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bWVwO-0003pq-Ll for ged-emacs-devel@m.gmane.org; Sun, 07 Aug 2016 17:49:04 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45235) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bWVwF-0003pX-82 for emacs-devel@gnu.org; Sun, 07 Aug 2016 17:48:57 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bWVwA-0004sU-BU for emacs-devel@gnu.org; Sun, 07 Aug 2016 17:48:54 -0400 Original-Received: from mail.muc.de ([193.149.48.3]:60185) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bWVw9-0004sJ-UF for emacs-devel@gnu.org; Sun, 07 Aug 2016 17:48:50 -0400 Original-Received: (qmail 30974 invoked by uid 3782); 7 Aug 2016 21:48:47 -0000 Original-Received: from acm.muc.de (p548C79F0.dip0.t-ipconnect.de [84.140.121.240]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 07 Aug 2016 23:48:46 +0200 Original-Received: (qmail 3904 invoked by uid 1000); 7 Aug 2016 21:48:13 -0000 Content-Disposition: inline In-Reply-To: X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de X-detected-operating-system: by eggs.gnu.org: FreeBSD 9.x X-Received-From: 193.149.48.3 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:206470 Archived-At: Hello, Stefan. On Sun, Aug 07, 2016 at 11:09:52AM -0400, Stefan Monnier wrote: > > Maybe it could, but that's not the point. The point here is that after > > deleting "\"foo(" (or part of it), the closing delimiter must be found, > > even if all that is going to be done is to remove a string fence > > property from it. How will one find this closing delimiter without > > knowing that the identifier in it is "foo"? Indeed, how will one know > > to find it without even knowing that a raw string delimiter has been > > removed? > Because the text-property on the remaining text says "I'm in the middle > of a raw-string" and it says so until the end of that raw-string, hence > telling you where was the end. OK. Extrapolating that suggestion, you're suggesting that all the different types of information about the buffer which are currently determined in c-before-change should be cached in text properties, or perhaps in special purpose Lisp structures, and retrieved and used in c-after-change. 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)). > > Or one could note the state before a change, and see how the change > > changes it. > Experience shows that this approach is a lot more complex, especially if > you take into account that before- and after- change-functions calls aren't > guaranteed to come in pairs. 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. You seem to be arguing that using all the information about a change is more complicated than ignoring some of it. 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. > In any case the question was not "can the CC-mode way be made to work" > but "is it the only way". If it was the only way, it would make sense > to try and support it better. But it's far from the only way, and > I have enough experience in those matters to even claim that it's far > from being the best way. "It's far from the only way" is what I have been saying for some while about your way of handling, for example, syntax-table text properties. Have you ever tried doing things the "CC Mode way", i.e. using information from before-change-functions in an essential fashion? If so, please tell me about it, and what it was that brought you to giving up on it. > Stefan -- Alan Mackenzie (Nuremberg, Germany).