emacs-devel
[Top][All Lists]
Advanced

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

Re: yes-or-no-p prompt conditionally broken in master?


From: David Kastrup
Subject: Re: yes-or-no-p prompt conditionally broken in master?
Date: Fri, 04 Sep 2015 11:14:13 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux)

Eli Zaretskii <address@hidden> writes:

>> Date: Thu, 3 Sep 2015 19:43:25 +0100
>> From: Artur Malabarba <address@hidden>
>> Cc: emacs-devel <address@hidden>, Brief Busters <address@hidden>,
>>      Stefan Monnier <address@hidden>,
>>      Drew Adams <address@hidden>, Kaushal Modi
>> <address@hidden>
>> 
>> >> 2. User preferences vary.  Some users never want to respond to
>> >> a `yes-or-no-p' prompt.  That's their choice.  It should be easy
>> >> for them to express their choice and have Emacs respect it.
>> >
>> > But if (1) is not enough, then I think we should fix the rest
>> > of the use cases via a user option that redirects yes-or-no-p to
>> > y-or-n-p.  Requesting us to drag on with supporting such defaliases is
>> > an unjustified maintenance burden.
>> 
>> I agree with any solution that makes it possible. Be it user option
>> or whatnot.
>
> Does anyone see a reason why we even have 2 functions, instead of just
> one that can either accept a single character or a string?

How would that even work?

> Let alone why yes-or-no-p is implemented in C, while y-or-n-p in Lisp?
>
> 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?

You mean, controlled by an optional argument?  With some defcustom for
specifying the interpretation of the optional argument?

Because otherwise you'll have a hard time retaining the current default
behavior for emacs -Q.

-- 
David Kastrup



reply via email to

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