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

[Eli Zaretskii]

> From: Drew Adams <drew.adams@oracle.com>
> CC: "al@petrofsky.org" <al@petrofsky.org>,
>         "rudalics@gmx.at"
>       <rudalics@gmx.at>,
>         "monnier@iro.umontreal.ca" <monnier@iro.umontreal.ca>,
>         "63967@debbugs.gnu.org" <63967@debbugs.gnu.org>
> Date: Sun, 11 Jun 2023 14:35:59 +0000
> 
> > > > 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.
> 
> You can and will ignore this, but IMO _all_ of
> the above is misguided and short-sighted.  "Isn't
> that simply...?" is just plain wrong - both the
> question and any single answer.

I will indeed ignore most of what you say -- because you seem to
completely misunderstand what this discussion is about.  See below.

> It isn't "simply" _anything_ you can preconceive.
> It's _whichever window ended up_ selected after
> using the minibuffer.  Nothing more, nothing less.

Using the minibuffer doesn't by itself cause any window to be
selected.  Using the minibuffer just supplies to whatever command that
prompted the user with the response to the prompt.  Then the
minibuffer is exited, and only then the command continues its
execution, and could very well choose another window to be the
selected one.

This discussion is about what happens _immediately_ after
read-from-minibuffer exits, which just provides the response to the
prompt.  It has nothing to do with what you are talking about, and
doesn't affect the window that will be the selected one after the
command exits.

read-from-minibuffer invokes recursive-editing cycle.  When that cycle
ends, it should leave the window/frame configuration intact, or as
intact as possible.  Why? because most commands that invoke
read-from-minibuffer in its interactive form do not expect the window
configuration to change after the interactive form finishes its job.

And if you still don't agree, then let's agree to disagree.