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: Mon, 4 Jan 2021 11:02:55 +0000 Message-ID: References: <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> 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="11204"; 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 Mon Jan 04 12:04:24 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 1kwNex-0002lB-UW for ged-emacs-devel@m.gmane-mx.org; Mon, 04 Jan 2021 12:04:23 +0100 Original-Received: from localhost ([::1]:55658 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kwNew-0001fo-RH for ged-emacs-devel@m.gmane-mx.org; Mon, 04 Jan 2021 06:04:22 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56704) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kwNde-0001Eh-1N for emacs-devel@gnu.org; Mon, 04 Jan 2021 06:03:02 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:22384 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.90_1) (envelope-from ) id 1kwNda-0005SQ-IN for emacs-devel@gnu.org; Mon, 04 Jan 2021 06:03:01 -0500 Original-Received: (qmail 89275 invoked by uid 3782); 4 Jan 2021 11:02:56 -0000 Original-Received: from acm.muc.de (p4fe15a93.dip0.t-ipconnect.de [79.225.90.147]) by colin.muc.de (tmda-ofmipd) with ESMTP; Mon, 04 Jan 2021 12:02:55 +0100 Original-Received: (qmail 10359 invoked by uid 1000); 4 Jan 2021 11:02:55 -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:262410 Archived-At: Hello, Gregory. On Mon, Jan 04, 2021 at 10:28:25 +0000, Gregory Heytings via Emacs development discussions. wrote: > >> The dynamic that results is this: > >> * A few people decide to make a UI change, which many have not noticed. > >> * Some people eventually notice it in master, or in a release, and > >> maybe people start objecting. > >> * At that point there is resistance to changing back. > > The resistance is understandable, but when this happens on master, and > > the objections are valid and supported by enough people, we usually > > augment or revert the change. > I don't think it's "enough people"; it is, rather, "important enough > people" ;-) > >> * 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". There has been argument, on that other thread, which you have taken part in, and which now extends to nearly 200 posts. That few people complained about the old behaviour is not a strong argument against improving it. Many improvements to Emacs are made without being prompted by widespread complaints. > 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. It would thus appear that you are an "important enough person". I put the old behaviour back as a result of your representations, despite not understanding why anybody might want it. However, since I've tidied up the C code appreciably, I cannot guarantee that this behaviour is 100% the same as the old, hence the use of the word "approximate". Have you tried this patch out, yet? If there is anything in the "approximation" which is not close enough, perhaps you could point out what, so that I might fix it. Thanks! -- Alan Mackenzie (Nuremberg, Germany).