Re: Unbalanced change hooks (part 2) [Documentation fix still remaining]

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

>> No: you read it as documenting this implicitly, but that's
>> a misunderstanding.
> Alan's interpretation is the text is the natural one, and it's the one I had
> as well.

If you say so.  I must say I don't know/understand what is his
interpretation, so if you can give details it would help.  E.g. give us
a concrete scenario that currently happens in Emacs and which you think
is incompatible with the description.

[ Tho, please note that we already know about 1 such scenario (the lack
  of b-c-f from insert-file-contents with `replace' non-nil and where
  the new content has no new text but has simply some part of the file
  deleted) which we all agree is a bug.  ]

> What pieces of code could conceivably break if Emacs balances
> currently-unbalanced a-c-f calls?

That's the wrong question.  A more interesting question could be: how
can we make those hooks always perfectly balanced even in the most twisted
cases (e.g. when a b/a-c-f call itself makes a change to the buffer),
and without undue performance penalty.  Another one would be: who would
write such a patch and then make sure that this patch doesn't introduce
other bugs?  On the sideline: the only known case which would benefit,
really, is that of Phillip Lord (because, as best I can see,
Alan's case would benefit much more from getting rid of this assumption
altogether (although Alan himself wouldn't benefit as much because he'd
first have to learn to appreciate this other way to deal with the
problem)).

> Is it really better to force that complexity (which, in the limit, amounts
> to full shadow buffers)

What complexity?  Compare the complexity of CC-mode with that of
cperl-mode or perl-mode.  I can guarantee you that it's actually
*simpler* to give up on the idea of perfectly matched b/a-c-f calls for
purposes of syntax highlighting and parsing.

> legitimately has an after-change-function, violates the rule that we use one
> set of functions or another.

There's no such rule.


        Stefan