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

[Alan Mackenzie <acm@muc.de>]

Hello, Drew.

On Sun, Jun 11, 2023 at 14:35:59 +0000, Drew Adams wrote:
> > > > 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, ....

I'm answering your post.  ;-)

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

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

That window is the miniwindow.  Unless we're talking about a recursive
minibuffer use from the miniwindow, we need to select some other window
after using the minibuffer, otherwise the user would need explicitly to
select a window herself.

> Let's-hard-code-which-window-should-be-selected
> is maybe related to the fact that I can no longer
> use Emacs > 26.3.

> What's wrong with attempts to predetermine which
> window should be selected after a minibuffer
> read?

> It's the presumption that a minibuffer's only
> purpose is to return something read, and that the
> state of Emacs, including which windows exist and
> which should be selected, should be the same as
> before the minibuffer was entered - or should be
> any other predefined state.  The selected window
> here shouldn't be determined formulaically.

It needs to be determined somehow.  That "somehow" would probably count
as a formula in some sense.

> This completely prevents or interferes with code
> that _does things_ while the minibuffer is active
> with the intent of changing such state, e.g., the
> intent to change the selected window, and not
> just till minibuffer reading is finished.

If you do C-x C-f, do wierd and wonderful things whilst the minibuffer is
active, then select a file to vist, you seem to be saying you want that
file to be visited on what became the selected window just before
terminating the minibuffer.  Am I right, here?

If so, that would involve some new options to enable this behaviour, and
some new complications in the code to support it.

> There.  I've said it again.  And clearly Emacs
> won't be going back to its former freedom in
> this regard - 1000 ships have sailed.  But IMO
> this is a great loss.  And it comes, I think,
> from assuming that others use existing behavior
> only the way you do.

As one of the people who implemented a recent change in the minibuffer,
I'm not sure this is entirely fair.  Efforts were made to avoid
restricting the ways the minibuffer could be used.  The code is anything
but simple and straightforward.

It might be useful to compare with the way most non-Emacs systems cope
with these problems: they use what are known as "modal" dialogue boxes.
Having initiated one of these, there is no way of doing anything else in
the system, including looking at a buried frame, until the "modal"
dialogue has been terminated or aborted.  I think Emacs's way is better,
even if not perfect.

> My use of Emacs relies on doing lots of things
> while a minibuffer is active - including things
> that you might do only when it's inactive.  And
> the changes I make while its active shouldn't
> be overridden when a minibuffer is exited.

That is complicated to specify and implement.

> And yes, this can include changing the selected
> window and focused frame.  I want to be able to
> do that myself, interactively or by definition
> from the function that invoked the minibuffer.

The command using the minibuffer often acts on a buffer, window, and/or
frame.  In such cases, chaos could result from having a different current
buffer, selected window, or selected frame from what the command thinks
it has.  It is possible that such chaos was what prompted the restoration
of the window configuration, etc., after using the minibuffer.

I've had a look into git blame minibuf.c, and it would appear that the
use of set-window-configuration is very old indeed - there is a comment
by Richard Stallman from 1996-04-07 saying:

    /* We have to do this after saving the window configuration
       since that is what restores the current buffer.  */

..

> To my mind you've hobbled Emacs - specifically
> its minibuffer, just as much as if you'd poked
> out its eyes or cut off its legs.

I assure you there was no malice intended.  ;-)

> If you'd really wanted to provide only some
> _default_ behavior wrt choosing the window to
> select here, then you'd have done that.  You'd
> have provided some way (e.g., a variable) for
> code to _prevent_ force-selecting the window
> you've predetermined to be the "chosen one".

As remarked above, some window has to be selected (? "force-selected"),
otherwise point would remain in the miniwindow.  That window needs to be
determined somehow.

> The Emacs minibuffer was "simply" better
> before you simply "fixed" it.

There were things wrong with it, which have been fixed.  You have
mentioned version 26.3 as the latest one you can use.  Are you saying
that the minibuffer was fine for you at that release, or was it better
even earlier?

-- 
Alan Mackenzie (Nuremberg, Germany).