Re: Stop frames stealing eachothers' minibuffers!

[Alan Mackenzie]

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*

> #<frame *Minibuf-2* 0x313ab10>

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