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: Tue, 02 Aug 2016 13:24:14 -0400 Message-ID: References: <83a8gxq288.fsf@gnu.org> <20160731172804.GD2205@acm.fritz.box> <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 X-Trace: blaine.gmane.org 1470505209 32439 195.159.176.226 (6 Aug 2016 17:40:09 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 6 Aug 2016 17:40:09 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Aug 06 19:40:06 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 1bW5Zs-0007QG-Qd for ged-emacs-devel@m.gmane.org; Sat, 06 Aug 2016 19:40:04 +0200 Original-Received: from localhost ([::1]:50130 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bW5Zp-00017m-Hm for ged-emacs-devel@m.gmane.org; Sat, 06 Aug 2016 13:40:01 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46303) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bW5Zf-00014f-11 for emacs-devel@gnu.org; Sat, 06 Aug 2016 13:39:52 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bW5Za-0007l6-PI for emacs-devel@gnu.org; Sat, 06 Aug 2016 13:39:49 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:18636) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bW5Za-0007kz-JB for emacs-devel@gnu.org; Sat, 06 Aug 2016 13:39:46 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AxFgA731xV/2/xd0tcgxCEAoVVwwsEPoECPBEBAQEBAQEBgQpBBYNdAQQBVigLCzQSFBgNAxuIPQgFz0qLOoUihBcBBLM/gUUjgUcBCxOCLiKCeAEBAQ X-IPAS-Result: A0AxFgA731xV/2/xd0tcgxCEAoVVwwsEPoECPBEBAQEBAQEBgQpBBYNdAQQBVigLCzQSFBgNAxuIPQgFz0qLOoUihBcBBLM/gUUjgUcBCxOCLiKCeAEBAQ X-IronPort-AV: E=Sophos;i="5.13,465,1427774400"; d="scan'208";a="250424834" 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; 06 Aug 2016 13:39:45 -0400 Original-Received: by fmsmemgm.homelinux.net (Postfix, from userid 20848) id 5C84EAE53B; Sat, 6 Aug 2016 13:39:45 -0400 (EDT) Original-Lines: 38 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1bUdO4-0005Cn-0G for emacs-devel@gnu.org; Tue, 02 Aug 2016 19:21:52 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-X-Complaints-To: usenet@blaine.gmane.org Cancel-Lock: sha1:556/nPUrLEy2pnPNJkzIAqcCt7E= 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:206458 Archived-At: > 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. > 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. > 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. 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 ... Stefan