Re: Unbalanced change hooks (part 2)

[Eli Zaretskii]

> Date: Tue, 2 Aug 2016 16:09:14 +0000
> Cc: address@hidden, address@hidden, address@hidden
> From: Alan Mackenzie <address@hidden>
> 
> > 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.

OK, so you must also have code that computes and places those
properties, right?  What triggers that code?  E.g., when a file is
visited, what invokes that code, and how much of the buffer it
processes when invoked?  If it doesn't process the entire buffer in
one go, how is it invoked to process the rest of the buffer?

> > Regarding the proposal itself, undoing arbitrary changes might be
> > expensive, both CPU- and memory-wise.
> 
> It might.  But what are the alternatives?

I don't know yet.  That's why I asked the questions above.

Thanks.