Re: Stop frames stealing eachothers' minibuffers!

[Alan Mackenzie]

Hello, Martin.

On Fri, Nov 20, 2020 at 19:47:28 +0100, martin rudalics wrote:
>  > I've just committed a fix to the Emacs master branch.

> Sorry, but this cannot be possibly right.  With emacs -Q load a file
> with

> (setq default-frame-alist '((minibuffer . nil)))

> (defun foo ()
>    (interactive)
>    (read-from-minibuffer "...?")
>    (insert (format "%s" (selected-frame))))

> insert (foo) into *scratch* and type C-x C-e.  After answering the
> prompt this gets me #<frame *Minibuf-1* 0x36132d8>.  Do the same with
> Emacs 27 and it will get you the *scratch* frame.

Yes, I see this (except for the Emacs 27 bit which I haven't tried,
yet).

However, if I type (frame-list) into *scratch* and do C-x C-e I get only
one frame in the list, and it has the same address in the #<frame ...>
output as the " *Minibuf-1* 0xxxx" output.

In other words, I think your (insert (format "%s" (selected-frame))) is
getting the correct frame, but the current buffer within it is still the
minibuffer.

Might you possibly have simplified the recipe so much that the problem
is no longer shown by the recipe?  Removing the setting of
default-frame-alist from the file doesn't seem to make any difference.

> As soon as 'read-from-minibuffer' has finished its job, it is as if it
> never happened and the old configuration must have been restored.  We
> might be able to stay on old_frame when minibuf_level > 0 but in the
> scenario above the frame that was selected when 'read-from-minibuffer'
> was called must be re-selected.

Why were we selecting a frame as an "incidental" side effect of restoring
a window configuration?  Surely the frame to be selected should be
selected deliberately and explicitly.

I'm thinking that what needs restoring is the frame's current buffer, and
I'm wondering why that wasn't done by the (set-window-configuration foo
t) which happened near the end of read_minibuf.

> martin

-- 
Alan Mackenzie (Nuremberg, Germany).