bug#48674: Frames and minibuffer bug

[martin rudalics]

> 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