Re: Confused by y-or-n-p

[Gregory Heytings]

> > I agree with you that this is already happening in the vast majority of 
> > cases, so why would it be problematic to make this a rule, that in 
> > principle any change to Emacs' behavior should provide a way to 
> > re-enable the old behavior?  IIUC that's all Richard wants.  Of course 
> > that rule would not apply to bugfixes, and exceptions would be possible 
> > with the explicit approval of a maintainer.
>
> The problem is that I disagree with your "Of course": the whole 
> difficulty is to decide which change falls in this category.
>
> The problem is not that we don't follow the rule or that we don't have 
> such a rule.  It's that there's no hard-and-fast way to decide where 
> that rule should apply: it's a judgment call and often this call is 
> non-trivial (what one person calls "feature" qualifies as "bug fix" for 
> another, what should be a cosmetic change may end up unexpectedly 
> changing behavior), which is why sometimes it takes feedback from users 
> to realize we got it wrong.

A rule is not a mathematical law, it's an action guideline.  Such a rule 
would avoid having developers start working on something thinking that 
scratching the current state of affairs to create something they believe 
is better without thinking about backwards compatibility is okay.

This does happen, and this can lead and does lead to unnecessary disputes 
(one is underway), that could be avoided with such a rule.

By the way, the feedback in this case came from Richard, who wanted the 
old behavior back, and he got it back in a few days.  I'm curious whether 
this would have happened if the feedback had been sent by a random user.