Re: Stop frames stealing eachothers' minibuffers!

[Eli Zaretskii]

> Date: Sat, 31 Oct 2020 20:39:14 +0000
> Cc: emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > > How about emptying mini-windows which don't have live minibuffers on
> > > them?  This could be tested by Fminibufferp (b, Qt).  In practice, when
> > > minibuffer-follows-selected-frame this would empty all mini-windows but
> > > the current one, and when !m-f-s-f it would leave intact the mini-windows
> > > we want to be left intact.
> 
> > let me turn the table and ask why this hunk is needed?  What doesn't
> > work right if this code is left in place?
> 
> Without that hunk (i.e. with the emptying-out code):
> (i) emacs -Q
> (ii) M-: (setq minibuffer-follows-selected-frame nil)
> (iii) C-x 5 2 ; giving two frames.
> (iv) C-x b ; leaving a minibuffer open.
> (v) C-x 5 o ; move to other frame.
> 
> (vi) C-r in ; start an isearch.
> (vii) C-x 8 RET ; intending on inserting a non-keyboard character.
> 
> At this point, the mini-window in Frame 1 is emptied.  This is bad.

But the same happens with the current master.  So this is no worse
than what we have today.

> By contrast, the same sequence of operations without (ii) (with an extra
> step:
> 
> (v).5 C-x o ; move to the ordinary window.
> 
> ), the first minibuffer is "protected" on Frame 2 underneath the C-x 8
> RET minibuffer.  So, when the isearch is finished, the "Switch to
> buffer" minibuffer appears again, and is active.

Is this with or without removing the code which empties all the other
minibuffers?