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

[Eli Zaretskii]

> Cc: address@hidden, address@hidden
> From: Daniel Colascione <address@hidden>
> Date: Tue, 30 Aug 2016 09:22:21 -0700
> 
> > My response is that we should not do it until we have decent test
> > coverage of the insdel functionality.  I simply don't believe in our
> > ability to avoid breakage in this core functionality unless we have
> > good test coverage.  Been there, done that, have bruises to prove it.
> 
> More tests in general would be nice. I have no objection to requiring 
> test coverage for insdel before making major changes; my objection is to 
> a blanket ban on changes even *with* test coverage. I was the under the 
> impression that your preference was for the latter model, but IIUC, you 
> actually hold the former position.

I'm simply disillusioned wrt to possibility of any significant
progress in having tests in these areas.  Almost all of our tests are
in application areas, while the functions in src/ remain almost
completely uncovered.  I have no reason to believe this will change
any time soon (but I will be happy to be mistaken, of course).

That is why I could have sent ambiguous messages in this regard.

(And it's not only insdel that will be affected, because
signal_before_change and signal_after_change also affect the various
caches we maintain for a buffer, its markers, text properties and
overlays, etc.  All of which will have to be covered by tests, before
we can consider serious changes in this area.)