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

[Drew Adams <drew.adams@oracle.com>]

> > `message', unlike `minibuffer-message', not only
> > interrupts input (switching to the echo area).
> > By doing so it also takes over that complete space.
> >
> > Yes, that hides your input temporarily - but that's
> > the point.
> 
> No, `message' hides your input not temporarily,
> but permanently.  That's the problem.

How so, _permanently_?  That's not what I see,
ever.

Permanent hiding means your input is lost,
destroyed/irretrievable - impossible to show
again.

I've never seen `message' - or any other use of
the echo area, destroy minibuffer input.  Input
is in the minibuffer, not in the echo area.
Completely separate - by design. 

Maybe there's some particular scenario where
something that _looks_ like "permanent hiding"
seems to happen.  If so, then it's that scenario
that needs fixing.

I see zillions of uses of `message' when the
minibuffer is active, and input is never hidden
permanently.  And I don't see how it could be.

I notice the Subject line of this bug says that
`message' overwrites a prompt.  If that happens
then (1) that prompt must be in the echo area,
not the minibuffer, and (2) presumably we're not
talking about input in the minibuffer anyway.

A minibuffer prompt is not in the echo area,
so it cannot be overwritten by `message'.

Sounds like you're doing something unusual,
which doesn't really involve prompting in the
minibuffer for minibuffer input.

What's more, `y-or-n-p' doesn't use (hasn't used)
the minibuffer.  It prompts in the echo area,
and it uses `read-key', which doesn't use the
minibuffer.  That's a main feature of `y-or-n-p'
and of `read-key' - no use of the minibuffer.

So you must really be doing something unusual,
if not unkosher.  Sounds like you've painted
yourself into a corner and are now painting up
the walls.  Maybe you've dreamed up some kind
of "solution" in search of a problem, or you've
created a problem out of thin air, which then
calls for a crazy "solution".

> And `minibuffer-message' fixes it both ways:
> when the minibuffer is active, it displays the
> message at the end of the minibuffer for 2 seconds.

Display at the end of the minibuffer input is
NOT a fix.  It can't be.  I already listed
specific advantages of `message', one of which
is to interrupt your input and use the entire
echo area to display a message.

`minibuffer-message' has its own specific
advantages, and thus specific use cases.  It
does not replace `message' and its advantages.

> When the minibuffer is not active, it displays
> the message in the echo area for 2 seconds
> (the timeout is configurable).

That too is BAD.  Code should be able to control
the interruption in the standard ways: `sit-for'
and `sleep-for'.  Those allow much more control
than just a time limit for ephemeral display.

> > Don't stop _callers_ from determining the
> > appropriate behavior.  If a caller uses
> > `message' then respect that.  If the caller
> > does something stupid then fix the caller.
> 
> Callers will be able to determine the
> appropriate behavior using new variable
> like `display-messages-in-minibuffer'.

I haven't seen the code or doc.  But based on
what you say above, about your "configurable"
time limit, that doesn't sound promising, at all.

Beyond this - there's no substitute, whatever
you might cook up, for _also_ letting `message'
do what it's always done.  This is about backward
compatibility, of course, but it's about much more
than that.

If you want to add some different behavior, you're
free to add it.  But don't subtract the existing,
and very longstanding, behavior.  Add your favorite
new behavior as an _addition_, letting users opt
in to choose it, if they want.

Hopefully, any damage you're doing with this you're
doing only in Lisp, so at least I (and others) will
be able to undo it - at least by redefining things
as they were.  But it really should not come to that.
Sounds like a sad state of affairs - not happy to
see things proceed like this.

I expect a lot of damage from this, at least to my
use of Emacs and my code.  Hope I'm wrong and it's
easy to undo it.  The right thing would be for you
not to oblige anyone to do anything to retrieve the
previous (since Day One), sane behavior.  _Opt-in_,
not just willy-nilly, destruction (or progress, as
you might see it).

If you push forward with this, and if it's not
opt-in, please document explicitly how to retrieve
the previous behavior, i.e., how to opt out.