> Any objections to removing yes-or-no-p (with a defalias for backward compatibility, of course) and making y-or-n-p serve both duties, controlled by some defcustom?
I don't mind that.
On Sep 4, 2015 7:03 AM, "David Kastrup" <
address@hidden> wrote:
Marcin Borkowski <address@hidden> writes:
> On 2015-09-04, at 11:26, Andreas Schwab <address@hidden> wrote:
>
>> Eli Zaretskii <address@hidden> writes:
>>
>>> Any objections to removing yes-or-no-p (with a defalias for backward
>>> compatibility, of course) and making y-or-n-p serve both duties,
>>> controlled by some defcustom?
>>
>> That doesn't make sense. They implement different intented meaning.
>
> +1. They serve different purposes, and they are both needed. At the
> same time. While I understand that someone might want to make
> yes-or-no-p behave like y-or-n-p all the time, someone else (like, say,
> me) might want to use y-or-n-p in places where just a confirmation is
> a nice thing to have, and yes-or-no-p in places where you really want to
> make sure that the user does not accidentally press `y'.
Not just 'y'. y-or-n-p is quite apt to turn any kind of typeahead into
an unintended answer. From its DOC string:
No confirmation of the answer is requested; a single character is
enough. SPC also means yes, and DEL means no.
--
David Kastrup