bug#21396: 25.0.50; read-key's prompt is not visible

[Tassilo Horn]

Eli Zaretskii <eliz@gnu.org> writes:

>> >>   1. emacs -Q
>> >>   2. eval (read-key "Gimme Key: ") in *scratch*
>> >> the key will be read but the prompt is not shown in the minibuffer
>> > [...]
>> >> commit 5dc644a6b01e2cf950ff617ab15be4bf1917c38c
>> >> Author: Stefan Monnier <monnier@iro.umontreal.ca>
>> >> Date:   Tue Sep 1 21:14:18 2015 -0400
>> >>     Generalize the prefix-command machinery of C-u
>> >
>> > Hmm... I'll look into it.
>> 
>> Great, thanks.  Meanwhile others have seen that issue, too.  See the
>> thread on emacs-devel.
>
> I really hope Stefan will NOT fix this.  It's IMO the wrong way of
> dealing with such issues.
>
> If typing yes<RET> is too much in some situations, and just y is
> enough, we should not call yes-or-no-p in those situations.  AFAIU,
> the only reason to call the latter is when the question is about
> some serious matter, so we want to avoid the possibility of mistakenly
> pressing just one (wrong) key.  So if some of these situations aren't
> so grave, let's call y-or-n-p instead.
>
> And if there are people who still want to press y or n, even when they
> might err and pay dearly for their mistakes, then we could have an
> option to have yes-or-no-p call y-or-n-p instead.
>
> But using a defalias here is a kludge; asking Emacs maintenance to
> support such kludges means extra overhead and tricky code for no good
> reason.  I think we should simply say no to such requests.  We have
> more than enough work on our hands already, no need for gratuitous
> additions, thank you.

I'm guilty of having (fset 'yes-or-no-p 'y-or-n-p) in my ~/.emacs, too,
but what does this have to do with this issue?  The problem is that no
prompt of any `read-key' is visible, `y-or-n-p' is just the most
prominent place where this pops up.

Bye,
Tassilo