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: Fri, 08 Jan 2021 09:16:26 +0200 Message-ID: <83lfd3kiet.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> <83mtxqcauz.fsf@gnu.org> <83turva0y2.fsf@gnu.org> <83v9c8ltys.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="17861"; mail-complaints-to="usenet@ciao.gmane.io" Cc: rms@gnu.org, juri@linkov.net, rudalics@gmx.at, stefankangas@gmail.com, emacs-devel@gnu.org, monnier@iro.umontreal.ca To: Gregory Heytings Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Jan 08 08:18:38 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 1kxm2f-0004VT-Fj for ged-emacs-devel@m.gmane-mx.org; Fri, 08 Jan 2021 08:18:37 +0100 Original-Received: from localhost ([::1]:48180 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kxm2e-0006Wl-Eo for ged-emacs-devel@m.gmane-mx.org; Fri, 08 Jan 2021 02:18:36 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:54154) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kxm0j-0005eJ-5m for emacs-devel@gnu.org; Fri, 08 Jan 2021 02:16:37 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:49261) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kxm0i-0008V4-II; Fri, 08 Jan 2021 02:16:36 -0500 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2533 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kxm0X-0007pb-NJ; Fri, 08 Jan 2021 02:16:26 -0500 In-Reply-To: (message from Gregory Heytings on Thu, 07 Jan 2021 23:34:09 +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:262733 Archived-At: > Date: Thu, 07 Jan 2021 23:34:09 +0000 > From: Gregory Heytings > cc: stefankangas@gmail.com, monnier@iro.umontreal.ca, rudalics@gmx.at, > emacs-devel@gnu.org, rms@gnu.org, juri@linkov.net > > > >> It is happening in the "Stop frames stealing each other's minibuffers" > >> thread > > > > No, it doesn't. In fact, the exact opposite happens there: an > > assumption that the existing behavior is a bug was later reversed based > > on feedback from you and others. > > Alas, this is not what is happening there. The old behavior has been > lost, and the developer who initiated these changes still firmly believes > that the old behavior is "an ad hoc unsystematic mess, not worthy even of > being called a behaviour", that it is "chaotic", that it is an "abstruse > "design" [that] can only have arisen by accident", that it "would get > rejected out of hand, and indeed ridiculed" if it were proposed now. In > spite of this, an approximation of the old behavior is now planned, and > I'm supposed to document where that current approximation differs from the > old behavior, to fix the current approximation. There is of course no > chance that the behavior of an UI element as complex as the minibuffer > could ever be recovered by working that way. There's no contradiction between what I said and what you say, when we consider what happens in practice. In practice Alan works on providing an option to have the best approximation to past behavior that is practical, given the extensive source code changes he has done. That is consistent with the "best effort" nature of providing backward compatibility in such cases, so I'm okay with that. We have other cases where changes were so extensive that providing the 100% backward-compatibility option is impractical. (This is one reason why a dogmatic rule for providing such options is something I cannot agree to.)