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: Sat, 02 Jan 2021 09:06:35 +0200 Message-ID: <83a6trg6mc.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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="30140"; mail-complaints-to="usenet@ciao.gmane.io" Cc: rudalics@gmx.at, emacs-devel@gnu.org, juri@linkov.net To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Jan 02 08:07:36 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 1kvb0h-0007l2-Vc for ged-emacs-devel@m.gmane-mx.org; Sat, 02 Jan 2021 08:07:35 +0100 Original-Received: from localhost ([::1]:44914 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kvb0h-0007Py-0s for ged-emacs-devel@m.gmane-mx.org; Sat, 02 Jan 2021 02:07:35 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:44502) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kvb0D-00071D-6Q for emacs-devel@gnu.org; Sat, 02 Jan 2021 02:07:05 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:48694) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kvb0B-0002nW-Eq; Sat, 02 Jan 2021 02:07:03 -0500 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:1721 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kvazz-0004ci-5D; Sat, 02 Jan 2021 02:06:53 -0500 In-Reply-To: (message from Richard Stallman on Sat, 02 Jan 2021 00:25:37 -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:262293 Archived-At: > From: Richard Stallman > Cc: eliz@gnu.org, rudalics@gmx.at, emacs-devel@gnu.org > Date: Sat, 02 Jan 2021 00:25:37 -0500 > > I think that y-or-n-p-use-read-key should default to t. > There is no hurry about making this change. Personally, I won't mind reversing the default, FWIW. > After this is included in a release, we can ask users > to try the value t for a week or two and tell us whether they like it. > Then we can tell which default is best. This is not practical, IME. Adoption of a new release by users is very slow; I wouldn't be surprised if a year passed before major distros made a new release their main one. E.g., we are still getting bug reports from people who use Emacs 25 and even 24, let alone 26, although Emacs 27.1 was released 5 months ago. So waiting for user reports could take a year or more, and by that time we will probably have the next minor release, so the setting becomes the de-facto standard that will be harder to change back. That is why changes in behavior are usually accompanied by a documented (in NEWS) way of getting the old behavior back. This way, users who want the old behavior can silently do that locally, and only very annoying behavior changes generate so many bug reports that we later consider reverting it.