From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Gregory Heytings via "Emacs development discussions." Newsgroups: gmane.emacs.devel Subject: Re: Confused by y-or-n-p Date: Mon, 04 Jan 2021 10:28:25 +0000 Message-ID: References: <834kkcr1eo.fsf@gnu.org> <43b24209-fa65-0e26-7cbd-f99175a7ffd8@gmx.at> <87wnx7j5is.fsf@mail.linkov.net> <83im8qnyca.fsf@gnu.org> <83bleinmse.fsf@gnu.org> <56435592-d2d0-5fb6-977f-01e1931da835@gmx.at> <87k0t38g1z.fsf@mail.linkov.net> <83czyvkts6.fsf@gnu.org> <87bleetirr.fsf@mail.linkov.net> <87y2hhri3n.fsf@mail.linkov.net> <83pn2tkfg8.fsf@gnu.org> <871rf7ippu.fsf@mail.linkov.net> <83a6trg6mc.fsf@gnu.org> <87im8f951f.fsf@gnus.org> <83lfdacapo.fsf@gnu.org> Reply-To: Gregory Heytings Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="15711"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Alpine 2.22 (NEB 394 2020-01-19) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Jan 04 11:29:25 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kwN75-0003wX-Rg for ged-emacs-devel@m.gmane-mx.org; Mon, 04 Jan 2021 11:29:23 +0100 Original-Received: from localhost ([::1]:46538 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kwN74-0003zf-SS for ged-emacs-devel@m.gmane-mx.org; Mon, 04 Jan 2021 05:29:22 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:49668) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kwN6J-0003GX-0X for emacs-devel@gnu.org; Mon, 04 Jan 2021 05:28:35 -0500 Original-Received: from mx.sdf.org ([205.166.94.24]:65181) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kwN6G-0001Up-BJ; Mon, 04 Jan 2021 05:28:34 -0500 Original-Received: from sdf.org (IDENT:ghe@faeroes.freeshell.org [205.166.94.9]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 104ASRPt003064 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Mon, 4 Jan 2021 10:28:27 GMT Original-Received: (from ghe@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 104ATAWE018278; Mon, 4 Jan 2021 10:29:10 GMT In-Reply-To: <83lfdacapo.fsf@gnu.org> Received-SPF: pass client-ip=205.166.94.24; envelope-from=ghe@sdf.org; helo=mx.sdf.org X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:262408 Archived-At: >> 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.