|Subject:||Re: Confused by y-or-n-p|
|Date:||Mon, 04 Jan 2021 10:28:25 +0000|
|User-agent:||Alpine 2.22 (NEB 394 2020-01-19)|
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.
|[Prev in Thread]||Current Thread||[Next in Thread]|