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: Tue, 05 Jan 2021 16:57:01 +0200 Message-ID: <83sg7fa0ua.fsf@gnu.org> References: <834kkcr1eo.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="38430"; mail-complaints-to="usenet@ciao.gmane.io" Cc: juri@linkov.net, rudalics@gmx.at, stefankangas@gmail.com, larsi@gnus.org, emacs-devel@gnu.org, drew.adams@oracle.com, monnier@iro.umontreal.ca To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Jan 05 16:24:00 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 1kwoBg-0009pp-SR for ged-emacs-devel@m.gmane-mx.org; Tue, 05 Jan 2021 16:23:56 +0100 Original-Received: from localhost ([::1]:50520 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kwoBf-0000dC-U1 for ged-emacs-devel@m.gmane-mx.org; Tue, 05 Jan 2021 10:23:55 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:54690) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kwoAC-0007yE-4D for emacs-devel@gnu.org; Tue, 05 Jan 2021 10:22:24 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:35382) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kwoAB-0006Hu-SM; Tue, 05 Jan 2021 10:22:23 -0500 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2749 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kwnlk-0003pZ-NM; Tue, 05 Jan 2021 09:57:11 -0500 In-Reply-To: (message from Richard Stallman on Tue, 05 Jan 2021 01:33:50 -0500) 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:262526 Archived-At: > From: Richard Stallman > Cc: monnier@iro.umontreal.ca, juri@linkov.net, rudalics@gmx.at, > eliz@gnu.org, emacs-devel@gnu.org, larsi@gnus.org, > drew.adams@oracle.com > Date: Tue, 05 Jan 2021 01:33:50 -0500 > > > So here's a suggestion: perhaps we should think about > > sometimes carrying out time-boxed experiments on the master branch in > > controversial cases. For example: we add this keybinding now, to be > > revisited in 14/21/30 days and then a final discussion is taken to keep > > or revert it once people have gotten some experience with it. > > That's fine with me, but there should be a variable to enable the > changed behavior. That makes the experiment painless for everyone else. It is impractical to make a variable for every change in behavior. In some cases the change itself is a variable: for example introduction of a new option or a new binding gives you that variable as a side effect. In other cases we think we are fixing a bug or a confusing or incorrect behavior. In these cases we don't provide variables to get back the incorrect behavior, nor should we. In yet other cases the changes are so deep and significant that providing backward compatibility would impose an impossible toll that makes the entire changeset impractical. The rare problematic cases are when the judgment call about the nature of the change turns out to be a mistake. We should try to minimize such mistakes, but introducing a rule that _every_ change should necessarily come with a variable to disable or revert it is a cure that is much worse than the disease. I'm against such absurd measures. To be practical, a rule like this would need to come with some elaborate set of allowed exceptions, and that will undoubtedly trigger endless discussions about whether this or that particular change is or isn't an exception (because adding such compatibility shims is never a job developers like). We have such disputes already, because we do attempt to provide such options where deemed necessary. The proposed rule will make that much worse, so I'm against such an absolute rule.