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

[Daniel Colascione]

On 08/29/2016 07:50 AM, Eli Zaretskii wrote:
> > From: Daniel Colascione <address@hidden>
> > Date: Sun, 28 Aug 2016 20:18:32 -0700
> >
> >     Please trust me that the documentation misleads.
>
> You are welcome to suggest more accurate wording that describes the
> current implementation.

Just mark b-c-f deprecated.

> > b-c-f and a-c-f are symmetric in name and signature. b-c-f is documented as "List of functions 
> > to call before each text change." a-c-f is documented as "List of functions to call after 
> > each text change." The elisp manual documentation is similarly symmetric. This symmetry 
> > produces an expectation that the behavior is symmetric, and this expectation is reinforced by how 
> > the observed behavior is almost always symmetric in practice. Symmetric behavior here is also what 
> > intuitively makes sense.
>
> This is a naïve interpretation of what a "change" means and entails.

It doesn't matter what a "change" means and entails. Whatever a "change" 
is, b-c-f and a-c-f use the same word for it, and I've already explained 
why it's natural to suppose symmetry between these hooks. In order for 
b-c-f and a-c-f to be asymmetric, the definition of the word "change" 
needs to somehow change.

Do you really not understand why many people would find the current 
behavior surprising? You have at least *three* people independently 
annoyed by it: Alan, Phillip Lord, and me.

> > Sure, I guess you could argue that current Emacs behavior is consistent with 
> > the manual, but it's not what anyone would reasonably expect, and the current 
> > behavior is surprising even to people who have been writing elisp for a long 
> > time.
>
> Surprising or not, the existing implementation is in use for many
> years, and until now no complaints were presented about it.  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.

The current implementation is buggy. Even Stefan agrees that it 
currently contains bona fide bugs (the file visit case). These bugs 
produce difficult-to-diagnose user bugs reports. that have generated 
real bug reports. The current implementation does not serve the needs of 
its users.

I mean, you could just declare the current implementation correct and 
point to workarounds as evidence of the fact --- but that's like 
declaring a drain unclogged by definition and pointing to the plunger as 
evidence.

> > I'm confident that with enough review, the core code could be changed to make 
> > b-c-f and a-c-f symmetric without causing weird bugs elsewhere. The necessary 
> > refactoring will probably make the logic cleaner as well.
> >
> > Of course there's a risk that changing b-c-f will itself produce weird side 
> > effects, but I have a hard time seeing how any code could actually depend on 
> > the current surprising behavior.
>
> 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.

The modern software engineering approach to preventing regressions is 
test automation. Insisting on adding a test as part of the change is 
reasonable. Forbidding all change, no matter how carefully done, is not.

>  Never again.

The surest way to make sure a computer doesn't do anything wrong is to 
turn it off.