emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Stop frames stealing eachothers' minibuffers!


From: Alan Mackenzie
Subject: Re: Stop frames stealing eachothers' minibuffers!
Date: Fri, 27 Nov 2020 22:00:20 +0000

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).



reply via email to

[Prev in Thread] Current Thread [Next in Thread]