Re: Unbalanced change hooks (part 2)

[Stefan Monnier]

> For some types of information this would be easy (such as putting text
> properties over C++ raw strings), for others it would be difficult (such
> as maintaining the integrity of the c-parse-state cache (yes, _that_
> thing)).

For this one, you don't need to know what changed either.  You just
restart from some point before BEG and compare the resulting state at
some point after END (after potentially adjusting the old state's
positions based on LENGTH).

> I now have an idea (see my recent post to Eli) to _make_ these hook
> calls properly paired.  This should be reliable and easy to implement.

I personally can't see any way you can make them properly paired in 100%
of the cases (including the case where one of the hooks itself makes
a buffer modification, for example).

> You seem to be arguing that using all the information about a change is
> more complicated than ignoring some of it.

Oh, yes.  And my attempt at using syntax-propertize in CC-mode comforts
me in this belief (even tho, I obviously only did the easy part).

> I can't see how that can be the case.  If one is missing part of the
> information, it is surely going to be rather complicated to work
> around that lack.

As Eli pointed out several times already, your code *has* to handle the
case where you have no prior knowledge, because that's what happens when
you open the file (or when you insert a new chunk of text).

So actually trying to use the information about "what was there before"
is extra effort.

> Have you ever tried doing things the "CC Mode way", i.e. using
> information from before-change-functions in an essential fashion?

No, because I know it's based on an invalid assumption.

> If so, please tell me about it, and what it was that brought you to
> giving up on it.

But as mentioned above, I've since had a look at what it takes to go
from "the CC-mode way" to "the usual way", and it mostly involves
removing (somewhat duplicate) code.


        Stefan