GNU bug report logs - #21396
25.0.50; read-key's prompt is not visible

Previous Next

Full log

View this message in rfc822 format

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.