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:50:05 +0200 Message-ID: <83wnwra15u.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="37816"; mail-complaints-to="usenet@ciao.gmane.io" Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Gregory Heytings Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Jan 05 16:56:31 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 1kwohB-0009hK-Ld for ged-emacs-devel@m.gmane-mx.org; Tue, 05 Jan 2021 16:56:29 +0100 Original-Received: from localhost ([::1]:50934 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kwohA-0006ht-NZ for ged-emacs-devel@m.gmane-mx.org; Tue, 05 Jan 2021 10:56:28 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:46600) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kwoga-0006HL-FI for emacs-devel@gnu.org; Tue, 05 Jan 2021 10:55:52 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:38246) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kwogX-0003Co-3S; Tue, 05 Jan 2021 10:55:49 -0500 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2322 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kwnf0-0000xO-CX; Tue, 05 Jan 2021 09:50:12 -0500 In-Reply-To: (emacs-devel@gnu.org) 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:262530 Archived-At: > Date: Mon, 04 Jan 2021 22:18:04 +0000 > Cc: emacs-devel@gnu.org > From: Gregory Heytings via "Emacs development discussions." > > I don't think that was Richard's point: we always go to great lengths to make it possible to get back the old behavior (even for changes where the impact is quite minor). > > E.g. with respect to `y-or-n-p`, I think we already all agree that there should be a way to recover the previous "modal" behavior. We just need someone to implement it (ideally while still preserving the improvement of the new minibuffer-based code). > > No always, alas. Yes, not always. It isn't feasible nor wise to do that "always", so please don't insist on such unrealistic goals. But in the vast majority of cases, we do go to great lengths (some say too great) to provide an option to get the old behavior back. This list and the bug list are replete with examples of that. > With respect to y-or-n-p, there is now indeed an agreement that there should be a way to recover the old behavior. But IIUC, Richard's point is that this possibility should have been present since the beginning, when the new behavior was introduced, without waiting for objections. It is impossible to promise that no one will ever make good-faith mistakes like this. The important point is to have procedures in place to detect such mistakes and fix them, without imposing too much overhead on the development. > What happened is (1) behavior A is removed and replaced by behavior B, (2) enough people object this change, (2) behavior B is implemented again. > > What could have happened instead is (1) behavior B is implemented, next to behavior A, with a way to choose between them, (2) at some point, possibly immediately, the default behavior is changed from A to B, (3) if after some time it becomes clear that behavior A is not used anymore, it is deprecated, and later again removed. The changes in the process proposed for making such cases rarer would cause a significant slowdown of the Emacs development, so my conclusion is that those proposals are unjustified given the small number of incidents that would presumably call for those changes. > Having both behaviors available at the same time is also, I believe, a necessary condition for a fruitful comparison and discussion. Otherwise the discussion is about the merits of a removed behavior vs. the new behavior instead of about the merits of a behavior A vs. a behavior B. It is very easy to compare without having both behaviors in the same binary: just keep old binaries around. That's what I do, and it allows me to quickly see what was past behavior, and even perform a quick "bisection" when some new problem is reported. Highly recommended.