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

[Eli Zaretskii]

> Date: Fri, 4 Sep 2015 13:34:39 +0000
> Cc: Andreas Schwab <address@hidden>, address@hidden,
>   address@hidden, address@hidden, address@hidden,
>   address@hidden, address@hidden
> From: Alan Mackenzie <address@hidden>
> 
> > Just to be sure we are talking about the same thing: the signature of
> > both functions and the return value are the same.  What I propose is
> > to change the body so that it could act like one or the other,
> > depending on the value of some defcustom.
> 
> I know I'm a bit late to this thread, but I find the above worrying,
> depending on the "depending".
> 
> If the defcustom has three values "Always-y-or-n", "Always-yes-or-no",
> "depends-on-the-particular-invocation", I'm fine.  With just the first
> two alternatives, I wouldn't like it.

The intent is to provide a predicate defcustom that allows to cause
yes-or-no-p behave like y-or-n-p.  y-or-n-p will always behave as it
does, and I didn't intend to change that, as I don't see the use case
for that.

If you still want the 3rd alternative, please describe the use cases
that would need it.

> I'm wondering whether coalescing these two function is more trouble than
> it's worth.

Please don't worry about the implementation aspects.  It's not rocket
science in any case.