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: Tue, 2 Aug 2016 16:09:14 +0000 Message-ID: <20160802160913.GB2328@acm.fritz.box> 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> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1470154243 21984 195.159.176.226 (2 Aug 2016 16:10:43 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 2 Aug 2016 16:10:43 +0000 (UTC) User-Agent: Mutt/1.5.24 (2015-08-30) Cc: ofv@wanadoo.es, rcopley@gmail.com, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Aug 02 18:10:39 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 1bUcH8-0005KT-BZ for ged-emacs-devel@m.gmane.org; Tue, 02 Aug 2016 18:10:38 +0200 Original-Received: from localhost ([::1]:57594 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bUcH4-0001va-Vi for ged-emacs-devel@m.gmane.org; Tue, 02 Aug 2016 12:10:35 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43152) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bUcGY-0001vE-0Z for emacs-devel@gnu.org; Tue, 02 Aug 2016 12:10:03 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bUcGS-0000Yh-3y for emacs-devel@gnu.org; Tue, 02 Aug 2016 12:10:00 -0400 Original-Received: from mail.muc.de ([193.149.48.3]:21811) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bUcGR-0000X3-QA for emacs-devel@gnu.org; Tue, 02 Aug 2016 12:09:56 -0400 Original-Received: (qmail 97116 invoked by uid 3782); 2 Aug 2016 16:09:53 -0000 Original-Received: from acm.muc.de (p548C7CD5.dip0.t-ipconnect.de [84.140.124.213]) by colin.muc.de (tmda-ofmipd) with ESMTP; Tue, 02 Aug 2016 18:09:51 +0200 Original-Received: (qmail 4197 invoked by uid 1000); 2 Aug 2016 16:09:14 -0000 Content-Disposition: inline In-Reply-To: <83ziovmdrh.fsf@gnu.org> 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:206356 Archived-At: Hello, Eli. On Tue, Aug 02, 2016 at 05:44:34PM +0300, Eli Zaretskii wrote: > > Date: Mon, 1 Aug 2016 20:52:23 +0000 > > Cc: ofv@wanadoo.es, rcopley@gmail.com, emacs-devel@gnu.org > > From: Alan Mackenzie > > (i) Abandon the use of before-change-functions. > > (ii) Enable undo in pre-command-hook, if necessary. > > (iii) At each after-change-functions call: > > a - Analyze buffer-undo-list down as far as (or pos (next-nil)), and > > revert the insertion or deletion which as been made, taking > > particular care over coalesced multiple insertions/deletions. > > b - (setq pos (current-position-in-undo-list)) > > c - Perform what used to be before-change actions. > > d - restore the insertion/deletion. > > e - Perform the normal after-change functions. > > (iv) Disable undo in post-command-hook, if appropriate. > What I don't get is why do you need to look at the deleted text. The > after-change-functions called after deletion tells you which buffer > positions were removed, so any data CC Mode holds in its caches about > those positions should be discarded. Why do you need to actually look > at the removed text itself? What am I missing? Things are cached in text properties on the text itself. These properties can only be examined before the text is deleted. A specific instance of needing to see the deleted text is in the handling of C++ raw strings. Such a thing looks like this: "foo()foo" . The "foo" can be any (sensible) sequence of 0-16 characters. The contents of the string can be literally anything _except_ the terminating delimiter ")foo\""; for example it could include both "\"bar(" and ")bar\"". 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. For example, each "\"" in the raw string has a syntax-table text property on it to suppress its "string" syntax, and there are text properties on what used to be the closing delimiter. For this we need to know where the string ended, i.e. we need to know the "foo" from the opening delimiter so that we can search forward for ")foo\"". This involves looking at the buffer before it is changed. > Regarding the proposal itself, undoing arbitrary changes might be > expensive, both CPU- and memory-wise. It might. But what are the alternatives? Anyhow, most buffer changes are going to be single character insertions or deletions for which the extra processing time shouldn't be noticeable. For something like a large C-w, a little extra time hopefully won't be too stressfull - undoing that C-w won't involve CC Mode's syntactic analysis, since all the deleted text properties are stored in the undo list. -- Alan Mackenzie (Nuremberg, Germany).