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

[Eli Zaretskii <eliz@gnu.org>]

> From: phillip.lord@russet.org.uk (Phillip Lord)
> Cc: Daniel Colascione <dancol@dancol.org>,  monnier@iro.umontreal.ca,  emacs-devel@gnu.org
> Date: Tue, 30 Aug 2016 15:12:13 +0100
> 
> > Surprising or not, the existing implementation is in use for many
> > years, and until now no complaints were presented about it.
> 
> Actually, it caused me significant issues several years ago, and I would
> have prefered that the hooks were balanced.

Me too, believe it or not.  But this is not about our preferences.
This is about the tough choices we must make when faced with the
current situation, where this code was working for many years, we have
a very small number of people who even understand the intricacies of
the implementation, and users certainly don't expect to see Emacs 26
have bugs in basic text handling in buffers.

IOW, we need to find the lesser evil.

> > And even now we have a single complaint from a single use case of a
> > single package (which meanwhile fixed the problem without any core
> > changes). Which is ample evidence that the existing implementation
> > does a good job after all.
> 
> No, I don't think it is. It might be evidence that people know to seek
> alternative solutions instead of using b-c-f and a-c-f.

Fine with me.  I indeed prefer that in the current situation any bugs
this could cause be fixed or worked around in the packages that are
hit by them.  As long as these problems are rare and far between, that
is better than risking to break insdel and its callers, which could be
virtually anywhere.

If someone refactors insdel to introduce some significant new feature,
then instability can be justified.  But otherwise, it sounds nuts to
me to risk that, given the rarity of the problems and the ability of
the packages to work around them.  Especially, as we have no way
whatsoever of verifying the changes by tests.

> > That's exactly the nonchalant attitude towards changes in core that
> > explains why, after 30-odd years of development, which should have
> > given us an asymptotically more and more stable Emacs, we still
> > succeed quite regularly to break core code and basic features, while
> > "confidently" relying on our mythical abilities to refactor correctly
> > without any serious testing coverage.  Never again.
> 
> Can I deliberately misinterpret this as saying that you think that the
> changes would be fine so long as we add lots of tests at the same time?

Not "at the same time", but "as a prerequisite" for any serious
consideration of such changes.  IOW, I want to see the tests first,
decide whether I like their degree of coverage, and only then I will
be prepared to _talk_ about any changes in this area.  And the first
step in that talk will have to be someone presenting a rather complete
design of the changes, including an analysis of the current callers
and how each one (or each class) of them will work under the new
design.