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 22:18:04 +0000 Message-ID: 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> 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="28544"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Alpine 2.22 (NEB 394 2020-01-19) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Jan 04 23:24:32 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 1kwYHA-0007Ks-0j for ged-emacs-devel@m.gmane-mx.org; Mon, 04 Jan 2021 23:24:32 +0100 Original-Received: from localhost ([::1]:46996 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kwYH9-0001dp-1x for ged-emacs-devel@m.gmane-mx.org; Mon, 04 Jan 2021 17:24:31 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:42890) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kwYB4-0004Y5-7I for emacs-devel@gnu.org; Mon, 04 Jan 2021 17:18:14 -0500 Original-Received: from mx.sdf.org ([205.166.94.24]:56259) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kwYB2-00018p-1F for emacs-devel@gnu.org; Mon, 04 Jan 2021 17:18:13 -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 104MI6Tq016968 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Mon, 4 Jan 2021 22:18:07 GMT Original-Received: (from ghe@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 104MImJj023109; Mon, 4 Jan 2021 22:18:48 GMT In-Reply-To: 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:262484 Archived-At: >> I agree with you, but I think you are missing Richard's main point: any >> significant UI change should either require setting a variable, or >> provide a way to disable the new behavior / re-enable to old behavior. > > 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. 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. 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. 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.