Re: Stop frames stealing eachothers' minibuffers!

[Alan Mackenzie]

Hello, Martin.

On Sun, Nov 22, 2020 at 18:57:30 +0100, martin rudalics wrote:
>  > 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.

On my machine (XFCE on X-Windows on GNU) I see TRT when I do this.  Could
it be something to do with your window manager?

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

Do people like it, or is it just not a big enough annoyance for anybody
to complain?  If I were a minibuffer-only frame user, I suspect it would
drive me up the wall.

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

Yes, I can understand that.  But you will be aware of all the nasty
little things which will leap out in front of you and force you to solve
along the way.

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

I'm more of the view that a minibuffer-only frame should never be
selected other than by activating a minibuffer.

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

Yes.  I hate these dialogues, which force you to cancel them and start
again, should you need some information from another part of the program
to be able to fill them in.

> martin

-- 
Alan Mackenzie (Nuremberg, Germany).