bug#63967: 28.2; switch-to-buffer in normal window fails if minibuffer window is active

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sat, 10 Jun 2023 16:51:47 +0200
> Cc: al@petrofsky.org, monnier@iro.umontreal.ca, 63967@debbugs.gnu.org
> From: martin rudalics <rudalics@gmx.at>
> 
>  > That works, but does it make sens to do the other stuff in that if
>  > clause in that case?  We do:
>  >
>  >        if (!NILP (w->prev_buffers))
>  > 	{
>  > 	  entry = Fcar (w->prev_buffers);
>  > 	  w->prev_buffers = Fcdr (w->prev_buffers);
>  > 	  set_window_buffer (window, Fcar (entry), 0, 0);
>  > 	  Fset_window_start (window, Fcar (Fcdr (entry)), Qnil);
>  > 	  Fset_window_point (window, Fcar (Fcdr (Fcdr (entry))));
>  > 	  /* set-window-configuration may/will have unselected the
>  > 	     mini-window as the selected window.  Restore it. */
>  > 	  if (!EQ (orig_selected_window, FRAME_SELECTED_WINDOW (f)))
>  > 	    Fset_frame_selected_window (exp_MB_frame, window, Qnil);
>  > 	}
>  >
>  > Does it make sense to manipulate the buffer, window-start, and
>  > window-point of WINDOW if we are not going to make it the selected
>  > window?
> 
> If w->prev_buffers gets us the right minibuffer to display here (any
> former dw->prev_buffers = sw->prev_buffers should guarantee that), then
> for that buffer we have to establish the corresponding start and point
> positions.  This makes sense regardless of whether the minibuffer window
> will be selected or not.

But read_minibuf_unwind already does all that when it restores the
window configuration, doesn't it?  Or is there something about the
mini-window that restoring window configuration doesn't handle
correctly?