Re: Stop frames stealing eachothers' minibuffers!

[martin rudalics]

> 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,

This one immediately chokes when I run

emacs -Q --eval "(setq default-frame-alist '((minibuffer . nil)))"

and type C-x 5 2.  Here the cursor disappears entirely although when I
do some typing now the text shows up in the minibuffer window.  TRT as
with Emacs 27 is to select and focus the new frame.

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

Here the minibuffer-only frame is selected but partially hidden by the
normal frame so that I don't see no cursor initially.  I don't know why
people like it that way.  A minibuffer child frame is explicitly not
selected.

Note that the way Emacs creates the two frames layout is atrocious - we
first make a normal frame to do our usual initialization stuff and then
we create the minibuffer-only and the minibuffer-less frames and delete
the initial one (compare 'frame-notice-user-settings').  It's for years
that I want to rewrite that ...

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

'other-frame' never selects a minibuffer-only frame.  It probably should.

And the behavior of C-g in a separate minibuffer frame IME usually
varies with the time of the day.

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

Modal dialogues are supported by the windowing subsystem, regardless of
whether it's free or not.

martin