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: Fri, 27 Nov 2020 22:00:20 +0000 Message-ID: References: <0d14bfc4-8e8e-d3b9-e0e1-ee4bf2e6449d@gmx.at> <20201125210947.GB8228@ACM> <835z5roud4.fsf@gnu.org> 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="14178"; mail-complaints-to="usenet@ciao.gmane.io" Cc: andreyk.mad@gmail.com, emacs-devel@gnu.org, martin rudalics , enometh@meer.net, monnier@iro.umontreal.ca, Eli Zaretskii To: Gregory Heytings Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Nov 27 23:01:33 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 1kilo5-0003bp-Bz for ged-emacs-devel@m.gmane-mx.org; Fri, 27 Nov 2020 23:01:33 +0100 Original-Received: from localhost ([::1]:42416 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kilo4-0004Ry-9F for ged-emacs-devel@m.gmane-mx.org; Fri, 27 Nov 2020 17:01:32 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:41368) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kiln1-0003uY-Mv for emacs-devel@gnu.org; Fri, 27 Nov 2020 17:00:27 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:24054 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.90_1) (envelope-from ) id 1kilmy-0007f6-2E for emacs-devel@gnu.org; Fri, 27 Nov 2020 17:00:27 -0500 Original-Received: (qmail 52868 invoked by uid 3782); 27 Nov 2020 22:00:21 -0000 Original-Received: from acm.muc.de (p4fe15c16.dip0.t-ipconnect.de [79.225.92.22]) by localhost.muc.de (tmda-ofmipd) with ESMTP; Fri, 27 Nov 2020 23:00:20 +0100 Original-Received: (qmail 10343 invoked by uid 1000); 27 Nov 2020 22:00:20 -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=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:259930 Archived-At: Hello, Gregory. On Fri, Nov 27, 2020 at 13:43:27 +0000, Gregory Heytings wrote: > >> Having a customizable variable like 'minibuffer-follows-selected-frame' > >> whose purpose is to get back the old behavior, should also provide that > >> old behavior as faithfully as possible IMHO. > > The NEWS entry clearly says that the old behavior is no longer > > available, so getting back the old behavior is not the purpose of that > > variable. > I hope that does not mean "end of discussion". > I sent two recipes to Martin a few hours ago, which demonstrate that the > behavior with that variable set to nil is broken. Again it is surprising > that such a radical change was accepted without testing these cases, which > are obvious cases to test. > The NEWS entry says "Nevertheless, the effect of what you type in the > minibuffer happens in the frame where the minibuffer was first activated, > even if it moved to another frame." This is not correct. Three recipes: > emacs -Q > C-x 5 2 > C-x C-f > C-x 5 o > C-x o > .emacs RET > The file is opened in the frame in which you are, not in the frame in > which C-x C-f was entered. > Another recipe: > emacs -Q > C-x 5 2 > C-h f setq > C-x 5 o > C-x o > RET > The *Help* buffer is displayed in the frame in which you are, not in the > frame in which C-h f setq was entered. > Yet another recipe, similar to the one with which this discussion started: > emacs -Q > C-x 5 2 > C-x b > C-x 5 o > C-x o > RET > The buffer is displayed in the frame in which you are, not in the frame in > which C-x b was entered. Thanks for drawing this to our attention. This bug slipped in unnoticed in my commit 6e469709c550ba18d9d5a34f6bb89908472f0eb2 from Thu Nov 19 10:31:50 2020 +0000, "In attempted recursive minibuffer use, display error message in correct frame". You are right, more systematic testing would have caught this bug before it got committed. I urge you to try out the following fix, and let us all know whether you find further problems with it. Thanks! diff --git a/src/minibuf.c b/src/minibuf.c index fc3fd92a88..7009579763 100644 --- a/src/minibuf.c +++ b/src/minibuf.c @@ -411,6 +411,7 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt, Lisp_Object val; ptrdiff_t count = SPECPDL_INDEX (); Lisp_Object mini_frame, ambient_dir, minibuffer, input_method; + Lisp_Object calling_frame = selected_frame; Lisp_Object enable_multibyte; EMACS_INT pos = 0; /* String to add to the history. */ @@ -729,6 +730,9 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt, recursive_edit_1 (); + if (!EQ (selected_frame, calling_frame)) + do_switch_frame (calling_frame, 1, 0, Qnil); + /* If cursor is on the minibuffer line, show the user we have exited by putting it in column 0. */ if (XWINDOW (minibuf_window)->cursor.vpos >= 0 -- Alan Mackenzie (Nuremberg, Germany).