bug#19064: 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>]

> > So you're saying it wasn't a mistake for you to say
> > that _user input_ (not a prompt) is permanently
> > hidden?
> 
> The minibuffer is composed of both the prompt and user input.
> Both the prompt and user input are hidden permanently
> by the message covering the whole minibuffer.

It was about `y-or-n-p', which, I repeat, does NOT
use the minibuffer.  It prompts in the echo area,
and it calls `read-key', which does not read textual
input from anywhere - certainly not the minibuffer.

You are doubling down, but you haven't yet provided
any recipe that shows that user input gets hidden
permanently.  The only thing you've shown is that
an echo-area prompt can be overwritten, and so be
lost, by subsequent echo-area output (such as from
`message').  And that's just what the original bug
reports reported in the first place!

Still, you repeat that user input is permanently
hidden.  Please show how.

> > If you had seen `(yes or no)' then you would be
> > using the minibuffer.  And if you had started to
> > type, say, `ye' for `yes', then your minibuffer
> > input would have been obscured only temporarily by
> > the compilation message.
> 
> Not temporarily, but permanently.

Not when I follow your recipe.  And not even if I
redefine `dired-deletion-confirmer' as `y-or-n-p'.

I guess you've indirectly confirmed that you did
redefine `dired-deletion-confirmer' as `y-or-n-p'?
Otherwise, how is it that you saw `(y or n)' and
not `(yes or no)'?

But if you did that then the `y-or-n-p' prompt
would be sent to the echo area; it would not be
used in the minibuffer.  The minibuffer wouldn't
be involved in your recipe at all.

On the other hand, you now seem to be indirectly
saying that you did see `(yes or no)'.  Is that
it?  Just what is your recipe?  Please start from,
say, `emacs -Q' with, say, Emacs 26.3.

Writing to the echo area does not affect minibuffer
input.  And it does not exit the minibuffer.  It
obscures minibuffer input _temporarily_, until you
hit a key, for example.

AFAIK, this is just a fact.  I know of no possibility
that allows writing to the echo area to lose your
minibuffer input or hide it permanently.

For a write to the echo area to do that, the echo
area would need to permanently hide the minibuffer.
I don't see that happening.

So no, I disagree with a claim that minibuffer
input is permanently hidden.  Until you can show
a recipe to reproduce that.

> > Using the echo area for a "prompt" is, IMO, not a
> > great idea.
> 
> I agree, this is why using the minibuffer is better.

Yes.  But only when it makes sense to use the
minibuffer. That's generally not the case for
reading a single char or a key sequence.  We have
`read-char' and `read-key' for a reason.

The minibuffer is not the best UI for every
interaction.  (And that's coming from someone who
uses the minibuffer for more than most people do.)

Is your plan to make `read-key' and such use the
minibuffer?  I _really_ hope not.  And I hope you
won't do that to `y-or-n-p'.

As I acknowledged - and as I reported originally
in bug #19064, there _is_ a problem with prompting
in the echo area, which is what `y-or-n-p' does
(likewise, other functions that call things like
`read-key').

I mentioned some possible remedies for that
in my previous mail (and before that).  And I
mentioned a different remedy in my original
report for #19064.

And the remedy I suggested in the #19064 report
was apparently the same one given by the OP of
#17272.  We both suggested, independently, that
`message' be made to hold off, if some dialog is
in progress that uses the echo area for a prompt
and that reads a char/key.

And Michael suggested another approach, also
reasonable.

Just what the right fix is for those two merged
bugs can be discussed.  But neither involves the
minibuffer.

And neither should be "fixed" by making it involve
the minibuffer.  And AFAICT, any discussion of the
minibuffer in the context of these two bugs is just
a distraction or obfuscation.

The problem is this: losing an echo-area prompt by
`y-or-n-p' because of a subsequent write to the
echo area, in particular by `message'.

The problem reported by these two bugs has nothing
whatsoever to do with the minibuffer, AFAIK.

Why you introduced the minibuffer into this, I don't
know.  If there's another bug, which involves the
minibuffer (e.g., input loss or permanent hiding
in some way), then maybe file a bug report for that?
This bug - these 2 merged bugs, are not about the
minibuffer.  Or if you really think they are, please
explain how.