RE: Confused by y-or-n-p

[Drew Adams]

>   > > Still I'd suggest to allow users to
>   > > separately choose for both, 'y-or-n-p' _and_
>   > > 'yes-or-no-p' dialogues, whether they want Emacs
>   > > to handle them in a modal or non-modal way.
> 
> That would have these drawbacks
> * It would mean extra complexity to debug, maintain, and document
> * It would not directly provide the old behavior, only a basis for it.
>   People who want that would have to implement that.
> 
> Does anyone really WANT this generality, or is it generality for
> generality's sake?
> 
>   > Indeed.  Here is a possible way to make the minibuffer modal:
>   > (defun minibuffer-lock ()
>   >   (when (active-minibuffer-window)
>   >     (select-window (active-minibuffer-window))))
> 
> I am not sure what behavior that would give.
> But I think it is NOT the behavior that y-or-n-p used to
> have, which was to reject unexpected answers.
> 
> What was the reason for implementing this change in the
> single-character-answer commands?  Who actually wanted
> the change in behavior?  And for what use cases?
> 
> If people really like the new behavior, I won't argue against it.
> But maybe we should turn it off by default, like recursive minibuffers.

FWIW:

I opposed this new behavior.  I think I was the only
one who did, but that impression might be wrong.

I opposed reading from the minibuffer for `y-or-n-p',
in part because it can break existing UI dialogs
(which may also involve the minibuffer at outer
levels), but also in part because of the reasons
you give (which are related).

I opposed wholesale replacement of uses of `read-key'
with use of the minibuffer.  (Not that 100% wholesale
replacement has occurred, but I sense that a general
motivation in that direction has taken hold of the
movers and shakers.)

IIRC, this change was done in bug threads.  I don't
think there was discussion in emacs-devel.  (Apology
if I remember this wrong).  In any case, as Eli is
wont to say, "That ship sailed long ago."  Alas.
___

Emacs 27 introduced several changes involving use of
the minibuffer, which unfortunately have broken my
personal use of Emacs (as well as some of my libraries,
which are used by some other users).

I use a standalone minibuffer frame, and I have lots
of dialogs that let you interact in virtually any way
with other buffers, etc. while a minibuffer interaction
is in progress.  E.g., for some commands that use the
minibuffer, you can hit keys that initiate sub-dialogs,
which can involve all kinds of things (and which
typically don't involve recursive minibuffers).

And the minibuffer, in my use, is very much an editing
buffer, i.e., most editing keys/commands act normally
there.  I want it to continue to be general this way.

I think some simplifying lockdowns of certain behavior
have been clamped onto the minibuffer lately, based on
(1) some assumptions that apply to presumed common
interactions and expectations, and (2) attempts to "fix"
some (relatively corner?) cases.  That's an impression
I have, and it's largely uninformed/ignorant, as I can't
really make use of Emacs since release 27.

So I don't use Emacs 27, and ditto for Emacs 28.  I do
sometimes submit bug reports for 27, as a result of
looking into some questions from other users.  But
those are mostly doc-bug reports.

Maybe, if I'm on the planet long enough and have
enough patience and interest, I'll eventually get to
the bottom of why I can't use Emacs 27+, what breaks
what, and find workarounds.  I'm not there now, and
I don't foresee ever going/getting there, alas.
I use Emacs 26.3, and perhaps always will.

Just one (hardly typical) user.