Re: Stop frames stealing eachothers' minibuffers!

[Alan Mackenzie]

Hello, Eli.

On Sat, Oct 31, 2020 at 22:00:09 +0200, Eli Zaretskii wrote:
> > Date: Sat, 31 Oct 2020 19:44:19 +0000
> > Cc: emacs-devel@gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > I can't remember very clearly, but I think I made this change early on in
> > the project because the Fthrow (Qexit, str); left some mini-windows in a
> > messy state; or something like that.  That doesn't happen any more.

> > So, maybe I should just remove this hunk from the proposed patch.  It
> > doesn't seem that important any more.

> Fine with me.

OK, that's done.

> > 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.
There appears to be no way to get its minibuffer back again.

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.

-- 
Alan Mackenzie (Nuremberg, Germany).