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: Sat, 28 Nov 2020 20:59:04 +0000 Message-ID: References: <53833023-d959-07af-7611-aa2e0bdcc1bc@gmx.at> <0d14bfc4-8e8e-d3b9-e0e1-ee4bf2e6449d@gmx.at> <20201125210947.GB8228@ACM> 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="17560"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Alpine 2.22 (NEB 394 2020-01-19) Cc: Alan Mackenzie , Andrii Kolomoiets , emacs-devel@gnu.org, martin rudalics , enometh@meer.net, Eli Zaretskii To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Nov 28 22:00:21 2020 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 1kj7KO-0004Uc-SS for ged-emacs-devel@m.gmane-mx.org; Sat, 28 Nov 2020 22:00:20 +0100 Original-Received: from localhost ([::1]:56896 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kj7KN-000429-Pg for ged-emacs-devel@m.gmane-mx.org; Sat, 28 Nov 2020 16:00:19 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:51640) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kj7JU-000355-8O for emacs-devel@gnu.org; Sat, 28 Nov 2020 15:59:24 -0500 Original-Received: from mx.sdf.org ([205.166.94.24]:57663) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kj7JR-0007gD-5E; Sat, 28 Nov 2020 15:59:24 -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 0ASKx7ED012297 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Sat, 28 Nov 2020 20:59:08 GMT Original-Received: (from ghe@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 0ASKxeWK021434; Sat, 28 Nov 2020 20:59:40 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:259975 Archived-At: > > More specifically, it's the act of leaving MB1 when there's a deeper MB2 > active: the code for leaving a minibuffer (e.g. `exit-minibuffer` or > `abort-recursive-edit`) doesn't actually pay attention to which > minibuffer is currently being used: while it's run from MB1 it actually > exits MB2. I'm not completely sure why we end up with a broken state, > but I guess it's because some of the code that "deactivates" the > minibuffer upon exit in run in the minibuffer that the users thought > they were about to exit rather than in the one that is actually exited. > Isn't the main reason for this that it has never been possible to interact with a MBn when a MBm, with m > n, was active? IOW, that exit-minibuffer was so far only meant to be used for the most recent minibuffer? BTW, I played a bit with this, and it seems that recursive minibuffers on more than two frames do not work correctly, since Emacs 21 at least. Here is a recipe you can try with Emacs 21-28: emacs -Q M-: (setq enable-recursive-minibuffers t) RET C-x C-f ; create MB1 on frame F1 C-x 5 2 C-x C-f ; move MB1 to frame F2 and create MB2 C-x 5 2 C-x C-f .emacs RET ; create MB3 on frame F3, open file in frame F3 C-x o .emacs RET ; activate MB2 on frame F3, open file in frame F2 At that point MB2 is moved to frame F2, and is now unuseable (in minibuffer-inactive-mode). You can either abort-recursive-edit (which works), or exit-recursive-edit (which, strangely, opens Dired on frame F1). You can add more frames to the recipe, only the two last ones will work as expected. What should have happened is that, at the end of the recipe, MB2 should have been exited and MB1 should be activated on frame F3, so that C-x o .emacs RET would open the file in frame F1. > > One way to address it might be to make every minibuffer use a different > exit tag (instead of the constant `exit` symbol), so that the `throw` > will not be caught by some unrelated `catch`. Additionally, we may want > to tweak `exit-minibuffer` and `abort-recursive-edit` so that the user > is warned/prompted before "silently" canceling that other (deeper) > minibuffer. > Is such an added complexity really worth the price? IMO the old behavior (with the bug above fixed) and a new behavior "minibuffer-follows-selected-frame" which would give a similar experience to that of using a minibuffer-only window, should be enough. What is the added value of tying minibuffers to the frames in which they were created, compared to the price of implementing that feature?