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

[Eli Zaretskii]

> Cc: address@hidden, address@hidden
> From: Daniel Colascione <address@hidden>
> Date: Mon, 29 Aug 2016 08:30:21 -0700
> 
> >> 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.

Of course, you have changed the subject.

> 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.

It doesn't matter what I understand or not, because that's not the
issue at hand.  We are talking about code that runs virtually
unchanged for many years.  Making significant changes in it needs a
good reason.  When such good reasons emerge, we can discuss whether
they justify the risks.  For now, the reasons presented do not.

> The current implementation is buggy.

Every piece of software is buggy.  That doesn't mean it's useless or
must be refactored the heck out of.

> (the file visit case). These bugs produce difficult-to-diagnose user
> bugs reports. that have generated real bug reports.

Those bugs were fixed.

> 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 not interested in an argument about correctness.  That's not what
this is about.  You are changing the subject again.

> > 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.

No one have forbidden all change, and no one in their right minds
will.  Do you really not understand what the above is about?

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

If you aren't interested in it doing anything useful, sure.  But I am,
so these simple solutions are wrong for me (and for all the rest of
Emacs users).

Of course, if those absurd "arguments" are the only ones you have
left, I guess this is EOD.