Re: Stop frames stealing eachothers' minibuffers!

["Miha Rihtaršič" <jakanakaevangeli@chiru.no>]

Alan Mackenzie <acm@muc.de> writes:

> Hello, Jakanakaevangeli,
>
> On Sat, Mar 13, 2021 at 21:53:05 +0100, jakanakaevangeli wrote:
>
> [ .... ]
>
>> 3)
>> In emacs daemon, evaluate
>> (run-at-time 5 nil #'make-frame '((window-system . x)))
>> and then open a minibuffer and close the last frame. When a new frame
>> appears, the same problem as in 1) occurs.
>
> I think one of the two previous changes fixed this.

Sorry, this still doesn't seem to be fixed. Just in case I wasn't clear
enough, I'll try to reiterate.

When a frame is closed, it's active minibuffer should now be moved to
another frame. What I wanted to test then was, what happens if we have
only a single frame with a minibuffer and we decide to close it, which
is possible with emacs daemon. Immediately, there will be no frames left
for the minibuffer to take refuge in and this seems to cause some
problems.

And two new regressions. These require minibuffer-follows-selected-frame
to be set to t.

1)
C-x C-f on frame A
select frame B
select frame A
Minibuffer is moved to B, but not back to A.

2)
Have two frames open
open a minibuffer on a frame
close this frame
The other frame does have the miniwindow selected, but the
minibuffer isn't shown in it.

Best.