Re: Unbalanced change hooks (part 2)

[Stefan Monnier <monnier@iro.umontreal.ca>]

> Things are cached in text properties on the text itself.

I doubt you only put them on the actual text.

>     "foo(<arbitrary characters, including ", \n, "bar) ....>)foo"

E.g. I doubt you put "foo" on the "foo" text.

> 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.

No, that doesn't have to be the case.  CC-mode does it this way
currently because it decided to add properties on various chars within
that string, but that's not the only choice.  E.g. you could put
a "string fence" property on the first char of the string and refrain
from putting a "string fence" property until the end of the string.
Most other major modes follow this strategy.

> This involves looking at the buffer before it is changed.

Even if you have properties that you need to remove, you don't actually
need to know the text that was there before.  All you need is any
position past the end of the used-to-be-string.  Then you just have to
refresh all properties until that position.  A trivial choice is
point-max but if you want to try and optimize this you can add some
text-property (such as cc-mode-multiline) over the whole string, which
makes it easy to find the end, even when some pats have been deleted.
That's also a common approach in many major modes.

Of course, there are plenty of alternatives if you like to do it
differently.  E.g. you can annotate every Nth char in the buffer with
a text property indicating its "state".  So you won't get the exact end
of the string, but some position slightly past it.  Or you can keep that
information is a side-table holding markers.  Or ...


        Stefan