[Top][All Lists]

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

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

From: Eli Zaretskii
Subject: Re: yes-or-no-p prompt conditionally broken in master?
Date: Fri, 04 Sep 2015 20:56:46 +0300

> 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.

reply via email to

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