From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: Confused by y-or-n-p Date: Tue, 5 Jan 2021 11:44:24 +0000 Message-ID: References: <871rf7ippu.fsf@mail.linkov.net> <83a6trg6mc.fsf@gnu.org> <87im8f951f.fsf@gnus.org> <83lfdacapo.fsf@gnu.org> <83sg7gbug6.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="27718"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , 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 12:46:26 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 1kwknC-00076V-2Z for ged-emacs-devel@m.gmane-mx.org; Tue, 05 Jan 2021 12:46:26 +0100 Original-Received: from localhost ([::1]:53922 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kwknB-000380-4D for ged-emacs-devel@m.gmane-mx.org; Tue, 05 Jan 2021 06:46:25 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:42484) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kwklK-00023Z-SI for emacs-devel@gnu.org; Tue, 05 Jan 2021 06:44:30 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:22090 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.90_1) (envelope-from ) id 1kwklH-0008Cm-6M for emacs-devel@gnu.org; Tue, 05 Jan 2021 06:44:30 -0500 Original-Received: (qmail 99062 invoked by uid 3782); 5 Jan 2021 11:44:24 -0000 Original-Received: from acm.muc.de (p4fe15a15.dip0.t-ipconnect.de [79.225.90.21]) by colin.muc.de (tmda-ofmipd) with ESMTP; Tue, 05 Jan 2021 12:44:24 +0100 Original-Received: (qmail 4642 invoked by uid 1000); 5 Jan 2021 11:44:24 -0000 Content-Disposition: inline In-Reply-To: X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de Received-SPF: pass client-ip=193.149.48.1; envelope-from=acm@muc.de; helo=mail.muc.de 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_NONE=0.001, SPF_PASS=-0.001 autolearn=unavailable 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:262515 Archived-At: Hello, Gregory. On Mon, Jan 04, 2021 at 22:17:51 +0000, Gregory Heytings via Emacs development discussions. wrote: > >>>> * If some are opposed, they install the feature with a variable to > >>>> enable it, disabled by default. > >>> This is already being done: every backward-incompatible change is > >>> either required to become compatible, or, if that's not feasible, to > >>> provide a way to get back the old behavior. In some rare cases this > >>> doesn't happen, but such mistakes are rare exceptions, they aren't the > >>> rule. > >> That's not correct, see for example the thread "Stop frames stealing > >> eachothers' minibuffers!", in which the longstanding behavior of Emacs' > >> minibuffers, which are arguably a central piece of Emacs' UI, is being > >> modified on the pretext that it is "unsystematic", without any > >> argument, and in spite of the fact that hundreds and thousands of users > >> have been using it without complaining about that supposed > >> "unsystematicity". > >> 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 think you "explained" at all, and certainly not before I started working on it - I initiated the discussion with a proposed patch so as to minimise the risk of just wasting people's time with bikeshedding. The word "explain" would entail you speaking with some special insight, some special knowledge, some authority. I don't think you had any of these, hence making the use of the word "explain" wrong. Indeed, I found it offensive for that reason. You were just expressing your point of view, one amongst several, that's all. > And I fear that trying to provide a better backward compatibility after > having removed the code of the old behavior is doomed to fail, it will > most likely result in an endless bug report / bug fix loop. You keep referring to an "old behaviour" that I removed, as though there were something coherent, something valuable, something worth keeping. I don't think there's anything of the kind. I think the former behaviour just happened by accident as a result of people working on other things, and nobody consciously made it happen. I am now consciously trying to fix it. If you've argued for an old behaviour on its merits, possibly in the thread "stealing eachother's minibuffers", could you perhaps point out the place in that thread, so that I can read it again. > > 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. 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. > What could have been done instead is to add some new code next to the > existing one to conditionally provide a new behavior, ..... That could not have been done, due to the state of the code in minibuf.c, in particular, due to the lack of any coherent "existing behaviour". > .... 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. > And the consequence of that pattern is what Richard fears: my comments, > which can be summarized as "please do not remove the old behavior", are > perceived by Alan almost as a personal attack. No. I see them as a misperception of the state of Emacs on your part. > This would not happen if we were doing what Richard suggests. -- Alan Mackenzie (Nuremberg, Germany).