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 11:35:19 +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> 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="34052"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Alpine 2.22 (NEB 394 2020-01-19) Cc: emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Jan 04 12:36:12 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 1kwO9j-0008hW-Om for ged-emacs-devel@m.gmane-mx.org; Mon, 04 Jan 2021 12:36:11 +0100 Original-Received: from localhost ([::1]:46160 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kwO9i-0002oc-Qk for ged-emacs-devel@m.gmane-mx.org; Mon, 04 Jan 2021 06:36:10 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34900) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kwO93-0002Jl-R7 for emacs-devel@gnu.org; Mon, 04 Jan 2021 06:35:29 -0500 Original-Received: from mx.sdf.org ([205.166.94.24]:63022) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kwO91-0008P8-LO for emacs-devel@gnu.org; Mon, 04 Jan 2021 06:35:29 -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 104BZL7V011066 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Mon, 4 Jan 2021 11:35:22 GMT Original-Received: (from ghe@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 104Ba4Pw024377; Mon, 4 Jan 2021 11:36:04 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:262416 Archived-At: >> 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. > I haven't seen a single argument in that thread to remove the current behavior. I've only seen an argument that you (and only you AFAICS) don't like it. > > 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 never ever objected the idea of improving the minibuffer behavior. I strongly objected the idea of removing its longstanding behavior. >> 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". > No, quite the contrary. > > I put the old behaviour back as a result of your representations, > despite not understanding why anybody might want it. > That's the problem I mentioned in my other email: "because [some users] use Emacs in a way that was not envisioned by the developer who implemented the UI change, and that this UI change breaks their configuration, which relied on the old behavior". We cannot know what kind of exotic things people do with Emacs, and the only way to ensure that it is stable is to keep the old behavior alongside the new one, at least for some time. Some time later (one or two major releases later, say) the old behavior can of course be deprecated, with a target release when this will happen. That gives users the time to adapt their libraries and configurations. But all of a sudden removing the old behavior and installing a new one is IMO wrong. > > 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! > Not yet, I'll do that, but can't promise when. But the problem is that I am now, and everybody else is now, in a situation where we have to spend a lot of time testing various combinations of commands and to describe what doesn't work anymore, which inevitably leads to very long and boring mails and discussions.