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

[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.

IIUC the present code either assumes that the user was in the minibuffer
window before starting the last read_minibuf interaction or that
Fset_frame_selected_window does not select the window when the frame is
already selected.

 > In general, I don't think I understand the logic of this function at
 > all.  Since this is about the "expired minibuffer", then the code
 > seems to assume that when a minibuffer is "expired", and there are
 > previous minibuffers for that mini-window, the mini-window stays the
 > selected-window?  But that is not true when recursive minibuffers are
 > enabled, right?

More precisely, it should not be true when a nested read_minibuf was
invoked from a normal window as with C-x b, something that can happen
only when `enable-recursive-minibuffers' is non-nil.  This includes the
simpler C-h f C-x o C-x b which means that a user does not have to
enable them explicitly.

 > IOW, I wonder whether your suggested change just postpones the problem
 > by moving it to the rarer cases when more than one frame is involved
 > in this dance.  Why is it okay to set the selected-window of another
 > frame here?

I wouldn't know.  That's why I called my proposal "timid".

martin