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: Thu, 07 Jan 2021 23:34:09 +0000 Message-ID: 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> 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="19731"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Alpine 2.22 (NEB 394 2020-01-19) Cc: rms@gnu.org, juri@linkov.net, rudalics@gmx.at, stefankangas@gmail.com, emacs-devel@gnu.org, monnier@iro.umontreal.ca To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Jan 08 00:35:37 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 1kxeob-000505-A7 for ged-emacs-devel@m.gmane-mx.org; Fri, 08 Jan 2021 00:35:37 +0100 Original-Received: from localhost ([::1]:52140 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kxeoa-0001Ff-Bn for ged-emacs-devel@m.gmane-mx.org; Thu, 07 Jan 2021 18:35:36 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:33666) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kxenX-0000PW-09 for emacs-devel@gnu.org; Thu, 07 Jan 2021 18:34:31 -0500 Original-Received: from mx.sdf.org ([205.166.94.24]:60735) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kxenU-0004Vq-80; Thu, 07 Jan 2021 18:34:30 -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 107NYCGC026132 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Thu, 7 Jan 2021 23:34:12 GMT Original-Received: (from ghe@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 107NYjej022008; Thu, 7 Jan 2021 23:34:45 GMT In-Reply-To: <83v9c8ltys.fsf@gnu.org> 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:262715 Archived-At: >> 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.