Re: Confused by y-or-n-p

[Gregory Heytings]

> > > > * If some are opposed, they install the feature with a variable to 
> > > > enable it, disabled by default.
> > >
> > > This is already being done: every backward-incompatible change is 
> > > either required to become compatible, or, if that's not feasible, to 
> > > provide a way to get back the old behavior. In some rare cases this 
> > > doesn't happen, but such mistakes are rare exceptions, they aren't the 
> > > rule.
> >
> > That's not correct, see for example the thread "Stop frames stealing 
> > eachothers' minibuffers!", in which the longstanding behavior of Emacs' 
> > minibuffers, which are arguably a central piece of Emacs' UI, is being 
> > modified on the pretext that it is "unsystematic", without any 
> > argument, and in spite of the fact that hundreds and thousands of users 
> > have been using it without complaining about that supposed 
> > "unsystematicity".
> >
> > I repeatedly explained that the old behavior should remain available. 
> > Initially the change explicitly removed the old behavior: "The old 
> > [behavior] is no longer available." The latest patch sent yesterday, 
> > only promises to "approximate" the old behavior.
>
> That's because the original behavior was deemed buggy.  We don't provide 
> compatibility options to get old bugs back.  As it turned out, what Alan 
> considered buggy behavior was not necessarily so, therefore he now tries 
> to provide a better backward compatibility.

It did not "turn out", I explained in detail that the behavior that Alan 
considered buggy was not at all buggy before he started working on this. 
And I fear that trying to provide a better backward compatibility after 
having removed the code of the old behavior is doomed to fail, it will 
most likely result in an endless bug report / bug fix loop.

> As the bug is still being actively worked on, it is premature ti draw 
> any definitive conclusions from it relevant to the current discussion.

I do believe it is relevant.

The general pattern is similar to the y-or-n-p one, in that the code of an 
UI behavior is removed and replaced by another one.  It is also, I think 
(but it's just a feeling, I did not follow the discussions at that time), 
similar to the changes in Emacs 27 about which Drew loudly complained and 
that make Emacs 27 unuseable for him.

What could have been done instead is to add some new code next to the 
existing one to conditionally provide a new behavior, with an easy way for 
users who prefer / need the old behavior to revert the change.  If this 
had been done with y-or-n-p, this thread would simply not exist.  If this 
had been done with the new minibuffer behavior, the "Stop frames stealing 
each other's minibuffers" thread would be very different.

And the consequence of that pattern is what Richard fears: my comments, 
which can be summarized as "please do not remove the old behavior", are 
perceived by Alan almost as a personal attack.  This would not happen if 
we were doing what Richard suggests.