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

[Daniel Colascione <dancol@dancol.org>]

On 08/29/2016 07:50 AM, Eli Zaretskii wrote:
>> From: Daniel Colascione <dancol@dancol.org>
>> 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.