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: Sat, 05 Sep 2015 09:20:26 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux)

Eli Zaretskii <address@hidden> writes:

>> From: David Kastrup <address@hidden>
>> Cc: address@hidden, address@hidden,
>> address@hidden, address@hidden,
>> address@hidden, address@hidden, address@hidden,
>> address@hidden
>> Date: Fri, 04 Sep 2015 22:04:27 +0200
>> 
>> Eli Zaretskii <address@hidden> writes:
>> 
>> > I meant it already works if the script supplies "y" or "n", not
>> > literally "yes" and "no".  If you had the latter in mind, then I see
>> > no reason for a script to supply "yes" when it knows that Emacs needs
>> > "y".
>> 
>> How would the script know which user settings for the proposed
>> customizable yes-or-no-p behavior options are active when it is used in
>> a manner reading in the user init file before proceeding?
>
> The issue at hand was whether we need to have a way to make y-or-n-p
> behave like yes-or-no-p.  So the scripts we are supposed to discuss
> are those that invoke y-or-n-p, whose behavior is not subject to
> customizations under my proposal.
>
> So the scripts should always supply y followed by a newline.
>
>> > But we could, of course, extend y-or-n-p to accept "yes" and "no" when
>> > in batch mode.
>> >
>> > IOW, it's a separate issue, whose solution is not necessarily to make
>> > y-or-n-p work as yes-or-no-p.
>> 
>> It's not entirely separate since it extends the manners in which Emacs
>> might "legitimately" behave.
>
> In that regard, it indeed is not separate.  But the number of manners
> in which Emacs might behave is truly infinite,

Not with regard to discrete-valued customizable options.

-- 
David Kastrup



reply via email to

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