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: Sun, 22 Nov 2020 10:59:47 +0000 Message-ID: <20201122105947.GA5912@ACM> References: <20201119104035.GB6259@ACM> <9aacff47-8ac2-93a2-5112-6153ee986b57@gmx.at> <20201120210005.GA1034@ACM> <20201121102751.GA11643@ACM> <18a901b8-3250-b461-eb2a-c13988616e93@gmx.at> <20201121124550.GB11643@ACM> <535bd6d4-3997-2e64-ea43-5de6f0892062@gmx.at> 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="39520"; mail-complaints-to="usenet@ciao.gmane.io" Cc: enometh@meer.net, Eli Zaretskii , Stefan Monnier , Andrii Kolomoiets , emacs-devel@gnu.org To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Nov 22 12:01:11 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 1kgn7G-000ABo-Sb for ged-emacs-devel@m.gmane-mx.org; Sun, 22 Nov 2020 12:01:10 +0100 Original-Received: from localhost ([::1]:53972 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kgn7F-0002iA-Sc for ged-emacs-devel@m.gmane-mx.org; Sun, 22 Nov 2020 06:01:09 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53796) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kgn63-00027l-4t for emacs-devel@gnu.org; Sun, 22 Nov 2020 05:59:55 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:15497 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.90_1) (envelope-from ) id 1kgn60-0005v8-2x for emacs-devel@gnu.org; Sun, 22 Nov 2020 05:59:54 -0500 Original-Received: (qmail 26021 invoked by uid 3782); 22 Nov 2020 10:59:48 -0000 Original-Received: from acm.muc.de (p2e5d52bc.dip0.t-ipconnect.de [46.93.82.188]) by localhost.muc.de (tmda-ofmipd) with ESMTP; Sun, 22 Nov 2020 11:59:47 +0100 Original-Received: (qmail 10098 invoked by uid 1000); 22 Nov 2020 10:59:47 -0000 Content-Disposition: inline In-Reply-To: <535bd6d4-3997-2e64-ea43-5de6f0892062@gmx.at> 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:259602 Archived-At: Hello, Martin. On Sat, Nov 21, 2020 at 16:53:11 +0100, martin rudalics wrote: > > Where do you see the failure happening with that quick and dirty patch? > Load (via --load) a file with the following contents: > (setq default-frame-alist '((minibuffer . nil))) > (setq enable-recursive-minibuffers t) > (defun foo () > (interactive) > (read-from-minibuffer "...?") > (insert (format "%s" (selected-frame)))) > (global-set-key [(control meta +)] 'foo) > Now type C-x 5 2 followed by C-M-+ in one of the normal frames. Then > type C-M-+ in the other normal frame and type RET in the minibuffer > frame. Here I get in *scratch* > # > and only answering the second prompt gets me a normal frame inserted. Yes. It seems my patch from yesterday was too complicated. At the record_unwind_protect for the window configuration of the calling frame (when that is different from the minibuffer frame) in read_minibuf, we can set it up later to select that calling frame unconditionally. Basically, if the MB is on a different frame, we want to return to the calling frame always. So, instead of yesterday's patch, I think this patch works: diff --git a/src/minibuf.c b/src/minibuf.c index 464e3018f7..fc3fd92a88 100644 --- a/src/minibuf.c +++ b/src/minibuf.c @@ -508,7 +508,10 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt, mini_frame = WINDOW_FRAME (XWINDOW (minibuf_window)); if (!EQ (mini_frame, selected_frame)) record_unwind_protect (restore_window_configuration, - Fcons (Qt, + Fcons (/* Arrange for the frame later to be + switched back to the calling + frame. */ + Qnil, Fcurrent_window_configuration (mini_frame))); /* If the minibuffer is on an iconified or invisible frame, > Emacs 27 after any of these prompts inserts the frame selected at the > time I typed C-M-+ which is TRT. There seem to be quite a few things wrong, even on Emacs 27. On starting it with loading your initialisation file from the command line, the initial selected frame is the minibuffer frame, which is surely suboptimal. On M-: followed by C-x 5 o (moving to the normal frame), the unfinished command in the minibuffer frame cannot now be cancelled, and C-x 5 o doesn't move back into the minibuffer. I'm coming round to your way of thinking, that this whole area is a mess, and needs redesigning. > As I mentioned earlier in this thread, such tribulations are the price > we have to pay for providing non-modal dialogues. Yes, maybe, but modal dialogues are a right pain for the user, as can be seen by using virtually any commericial software on non-free systems. > martin -- Alan Mackenzie (Nuremberg, Germany).