bug#34939: Some minibuffer behaviour is annoying

[Drew Adams]

> The problem is that it's hard to efficiently interact
> with something you cannot see.

But you _can_ see it.  Before and after the `message',
which disappears as soon as you type your next input
char or perform some other action.  Seeing happens
in time, over time.

> I'd think that much would be obvious.

It's too general and abstract.  Too blanket, too
black-&-white.  Too simplistic, dogmatic.

Sometimes in a dialog what's _wanted_ is to interrupt.
And there are different ways of interrupting, each of
which can be useful, helpful.

Sometimes, while a user is inputting content in the
minibuffer, she wants to interrupt her own inputting
to do something else temporarily.  Would you prevent
her from doing that too?

Sometimes something else going on wants to interrupt
her inputting to remind/report/signal/... something.

The point is that `message' interrupts temporally,
and `minibuffer-message' interrupts spatially.

They both interfere with what appears in that little
dialog space (minibuffer/echo-area real estate), but
they do so in different ways.

Those different ways lend themselves to different
uses/purposes.  They can be put to good use together
or separately.

"I'd think that much would be obvious." It should be.

You're trying to impede the use of an important
dialog construct.

To return to the OP problem statement -

Minibuffer behavior can be annoying or helpful.
Programmers have the means to do good or bad.
Your removing one of their tools does not improve
things - quite the contrary.

It's not `message' + minibuffer that's bad.  It's
a programmer's misguided use of the combination
that _can_ be bad.

Please leave programming minibuffer interaction to
programmers, instead of trying to dictate it from
on high.

Thx.