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

[David Kastrup]

Eli Zaretskii <address@hidden> writes:

>> Date: Fri, 04 Sep 2015 22:47:05 +0300
>> From: Eli Zaretskii <address@hidden>
>> Cc: address@hidden, address@hidden, address@hidden,
>>      address@hidden, address@hidden,
>>      address@hidden, address@hidden, address@hidden
>> 
>> > From: David Kastrup <address@hidden>
>> > Date: Fri, 04 Sep 2015 20:39:22 +0200
>> > Cc: address@hidden, address@hidden, address@hidden,
>> >    address@hidden, address@hidden,
>> >    address@hidden, address@hidden, address@hidden
>> > 
>> > >> Reliable translation into selection boxes when feeding emacs -batch from
>> > >> a script?
>> > >
>> > > y-or-n-p already does TRT in that case (no dialog boxes in -batch).
>> > 
>> > Feeding emacs -batch _from_ a script.  Meaning the script supplies "yes"
>> > and "no".
>> 
>> That already works, AFAIK.
>
> 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?

> 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.  Customizable options usually don't fall
into "if it breaks, you get to keep the pieces" category.

-- 
David Kastrup