Re: Confused by y-or-n-p

[Gregory Heytings]

> > The dynamic that results is this:
> >
> > * A few people decide to make a UI change, which many have not noticed.
> >
> > * Some people eventually notice it in master, or in a release, and 
> > maybe people start objecting.
> >
> > * At that point there is resistance to changing back.
>
> The resistance is understandable, but when this happens on master, and 
> the objections are valid and supported by enough people, we usually 
> augment or revert the change.

I don't think it's "enough people"; it is, rather, "important enough 
people" ;-)

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