From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: Stop frames stealing eachothers' minibuffers! Date: Sat, 28 Nov 2020 10:45:34 +0000 Message-ID: References: <53833023-d959-07af-7611-aa2e0bdcc1bc@gmx.at> <0d14bfc4-8e8e-d3b9-e0e1-ee4bf2e6449d@gmx.at> <20201125210947.GB8228@ACM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="25966"; mail-complaints-to="usenet@ciao.gmane.io" Cc: enometh@meer.net, Eli Zaretskii , Stefan Monnier , Andrii Kolomoiets , emacs-devel@gnu.org To: Gregory Heytings , martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Nov 28 11:46:43 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 1kixkZ-0006fH-6z for ged-emacs-devel@m.gmane-mx.org; Sat, 28 Nov 2020 11:46:43 +0100 Original-Received: from localhost ([::1]:40216 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kixkY-00061f-1z for ged-emacs-devel@m.gmane-mx.org; Sat, 28 Nov 2020 05:46:42 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36158) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kixja-0005aD-Ix for emacs-devel@gnu.org; Sat, 28 Nov 2020 05:45:42 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:53085 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.90_1) (envelope-from ) id 1kixjX-00016k-9J for emacs-devel@gnu.org; Sat, 28 Nov 2020 05:45:42 -0500 Original-Received: (qmail 72372 invoked by uid 3782); 28 Nov 2020 10:45:34 -0000 Original-Received: from acm.muc.de (p2e5d54e3.dip0.t-ipconnect.de [46.93.84.227]) by localhost.muc.de (tmda-ofmipd) with ESMTP; Sat, 28 Nov 2020 11:45:34 +0100 Original-Received: (qmail 6021 invoked by uid 1000); 28 Nov 2020 10:45:34 -0000 Content-Disposition: inline In-Reply-To: X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de Received-SPF: pass client-ip=193.149.48.1; envelope-from=acm@muc.de; helo=mail.muc.de 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_NONE=0.001, SPF_PASS=-0.001 autolearn=unavailable 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:259949 Archived-At: Hello, Gregory and Martin. On Fri, Nov 27, 2020 at 07:33:04 +0000, Gregory Heytings wrote: [ .... ] > | 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. The abstract cause of this situation would appear to be using F1's minibuffer while a more deeply nested minibuffer is still active. It is a violation of the "recursive" nature of these buffers. I think a solution would be to put F1's minibuffer into minibuffer-inactive-mode until the recursive MB in F2 has terminated. What do you think of this? -- Alan Mackenzie (Nuremberg, Germany).