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: Fri, 27 Nov 2020 07:33:04 +0000 Message-ID: References: <20201123133613.GA4635@ACM> <69ba00e6-b182-77e1-911b-d70f9fffa762@gmx.at> <20201123160703.GB4635@ACM> <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="33749"; 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, enometh@meer.net, Stefan Monnier , Eli Zaretskii To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Nov 27 08:35:53 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 1kiYIL-0008gC-D8 for ged-emacs-devel@m.gmane-mx.org; Fri, 27 Nov 2020 08:35:53 +0100 Original-Received: from localhost ([::1]:58402 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kiYIK-0007Xt-F6 for ged-emacs-devel@m.gmane-mx.org; Fri, 27 Nov 2020 02:35:52 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:59532) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kiYGF-0006LZ-7E for emacs-devel@gnu.org; Fri, 27 Nov 2020 02:33:43 -0500 Original-Received: from mx.sdf.org ([205.166.94.24]:54755) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kiYGC-0004Kx-TF; Fri, 27 Nov 2020 02:33:42 -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 0AR7X6rE019445 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Fri, 27 Nov 2020 07:33:06 GMT Original-Received: (from ghe@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 0AR7Xdbw028903; Fri, 27 Nov 2020 07:33:39 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:259849 Archived-At: [Apparently this email I sent a few hours ago did not reach the mailing list. I apologize if you receive it twice.] >> I wouldn't write it is "chaotic". The behavior you consider "chaotic" >> is well-defined, and has been there since Emacs 21 at least: the >> minibuffer moves from frame F1 to frame F2 if and only if the >> minibuffer is active on frame F1 and a recursive minibuffer is entered >> on frame F2. There are other possible behaviors of course, but IMO the >> current one is a reasonable one. > > The basic behavioral change I see is with 'enable-recursive-minibuffers' > non-nil and two frames: When I type C-h f setq in the first frame and > C-h f cons in the second frame, hit RET, reselect the minibuffer window > and hit RET again, with Emacs 27 a help window pops up in the first > frame while Emacs 28 reuses the help window of the second frame. In > both cases the second RET goes to the second frame and both behaviors > seem reasonable to me. > > If, with Emacs 28, I set 'minibuffer-follows-selected-frame' to non-nil, > the behavior does not entirely match that of Emacs 27 because the second > RET must be typed in the first frame. So if some application relies on > the exact replication of the behavior of Emacs 27, we have a regression. > Note that this patch and discussion started with the following observation (on Oct 13): > (i) Have two frames open displaying buffers. > (ii) On frame F1 do C-x b. This leaves a minibuffer open there. > (iii) Move to F2. > (iv) Do C-x 8 RET . > F1's minibuffer is now on F2. This is bad. It is indeed not possible to replicate the behavior of Emacs 27 and earlier. What we have is, for example: | Emacs 21-27 | Emacs 28 with (setq m-f-s-f t) | Emacs 28 with (setq m-f-s-f nil) A | MB1 on F1 | MB1 on F2 | MB1 on F1 B | MB1+2 on F2 | MB1+2 on F2 | MB1 on F1, MB2 on F2 [1] A: type C-x C-f on frame F1, switch to frame F2 B: type C-x C-f on frame F1, switch to frame F2, type M-: [1] There is also a severe regression in this case. Type C-x C-f on frame F1, switch to frame F2, type M-:. "Find file" is still visible in the miniwindow on frame F1; switch to frame F1. Experiment 1: Type the name of a file and RET. You'll get the error message "End of file during parsing", and MB2 on frame F2 will be left. MB1 is now unuseable, and impossible to leave, it will stay on F1 whatever you do. Experiment 2: Type C-g. MB2 on frame F2 will be left, and "Find file" will stay in MB1 on frame F1. However you cannot use it anymore, the keymap of MB1 is now minibuffer-inactive-mode-map. And like in experiment 1, you cannot leave it.