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>]

> > But a question: after reversing the dependency should it be
> > customizable to get back an old behavior for Drew?
> 
> I didn't quite understand what Drew wanted (to have the prompt be
> overwritten?), but if so, a user option would be trivial to add,
> wouldn't it?  Like `display-messages-in-minibuffer' or something?

I'm sorry, but I can't follow this.  I don't know
what's been changed, or why.  (There are even two
bugs that are being handled here, apparently.)

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'.

The minibuffer can be active - or not - during
any number of other activities.  The minibuffer
is for user input, but that space is also (as
the echo area) for `message' output.

And such output - messages to the user - can,
and should be able to, be delivered while a user
is using the minibuffer for input.  Nothing wrong
with that, in general.

`message' is often, and can always be, associated
with an _interruption_: `sit-for' or `sleep-for'.
This is part of a normal UI dialog/interaction -
one kind of such interaction.

This applies also when you're using the minibuffer.
It can make sense to interrupt inputting briefly,
to deliver a message.

`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.  The complete space is available for a
message.  It's saying, "Forget about your inputting
for a moment, and read this important announcement."

(`message' also logs messages, which can be very
important.)

`minibuffer-message' is limited to appending to
your minibuffer input.  Much less space available.
And no interruption, no real separation from your
input (apart from the brackets).

Minibuffer input can be long and complex, even
using multiple lines.  `message' allows complete
separation of the input space from the output
space.  But yes, it separates in time, not space.
Is that bad? good?  It depends.

Consider also recursive minibuffers.  Imagine,
in fact, that the minibuffer is _always_ active.
You can continue to use Emacs normally in this
scenario.  `message' needs to work normally, as
does `minibuffer-message', regardless of whether
the minibuffer is active.

In sum, BOTH `message' and `minibuffer-message'
have their uses when the minibuffer is active.
They are _different_.  Neither is good or bad.

It is absolutely wrong - misguided - to suppose
that when the minibuffer is active all messages
should be delivered using `minibuffer-message'.

It's up to the functions that _use_ these two
output functions to DTRT.

Consider an asynchronous process trying to
deliver progress or result messages.  Should it
use the echo area?

If so, maybe `message' with a hard interruption
(`sleep-for') is appropriate.  Or maybe it's
appropriate to pop up a buffer to show the
messages.  Or maybe it's appropriate to use
`message' if the minibuffer is active or
`minibuffer-message' if not.  It all depends.

There are lots of UI and reporting possibilities.
It's up to the functions that are trying to tell
the user something to decide and do what's
appropriate.  It's not up to the minibuffer
("Am I active?") to decide.

No simple rule/condition (e.g. minibuffer is
active) can reasonably determine which output
effect should be used in a particular situation.

This BUG is about a particular scenario where
the functions that use output functions interact
badly during minibuffer input.

That's a PARTICULAR scenario.  A proper fix for
the bug is to find a solution specific to that
scenario - to coordinate or otherwise referee
among the participants that vie for the user's
attention.  Not taking account of the particular
scenario is wrong (and perhaps a cop-out).

Determine the real, problematic scenario, and
provide a remedy for that.  Don't try to elevate
this to some  general, abstract, blanket,
one-size-fits-all, hard-coded rule to finesse
messages during minibuffer input.

Analyze the real, specific problem in the
reported scenario, and provide a solution for
that.  Don't overreach.  Don't paint everything
the same color just because there's a scenario
where the color scheme is problematic.

That's my point.  Please do _not_ impose
`minibuffer-message' as a replacement for
`message' when the minibuffer is active.

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.

I said (perhaps in this thread) that I have a
function, `icicle-msg-maybe-in-minibuffer',
that does this - something similar to what I
guess you have in mind imposing in some
systematic way:

  (icicle-msg-maybe-in-minibuffer FORMAT-STRING
                                  &rest ARGS)

  Display FORMAT-STRING as a message.
  If called with the minibuffer inactive, use 'message'.
  Otherwise:
   If 'icicle-minibuffer-message-ok-p', then use
      'minibuffer-message'.
   Else do nothing (no message display).

But the point is that that's just another output
function, available for use by callers.  I don't
just impose that systematically.

For some callers, using that instead of `message',
or instead of `minibuffer-message', makes sense.
For others it makes sense to just use `message'
or `minibuffer-message'.

(And you'll notice that I even provide a global
variable, `icicle-minibuffer-message-ok-p', that
can be bound to override substituting
`minibuffer-message' for `message'.)

I don't object to ever using `minibuffer-message'
in place of `message'.  I object to doing that
systematically.  I object to doing that behind
the backs of callers - let the callers decide.

Can odd or unpleasant behavior sometimes result,
due to caller behavior conflicts?  Of course.
That's rare, IME, but it can happen.  When it
does. it needs to be fixed - for that particular
scenario.

And in particular, if there's something very
important that a caller is doing - some very
important message communication, then probably
something other than `message' and other than
`minibuffer-message' is appropriate - e.g., a
popup, maybe even a modal, dialog.

Dunno whether this long reply makes clear
"what Drew wanted".  I hope it helps.
And I hope you'll reconsider the simplistic
"solution" that I think you've planned.

If I'm mistaken wrt the planned solution,
apologies.  At least I hope I've made clear my
objection to what I've thought the plan is.
Thanks for listening.