Re: Stop frames stealing eachothers' minibuffers!

[jakanakaevangeli <jakanakaevangeli@chiru.no>]

Alan Mackenzie <acm@muc.de> writes:

> Hello, Stefan and jakanakaevangeli.
>
> On Thu, Feb 11, 2021 at 09:29:44 -0500, Stefan Monnier wrote:
>> > This is more involved.  What do we want to happen when a frame with open
>> > minibuffers is deleted?  I would say that these minibuffers should,
>> > except in the (eq minibuffer-follows-selected-frame t) case, be aborted,
>> > together with any others in other frames whose nesting level makes this
>> > necessary.
>
>> I vote for moving those minibuffers elsewhere (anywhere else is fine by
>> me, really).  I assume it's no more complicated code-wise, and it should
>> suffer less from the risk of losing information.
>
> Just a quick recapitulation of the problem: when
> minibuffer-follows-selected-frame is nil, and
> enable-recursive-minibuffers t, it is possible to have several open
> minibuffers on several frames.  If one of these frames is deleted, its
> minibuffers continue to exist, but are wholly inaccessible - the only
> thing to do with them is to abort them, e.g. with C-].  This is
> suboptimal.
>
> The patch below tries to solve this by, when such a frame gets deleted,
> "zipping" its minibuffers into those of another frame.  The idea behind
> the patch is to use the mini-window's w->prev_buffers component to hold
> the list of its minibuffers.  This mini-window component was unused by
> the rest of Emacs, apart from accidentally by
> window--before-delete-windows, which I have now amended.
>
> I would be grateful indeed if either of you (or indeed, anybody else),
> would apply the patch and try it out, or indeed comment on it.  Thanks!

Great! I tested it and there still seem to be a few ways one can end up
with invisible active minibuffers, all of them with
minibuffer-follows-selected-frame set to nil:

1)
C-x C-f on frame A
C-x C-f on frame B
select frame A and press C-] (abort-recursive-edit)

This does quit only the inner minibuffer as expected but it hides the
outer one for some reason. This also seems to be a regression of this
patch, the minibuffer isn't hidden without this patch applied.

2) (Might depend on your window manager, I'm not sure)
Open frames A, B, and C
C-x C-f on frame A
C-x b on frame B
Close frame A

Both of the minibuffers are now moved to frame C and the outer C-x C-f
is shown in the mini-window, which is kind of annoying. If we now select
frame C and press C-], the same problem as in 1) occurs.

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.

Hope this helps.