bug#48674: Frames and minibuffer bug

[martin rudalics <rudalics@gmx.at>]

 > What is happening is that the with-selected-frame invocation is
 > selecting (temporarily) a different frame from the minibuffer's frame.
 > This has the (intended) side effect of making the MB no longer selected
 > in that frame.  When the MB's frame becomes selected again, nothing
 > makes the mini-window the selected window.  This needs fixing.

Does this mean that the

   Fselect_window (f->selected_window, norecord);

in do_switch_frame fails?  If so, why?  Do we anywhere violate the

   (eq (selected-window) (frame-selected-window (selected-frame)))

invariant?  That might be fatal.  Both, `with-selected-frame' and
`with-selected-window', should leave no traces behind.

 > Martin, that Qt in the Fselect_window call (the NORECORD argument) -
 > would it be perhaps be better as Qnil?
 >
 >
 > diff --git a/src/minibuf.c b/src/minibuf.c
 > index cffb7fe787..3468643a7e 100644
 > --- a/src/minibuf.c
 > +++ b/src/minibuf.c
 > @@ -893,6 +893,11 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt,
 >
 >     run_hook (Qminibuffer_setup_hook);
 >
 > +  /* If the above hook has made the mini-window no longer the selected
 > +     window, restore it.  */
 > +  if (!EQ (selected_window, minibuf_window))
 > +    Fselect_window (minibuf_window , Qt);
 > +

Are we sure that we want to disallow a function on
`minibuffer-setup-hook' to change the selected window?  With Emacs 27


(defun foo ()
   (select-window (frame-first-window)))

(add-hook 'minibuffer-setup-hook 'foo)


works without any problems here.

The NORECORD argument is important only if you need it - so far, the
previous buffers of the minibuffer window were largely ignored.

martin