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 14:49:20 +0000 Message-ID: <20160807144920.GA27625@acm.fritz.box> References: <834m75ptij.fsf@gnu.org> <20160731212635.GF2205@acm.fritz.box> <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> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1470581453 23810 195.159.176.226 (7 Aug 2016 14:50:53 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 7 Aug 2016 14:50:53 +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 16:50:49 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 1bWPPV-0004vq-9n for ged-emacs-devel@m.gmane.org; Sun, 07 Aug 2016 16:50:41 +0200 Original-Received: from localhost ([::1]:52928 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bWPPR-0000bY-V4 for ged-emacs-devel@m.gmane.org; Sun, 07 Aug 2016 10:50:37 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54565) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bWPOt-0000bN-Td for emacs-devel@gnu.org; Sun, 07 Aug 2016 10:50:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bWPOp-0000CE-NK for emacs-devel@gnu.org; Sun, 07 Aug 2016 10:50:02 -0400 Original-Received: from mail.muc.de ([193.149.48.3]:53184) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bWPOp-0000Br-DG for emacs-devel@gnu.org; Sun, 07 Aug 2016 10:49:59 -0400 Original-Received: (qmail 27080 invoked by uid 3782); 7 Aug 2016 14:49:55 -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 16:49:54 +0200 Original-Received: (qmail 27649 invoked by uid 1000); 7 Aug 2016 14:49:20 -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:206466 Archived-At: Hello, Stefan. On Tue, Aug 02, 2016 at 01:24:14PM -0400, Stefan Monnier wrote: > > Things are cached in text properties on the text itself. > I doubt you only put them on the actual text. > > "foo()foo" > E.g. I doubt you put "foo" on the "foo" text. The text "foo" in "\"foo(" implicitly contains the information "the matching closing delimiter is at the text ")foo\"" further down the buffer". > > Now supposing the buffer is changed by deleting the opening delimiter > > "\"foo(". Lots of text properties in the (formally) raw string need to > > be removed. > No, that doesn't have to be the case. CC-mode does it this way > currently because it decided to add properties on various chars within > that string, but that's not the only choice. E.g. you could put > a "string fence" property on the first char of the string and refrain > from putting a "string fence" property until the end of the string. > Most other major modes follow this strategy. 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? > > This involves looking at the buffer before it is changed. > Even if you have properties that you need to remove, you don't actually > need to know the text that was there before. Again, how does one know that a raw string opening delimiter has been removed? > All you need is any position past the end of the used-to-be-string. > Then you just have to refresh all properties until that position. A > trivial choice is point-max but if you want to try and optimize this > you can add some text-property (such as cc-mode-multiline) over the > whole string, which makes it easy to find the end, even when some pats > have been deleted. That's also a common approach in many major modes. > Of course, there are plenty of alternatives if you like to do it > differently. E.g. you can annotate every Nth char in the buffer with > a text property indicating its "state". So you won't get the exact end > of the string, but some position slightly past it. Or you can keep that > information is a side-table holding markers. Or ... Or one could note the state before a change, and see how the change changes it. > Stefan -- Alan Mackenzie (Nuremberg, Germany).