bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Eli Zaretskii
Subject: bug#21396: 25.0.50; read-key's prompt is not visible
Date: Thu, 03 Sep 2015 21:18:08 +0300

> From: Tassilo Horn <tsdh@gnu.org>
> Date: Thu, 03 Sep 2015 19:50:23 +0200
> Cc: 21396@debbugs.gnu.org
> 
> Stefan Monnier <monnier@IRO.UMontreal.CA> 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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]