bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it

[Drew Adams]

> AFAIU the issues fixed were all special cases were a message hided some
> y-or-n-p prompt so that the user may have missed the prompt, or may
> have wondered what to do to get it back.

I see.  So the problem is that `y-or-n-p' uses the
echo area for prompting, and `message' writes to
the echo area.  Yes, that's indeed a problem.
Sorry for not understanding that that's what we're
trying to solve.

[I still don't understand why it's said that your
minibuffer input gets permanently hidden, in that
scenario.  I suppose that if the result of your
`y-or-n-p' answer causes Emacs to quit or to kill
stuff then that could happen, but I wouldn't think
it would happen generally.  Your input is in the
minibuffer; the prompt from `y-or-n-p' is in the
echo area.]

> > What I've said is that I object to an automatic
> > attempt to determine, when the minibuffer is
> > active, whether to realize the effect of `message'
> > or the effect of `minibuffer-message'.
> 
> AFAICT only the behavior for these special situations have been made a
> bit more user friendly, and all other calls of message or mb-message
> are uneffected (is that correct, Juri?) so that third party stuff should
> not be affected.

I see.  I hope that's right.  I got the impression
that a change was being made to detect whether the
minibuffer is active, and, when so, make `message'
calls behave instead like `minibuffer-message'.
That would not be good.

Can someone please confirm that that's not the case?

> `y-or-n-p' has been reimplemented to use
> read-from-minibuffer instead of read-key, however.

I see.  That sounds like a big change, just to fix
the "special situations" you described.  And it
sounds bad, to me.

`y-or-n-p' is not the only situation where we prompt
in the echo area and read a key.

If we're really going to make big changes, wouldn't
it be better to do something different, to address
all such read-key situations - aren't they all
potentially problematic (special situations)?

Why would we want to switch such situations to read
from the minibuffer (activating it, prompting in it,
etc.)?

Reading a key (which is what this is about, IIUC)
isn't specific to any particular _input location_
(e.g. the minibuffer).

It can be relevant to the place where that action
gets initiated (to maybe pick up relevant keymaps).
But it shouldn't be associated with any particular
expected-input location.

To read a key, the prompt basically _tells_ the
the user to hit a key.  It's not looking to read
any input into a buffer - minibuffer or otherwise.

Why not instead just put the prompt in a temporary
(unselected) popup window or undecorated frame?

IMO there should be no need to give `y-or-n-p',
or any other function that reads a key,
interaction with the  minibuffer.  Just because
we need to prompt, and be sure the user sees the
prompt, that doesn't imply that we should use the
minibuffer.

No need and no reason to do that, is there?
Using the minibuffer to read a key introduces
unnecessary complexity and confusion for users.
We present an input buffer for no reason - no
text gets edited and input there.

The minibuffer is a heavy-weight UI, allowing
lots of possible interactions.  I have a hard
time believing that, just to solve the problem
you described, we would end up going down this
route.

(A key can be read anytime - whether or not
the minibuffer's active.  And it certainly
shouldn't require a recursive minibuffer if
key-reading is initiated while the minibuffer
is active for something else.)

Using the minibuffer for _output_, as does
`minibuffer-message', is generally worse, not
better, than using the echo area for output
(`message') and reserving the minibuffer for
input only.