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

[Eli Zaretskii <eliz@gnu.org>]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Al Petrofsky <al@petrofsky.org>,  martin rudalics <rudalics@gmx.at>,
>   63967@debbugs.gnu.org
> Date: Fri, 09 Jun 2023 11:08:43 -0400
> 
> > Seems like read-buffer-to-switch (called by "C-x b") changes the
> > selected-window: when it returns, the rest of the function runs with
> > the minibuffer window being the selected-window, which is wrong in
> > this case.
> 
> Are you 100% sure that's what happens?

Yes, I'm sure.  First, the window-minibuffer-p call in the interactive
form:

  (interactive
   (let ((force-same-window
          (unless switch-to-buffer-obey-display-actions
            (cond
             ((window-minibuffer-p) nil) <<<<<<<<<<<<<<<<<<<<<<<<<<<<
             ((not (eq (window-dedicated-p) t)) 'force-same-window)
             ((pcase switch-to-buffer-in-dedicated-window
                ('nil (user-error
                       "Cannot switch buffers in a dedicated window"))
                ('prompt
                 (if (y-or-n-p
                      (format "Window is dedicated to %s; undedicate it?"
                              (window-buffer)))
                     (progn
                       (set-window-dedicated-p nil nil)
                       'force-same-window)
                   (user-error
                    "Cannot switch buffers in a dedicated window")))
                ('pop nil)
                (_ (set-window-dedicated-p nil nil) 'force-same-window)))))))
     (list (read-buffer-to-switch "Switch to buffer: ") nil force-same-window)))

returns nil, as expected (since this runs in the window to which we
changed with "C-x p", before Emacs prompts for the buffer to switch
to).  But then the call to window-minibuffer-p in the body of the
function:

  (let ((buffer (window-normalize-buffer-to-switch-to buffer-or-name))
        (set-window-start-and-point (not switch-to-buffer-obey-display-actions)))
    (cond
     ;; Don't call set-window-buffer if it's not needed since it
     ;; might signal an error (e.g. if the window is dedicated).
     ((and (eq buffer (window-buffer))
           ;; pop-to-buffer-same-window might decide to display
           ;; the same buffer in another window
           (not switch-to-buffer-obey-display-actions)))
     ((and (window-minibuffer-p)  <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
           (not switch-to-buffer-obey-display-actions))
      (if force-same-window
          (user-error "Cannot switch buffers in minibuffer window")
        (pop-to-buffer buffer norecord)))

returns non-nil, although we were supposed to be out of the minibuffer
by that time.  I've verified that selected-window returns the original
non-minibuffer window in the first place and the minibuffer window in
the second.

I then ran the recipe under GDB, with a watchpoint on selected_window,
and clearly saw that it stays at its mini-window value by the time we
exit read-buffer-to-switch.

> And if it happens with `read-buffer-to-switch` I can't see any reason
> why it wouldn't happen for most/all other uses of the minibuffer.

It probably does, yes.