Re: Unbalanced change hooks (part 2)

[Alan Mackenzie]

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: address@hidden, address@hidden, address@hidden
> > From: Alan Mackenzie <address@hidden>

> > (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(<arbitrary characters, including ", \n, "bar) ....>)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).