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:48:47 +0200 Message-ID: <83y2h7a180.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> <83a6trg6mc.fsf@gnu.org> <87im8f951f.fsf@gnus.org> <83lfdacapo.fsf@gnu.org> <83sg7gbug6.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="5101"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 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:25:30 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 1kwoDB-0001A0-E4 for ged-emacs-devel@m.gmane-mx.org; Tue, 05 Jan 2021 16:25:29 +0100 Original-Received: from localhost ([::1]:53338 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kwoDA-0001ts-Fe for ged-emacs-devel@m.gmane-mx.org; Tue, 05 Jan 2021 10:25:28 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:55616) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kwoBm-0000xb-DE for emacs-devel@gnu.org; Tue, 05 Jan 2021 10:24:02 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:35343) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kwoBl-0004kL-Uu; Tue, 05 Jan 2021 10:24:01 -0500 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2242 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kwndn-0008Uu-3s; Tue, 05 Jan 2021 09:48:55 -0500 In-Reply-To: (message from Gregory Heytings on Mon, 04 Jan 2021 22:17:51 +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:262527 Archived-At: > Date: Mon, 04 Jan 2021 22:17:51 +0000 > From: Gregory Heytings > cc: emacs-devel@gnu.org > > I repeatedly explained that the old behavior should remain available. Initially the change explicitly removed the old behavior: "The old [behavior] is no longer available." The latest patch sent yesterday, only promises to "approximate" the old behavior. > > That's because the original behavior was deemed buggy. We don't provide compatibility options to get old bugs back. As it turned out, what Alan considered buggy behavior was not necessarily so, therefore he now tries to provide a better backward compatibility. > > It did not "turn out", I explained in detail that the behavior that Alan considered buggy was not at all buggy before he started working on this. I don't see the relevance of this. We are talking about the process, so the details of who said what and when to make the developer aware that the presumed buggy behavior isn't -- those details aren't important for the purposes of the current discussions, and not naming the person(s) who contributed to this doesn't mean their contribution is not acknowledged. > As the bug is still being actively worked on, it is premature ti draw any definitive conclusions from it relevant to the current discussion. > > I do believe it is relevant. > > The general pattern is similar to the y-or-n-p one, in that the code of an UI behavior is removed and replaced by another one. The UI didn't change at all in the case of minibuffer tracking. The commands are still the same commands. What changed is the behavior of Emacs in response to these commands. That _is_ different from the y-or-n-p case. > It is also, I think (but it's just a feeling, I did not follow the discussions at that time), similar to the changes in Emacs 27 about which Drew loudly complained and that make Emacs 27 unuseable for him. We don't really know what makes Emacs 27 unusable for Drew, because we don't have enough information regarding the problems he faces, and no one else reported anything similar, so it seems. So I cannot see how the issue of Emacs 27's usability for Drew can support any conclusions yet. > What could have been done instead is to add some new code next to the existing one to conditionally provide a new behavior, with an easy way for users who prefer / need the old behavior to revert the change. If this had been done with y-or-n-p, this thread would simply not exist. If this had been done with the new minibuffer behavior, the "Stop frames stealing each other's minibuffers" thread would be very different. Like I said, sometimes changes run so deep that providing options to get the precise past behavior is not feasible. E.g., see the example of the bidi display.