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: Stop frames stealing eachothers' minibuffers! Date: Thu, 07 Jan 2021 23:34:18 +0000 Message-ID: References: <20201125210947.GB8228@ACM> <50c96c83-01b4-d2b8-ff90-82c9d706e268@gmx.at> 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="19658"; 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 Fri Jan 08 00:35:36 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 1kxeoa-0004yO-Cf for ged-emacs-devel@m.gmane-mx.org; Fri, 08 Jan 2021 00:35:36 +0100 Original-Received: from localhost ([::1]:52074 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kxeoZ-0001E9-BZ for ged-emacs-devel@m.gmane-mx.org; Thu, 07 Jan 2021 18:35:35 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:33654) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kxenV-0000PD-OM for emacs-devel@gnu.org; Thu, 07 Jan 2021 18:34:29 -0500 Original-Received: from mx.sdf.org ([205.166.94.24]:60736) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kxenT-0004VL-KT for emacs-devel@gnu.org; Thu, 07 Jan 2021 18:34: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 107NYLSn015878 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Thu, 7 Jan 2021 23:34:21 GMT Original-Received: (from ghe@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 107NYs5t020243; Thu, 7 Jan 2021 23:34:54 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:262714 Archived-At: > > Let me repeat, it is not the content of your posts I find difficult to > deal with. It's their rudeness and aggressiveness. > I think we are miscommunicating. I honestly don't understand where you perceive "rudeness and aggressiveness" in my posts. I can only say again that this was not at all my intention. > >> The old behavior is indeed valuable, if only because it is an old >> behavior. > > So you're defending old bugs as valuable, simply because they're old. > You decline to defend this behaviour on its merits. Nobody else has > done so either, as far as I'm aware. > I did defend it on its merits, multiple times. What I said did not convince you; I should perhaps have written something more detailed, as I do below. I experienced the behavior which surprised you from time to time, and found it coherent with the general Emacs behavior. Let's first define that behavior again: from a user's point of view, in Emacs 21 (and possibly earlier) to 27, when minibuffers MB1 to MBn are active on a frame F1, and a command that activates the minibuffer is started on a frame F2, the minibuffers MB1 to MBn are moved to frame F2, and the minibuffer MBn+1 is created. This behavior happens with enable-recursive-minibuffers set to t, either globally or temporarily. The other possible behaviors are, AFAICS, the ones you try to implement: 1. Either tying each minibuffer to the frame in which it is created. If you tie each minibuffer to the frame in which it was created, there are two options: 1.1. Either it becomes possible to interact with them. From an UI point of view, the problem of that behavior is that it is not coherent with recursive edits in Emacs, of which recursive minibuffers are an instance. When you enter a recursive edit you cannot act on the non-recursive edit level or on the previous recursive edit levels anymore, you first have to leave the current recursive edit. As the Emacs manual explains, recursive edits "constrain you to go back in a particular order---from the innermost level toward the top level." IOW, that behavior would violate the general recursive editing constraint. 1.2. Or you make sure in one way or another that it is not possible to interact with them, which means that the user sees a minibuffer that it cannot use (for instance by clicking on it). From an UI point of view, this would be counter-intuitive; I don't know any other UI element that is displayed by Emacs and that you cannot interact with. 2. Or always moving the minibuffers to the currently active frame. From an UI point of view, the problem is that such a movement is, in most cases, gratuitious: when you start a command in a frame and switch to another frame, in most cases this switch is a temporary one (for example to check the documentation of the command you just started), and what you intend to do is to switch back to the frame in which you started the command to complete it. The old behavior, which you despise, is not "chaotic" (see the definition of that word in Wordnet: "completely unordered and unpredictable and confusing", or in Wiktionary: "extremely disorganized"), it is well-defined, and it is a reasonable solution which avoids (at least) these three problems. And it has worked well for virtually all Emacs users in the last twenty years. There is, in fact, a fourth possible behavior, which AFAICT has not been discussed in this thread: 1.3. Tying each minibuffer to the frame in which it is created, but make it invisible when a recursive minibuffer is entered in another frame, and visible again when that recursive minibuffer is left. The problem I see in this potential behavior is that, upon leaving the recursive minibuffer, the user would have no indication that another minibuffer is still (or rather, again) open in another frame, waiting for their input. This is yet another problem that the old behavior avoids.