Re: Unbalanced change hooks (part 2)

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

> And in such calls, what are the parameters BEG, END, and OLD-LEN supposed
> to mean?

Same as ever: that compared to the last time the hook was run, nothing
was changed before BEG, nothing as changed after END and that the chunk
of text between those two had length OLD-LEN last time the hook was run.

> An empty buffer is a fully defined state.  A buffer immediately following
> a deletion is in an undefined state, which requires to know what was
> deleted to make it defined again.

If you need to know something about the deleted text, you can always
keep track of that info in things like text-properties (or buffer-local
vars).  E.g.:

>> > As a concrete example of this, suppose we have this in a buffer:
>> > 
>> >     #define foo() first line \
>> >                   second line \
>> > 	          third line \
>> > 	          fourth line
>> > 
>> > , and the change consists of deleting the backslash on L2.

You can handle this case with nothing more than an a-c-f and something
like a cc-mode-multiline property applied to the whole CPP construct:
in a-c-f you look at the cc-mode-multiline property at BEG and at END
and you expand the "area to recompute" according to that property.

That's the strategy used by font-lock.

Another strategy is the one used by syntax.el which is to simply
consider everything after BEG as being in need of review (actually,
font-lock also uses this strategy via jit-lock-context).


        Stefan