From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Confused by y-or-n-p Date: Mon, 04 Jan 2021 17:19:53 +0200 Message-ID: <83sg7gbug6.fsf@gnu.org> 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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="23092"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Gregory Heytings Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Jan 04 16:21:57 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 1kwRgD-0005rF-6a for ged-emacs-devel@m.gmane-mx.org; Mon, 04 Jan 2021 16:21:57 +0100 Original-Received: from localhost ([::1]:50618 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kwRgC-0002mB-7f for ged-emacs-devel@m.gmane-mx.org; Mon, 04 Jan 2021 10:21:56 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:55764) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kwReS-0001fP-Ll for emacs-devel@gnu.org; Mon, 04 Jan 2021 10:20:08 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:36476) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kwReS-0008Ok-2e; Mon, 04 Jan 2021 10:20:08 -0500 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:3517 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kwReN-0007Vu-A0; Mon, 04 Jan 2021 10:20:04 -0500 In-Reply-To: (message from Gregory Heytings on Mon, 04 Jan 2021 10:28:25 +0000) 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:262435 Archived-At: > Date: Mon, 04 Jan 2021 10:28:25 +0000 > From: Gregory Heytings > cc: emacs-devel@gnu.org > > * 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. As the bug is still being actively worked on, it is premature ti draw any definitive conclusions from it relevant to the current discussion. Also, we should recognize that some changes are deep enough to make 100% backward compatibility impractical or even infeasible. That doesn't mean such changes should be automatically rejected.