bug#56305: 29.0.50; 'yes-or-no-p' deselects minibuffer frame

[Drew Adams]

> I think that might be over-stating things.
> Most of the time, users are just going to be
> typing "yes" or "no" here.

[Big caveat: I'm not following this thread.]

FTR/FWIW -

I expect that there's lots in here that I don't
agree with.

But there's also lots that's happened over the
last few releases that I don't agree with, wrt
Emacs grabbing or changing the focus (frame)
from what my code or user actions have decided.

I tend to think that such changes have been
essentially gratuitous (unconsciously so), even
if someone thought they were called for to fix
this or that reported problem.  Fixing one user
problem can easily mess up other things.  And
fiddling with frame focus is a particularly
sensitive kind of fiddling - including because
different platforms can do things differently.
____


I'll just say this wrt `yes-or-no-p' - at
least wrt how it _used_ to behave.

`yes-or-no-p' is just a function that reads
minibuffer input.  As far as that reading's
concerned, it's "modal" in this sense _only_:
you can't end the reading of minibuffer input
without hitting `C-g' or `C-]' or similar, or
else entering `yes' or `no'.  That's it -
nothing more modal than that.

There's _nothing_ that prevents a user (and
code invoked by the user hitting a key etc.)
from changing the focus to another window or
frame, and carrying out any number of actions
there.  Even multiple frames, successively.
(Not to mention recursive minibuffers.)

There should be _ZERO_ expectation by Emacs
that focus should remain with the minibuffer
during `yes-or-no-p', any more than during
any other minibuffer interaction.

[`y-or-n-p' _has_ been thoroughly modal in
the past.  It expressly did _not_ use the
minibuffer.  But now it reads input from
the minibuffer...]

Users and code need to be in control, able
to change focus away from the minibuffer
and back to it.  Emacs really shouldn't get
in the way.

Once Someone(TM) gets the idea that focus
needs to be kept in the minibuffer, we're
headed down the road to knee-capping code
and user - crippling the minibuffer.

And that, no doubt from good intentions.
Good intentions, but maybe some ignorance
of minibuffer possibilities.

The minibuffer is just a buffer - there's
_NO_ prescribed, ineluctable, "consistent",
simple behavior that can be counted on.

And there should be none.  That's a GOOD
THING.

At least that was the case before any
sanitizing mission started blasting away.

More and more, it seems, if you write code
that takes advantage of how Emacs behaves
you'll lose, because Someone will climb
under the pavement and make a fundamental
change that "fixes" some perceived problem,
upsetting the apple cart above.
____


Here's the general problem I see wrt someone
trying to "regularize", make "consistent",
"simplify" - or whatever - minibuffer
interaction, including focus:

You'll undoubtedly screw things up by making
simplistic assumptions - either about user
or programmatic behavior or about state at
some point.  Sorry to say that (really), but
that's my conclusion.  I know that people
mean well, but that's what happens, IMO.

Why do I say that?  Because I think that's
what's happened, to break my code.

Starting with Emacs 26 (I think Stefan has
pointed to this) - and definitely with Emacs
27, Emacs has apparently tried to get too
smart about such focus things - making more
assumptions about what users and code will
or should do.

The result: _Emacs changes the focus when
it shouldn't_.

I can't be more precise than that.  I've
given up.  I don't have the time to chase
it.  I use only Emacs 26 and earlier now.

My code, including as a result of user
actions, _explicitly_ uses things such as
`select-frame-set-input-focus'.  IOW, my
code, and users, control the UI, including
focus.

Alas, that careful control has been broken
by Emacs.  No doubt Someone thought he was
doing Emacs and its users a favor "cleaning"
things up and making things more "consistent".
Nothing but good intentions, no doubt.  No
carelessness, I assume.

Instead of giving code & users _more_ control,
to handle frame focus as they see fit, Emacs
has itself apparently tried to take control.
Too smart for its own britches.

The fault is in accidental hubris that can
creep in by not appreciating that Emacs
allows for umpteen _zillion_ different
states and interactions.

It's all too easy to think that every user,
use, use case, and setup (configuration),
and all Emacs code, are more or less similar
to your own use, setup, code etc.

Someone makes a "consistency/cleanup" change,
tries it out with a few (even many) setups,
and considers it a job well done.  Shiny.

Maybe someone else reports, in vague terms,
that Emacs now breaks things.  Without a
clear, simple recipe to show that, Emacs
just goes ahead with the new "improvement".
And on it goes.

What was stable for many years becomes
something different, less flexible, etc.

The minibuffer, in particular, is just a
buffer.  And it can be in its own frame.
Users and code can switch focus to & from
that frame, including during minibuffer
interaction.

And other frames (e.g. a dedicated
*Completions* frame) can have their focus
redirected to the minibuffer frame.  And
such redirection doesn't prevent code or
users from switching the focus to such a
frame, and back again.

In short, it should be possible to do
pretty much _anything_ while the
minibuffer is active.

And that - especially - includes changing
the input focus among different frames.