Re: Unbalanced change hooks (part 2)

[Alan Mackenzie]

Hello, Stefan.

On Sun, Aug 07, 2016 at 11:09:52AM -0400, Stefan Monnier wrote:
> > 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?

> Because the text-property on the remaining text says "I'm in the middle
> of a raw-string" and it says so until the end of that raw-string, hence
> telling you where was the end.

OK.  Extrapolating that suggestion, you're suggesting that all the
different types of information about the buffer which are currently
determined in c-before-change should be cached in text properties, or
perhaps in special purpose Lisp structures, and retrieved and used in
c-after-change.

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

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

> Experience shows that this approach is a lot more complex, especially if
> you take into account that before- and after- change-functions calls aren't
> guaranteed to come in pairs.

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.

You seem to be arguing that using all the information about a change is
more complicated than ignoring some of it.  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.

> In any case the question was not "can the CC-mode way be made to work"
> but "is it the only way".  If it was the only way, it would make sense
> to try and support it better.  But it's far from the only way, and
> I have enough experience in those matters to even claim that it's far
> from being the best way.

"It's far from the only way" is what I have been saying for some while
about your way of handling, for example, syntax-table text properties.

Have you ever tried doing things the "CC Mode way", i.e. using
information from before-change-functions in an essential fashion?  If
so, please tell me about it, and what it was that brought you to giving
up on it.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).