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

[Phillip Lord]

Stefan Monnier <address@hidden> writes:

>>> I guess a way to "fix" it would be to add a random fudge factor to the
>>> b-c-f calls, plus add random dummy calls to b-c-f, and sprinkle the
>>> lisp/*.el code with combine-after-change-calls.  This way, the "properly
>>> paired up" case will be much more exceptional.
>> You can't be serious.
>
> If it can finally get us rid of people who insist they want exactly
> paired/matched/symmetric b/a-c-f, then I'd willing to do that, yes.
>
> AFAICT the result would be simpler, cleaner, and more robust code, since
> instead of trying to think of the various different ways a buffer can
> change here or there, the coder would be forced to step back and think
> how to handle the general case.


I use these functions for my package lentic, and I do handle the general
case.

In fact, I started off by handling the general case -- this involves
using a-c-f only and just ignoring the parameters. It works, of course,
but it is inefficient enough that it limits the usability to small
buffers.

So, I made use of the information on a-c-f and b-c-f. This increases the
code complexity significantly, but it reduces the load massively. That
b-c-f and a-c-f are not always balanced or consistent, unfortunately,
works directly against this aim.

So having them balanced and consistent would be nice. I agree that in
fixing this, bad things might happens. But surely that is a risk of
fiddling with any core part of Emacs. One response would be to not to
it. Another response would be to incrementally increase the number of
test cases Emacs has to enable this (and other) changes in the core to
be made with more confidence.

Phil