Re: Stop frames stealing eachothers' minibuffers!

[Alan Mackenzie <acm@muc.de>]

Hello, Martin.

On Mon, Nov 23, 2020 at 10:10:36 +0100, martin rudalics wrote:
>  > 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?

> Here it's xfce 4.12 with xfwm4 so probably something very similar to
> yours.  But since the behavior does not depend on your patches as I just
> verified, something else must be causing it.

OK.

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

> I suppose we only have two such users - Stefan and Drew - and they seem
> to like it (or work around it).

Maybe one or other of them might answer this point.

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

> Then what did you mean with the last line of

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

It was a complaint about not being able to cancel the unfinished command
in the minibuffer.  One should be able to cancel such a command.
Eventually it occurred to me that I could click on the minibuffer frame
with the mouse, which I did, and then C-g worked.

If you have nothing against it, I'll commit the fix from yesterday (the
one supplying a Qnil to the future set-window-configuration) to master.

> martin

-- 
Alan Mackenzie (Nuremberg, Germany).