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 11:09:52 -0400 Message-ID: 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> <20160807144920.GA27625@acm.fritz.box> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1470582614 12352 195.159.176.226 (7 Aug 2016 15:10:14 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 7 Aug 2016 15:10:14 +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 Sun Aug 07 17:10:11 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 1bWPiK-0002Sg-NT for ged-emacs-devel@m.gmane.org; Sun, 07 Aug 2016 17:10:08 +0200 Original-Received: from localhost ([::1]:52977 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bWPiH-0007Fv-Fs for ged-emacs-devel@m.gmane.org; Sun, 07 Aug 2016 11:10:05 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56832) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bWPiB-0007Fk-Ry for emacs-devel@gnu.org; Sun, 07 Aug 2016 11:10:00 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bWPi8-00030z-NB for emacs-devel@gnu.org; Sun, 07 Aug 2016 11:09:59 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:51581) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bWPi8-00030e-GW for emacs-devel@gnu.org; Sun, 07 Aug 2016 11:09:56 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0A3FgA731xV/2/xd0tcgxCEAoVVwwsEAgKBPDwRAQEBAQEBAYEKQQWDXQEBAwFWIwULCw4fBxIUGA0kiDcIzyMBCyCKOIEChQUHCoQjAQSzP4FFI4Fmgi4igngBAQE X-IPAS-Result: A0A3FgA731xV/2/xd0tcgxCEAoVVwwsEAgKBPDwRAQEBAQEBAYEKQQWDXQEBAwFWIwULCw4fBxIUGA0kiDcIzyMBCyCKOIEChQUHCoQjAQSzP4FFI4Fmgi4igngBAQE X-IronPort-AV: E=Sophos;i="5.13,465,1427774400"; d="scan'208";a="250489524" 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 11:09:53 -0400 Original-Received: by fmsmemgm.homelinux.net (Postfix, from userid 20848) id EA7E9AE080; Sun, 7 Aug 2016 11:09:52 -0400 (EDT) In-Reply-To: <20160807144920.GA27625@acm.fritz.box> (Alan Mackenzie's message of "Sun, 7 Aug 2016 14:49:20 +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:206467 Archived-At: > 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. > 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. 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. Stefan