RE: Confused by y-or-n-p

[Drew Adams]

> >> I think that y-or-n-p-use-read-key should default to t.
> >> There is no hurry about making this change.
> >
> > Personally, I won't mind reversing the default, FWIW.
> 
> I think reversing the default would be less than optimal for two
> reasons: 1) The new behaviour is in Emacs 27, and flopping back to the
> Emacs 26 behaviour just sounds confusing

See - that's the problem with saying that Emacs
can just go ahead and change stuff, because we
can always backtrack later.

The cement overshoes start to harden immediately.
People then make arguments like that one: it's
already been released, so we shouldn't, or we
can't, change it back.  "Less than optimal."
"That ship has already sailed."  "The horse is
already out of the barn."

> I think Emacs (by default) should avoid being
> "modal".  Not being able to change buffers on
> a y-or-n-p question makes it differ from how
> Emacs behaves in almost all other
> circumstances, which makes it inconsistent.

Yes, "almost all other".  Emacs has _always_
been inconsistent in that way - by design.

Emacs has always been modal in contexts where
it's important to require an immediate answer,
e.g. a confirmation.  That's always been a
general exception.
___

But note the difference with `yes-or-no-p'.
On the one hand, it requires more typing,
inviting more attention and limiting
accidental mischoice.  On the other hand, it
does _not_ prevent delaying a response and
performing other actions.

Consider changing to another buffer, opening
another file,getting some help, etc., while
confirmation awaits:

  (let ((enable-recursive-minibuffers  t))
    (yes-or-no-p "Are you sure? "))
___

Beyond that, what you say there, which I agree
with as a general rule, flies in the face of
recent _big_ changes wrt preventing keeping
the minibuffer active, changing focus somewhere
else, doing other stuff, and coming back to the
minibuffer (or never coming back: `C-g').

That kind of interaction is super-important to
my own use of Emacs.  Now it's been impeded.

Imposing a predetermined rule about focusing,
making hard-coded assumptions about minibuffer
interaction, prevents users from changing focus
the way they want, and so doing what they want.

It was wrong to assume that minibuffer
interaction always follows, and should follow,
some single, rigid pattern.  On l'a niqué, le
pauvre minibuffer.

As a general rule, the minibuffer should not,
in any way, be forced to be modal - wrt its
focus or anything else.  Not by default - modal
behavior can be programmed for it, but that
shouldn't be part of its general design.