Re: Unbalanced change hooks (part 2)

[Alan Mackenzie]

Hello, Stefan.

On Tue, Aug 02, 2016 at 01:24:14PM -0400, Stefan Monnier wrote:
> > 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.

The text "foo" in "\"foo(" implicitly contains the information "the
matching closing delimiter is at the text ")foo\"" further down the
buffer".

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

Maybe it could, but that's not the point.  The point here is that after
deleting "\"foo(" (or part of it), the closing delimiter must be found,
even if all that is going to be done is to remove a string fence
property from it.  How will one find this closing delimiter without
knowing that the identifier in it is "foo"?  Indeed, how will one know
to find it without even knowing that a raw string delimiter has been
removed?

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

Again, how does one know that a raw string opening delimiter has been
removed?

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

Or one could note the state before a change, and see how the change
changes it.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).