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

[Eli Zaretskii]

> Date: Sun, 11 Jun 2023 13:40:52 +0000
> Cc: monnier@iro.umontreal.ca, al@petrofsky.org, rudalics@gmx.at,
>   63967@debbugs.gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > > Fset_window_configuration seems to be the troublesome function in this
> > > scenario.  As well as setting the window configuration, it also selects
> > > a window.
> 
> > Where is that problem and its circumstances described?  Is there some
> > bug number or a discussion on emacs-devel that you could point to?
> 
> I remember such a discussion vaguely, but after much searching, haven't
> been able to find it again.  Sorry.

Too bad.  If someone can find it, please speak up.  It is important to
know what those situations are to make sure the solution we install
for this bug doesn't break those situations.

> > > Perhaps we should modify the minibuffer code to note which window should
> > > be current after the completion or abortion of the minibuffer read
> > > action.
> 
> > Isn't that simply "the window which was selected before entering the
> > minibuffer"?
> 
> Most of the time, yes.  If that window no longer exists on termination of
> the minibuffer, or we've moved to a different frame, things aren't so
> simple.

So you are saying that minibuffer_unwind exists only for the case when
that window no longer exists?  But if so, where's that condition being
tested, in a way that minibuffer_unwind is a no-op if that window
still exists?

> In read_minibuf (the meat of the minibuffer processing), there is a
> variable calling_window which records that window.  It gets pushed onto
> the binding stack (along with a lot of other variables) around the
> recursive edit, and then possibly restored in the unwind_protect function
> read_minibuf_unwind.  However, restore_window_configuration overrides it,
> because of the order these things are pushed onto the binding stack by
> read_minibuf.

I don't understand the need for recording that window separately.  The
window configuration restored by restore_window_configuration is
supposed to record it.

> Do you want me to fix this bug?  It seems there are quite a lot of people
> who've made observations about it in the last couple of days.

I want to fix the bug whose recipe is in
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=63967#5 and other
similar ones, yes.  Basically, if Emacs reads from a recursive
minibuffer when the selected window before that was not a mini-window,
we now signal a user-error, which is a regression since Emacs 28, and
I'd like that to be solved.  But please begin by looking at the
solution proposed by Martin in
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=63967#38 and tell if it
looks good to you, and if not, why not.

I'd also appreciate more commentary explaining the rationale for
minibuffer_unwind and the situations where it is needed.  But that is
less urgent.

Thanks.