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

[Alan Mackenzie]

Hello, Eli.

On Fri, Sep 04, 2015 at 03:58:52PM +0300, Eli Zaretskii wrote:
> > From: Andreas Schwab <address@hidden>
> > Cc: address@hidden,  address@hidden,  address@hidden,  address@hidden,  
> > address@hidden,  address@hidden
> > Date: Fri, 04 Sep 2015 14:40:00 +0200

> > Eli Zaretskii <address@hidden> writes:

> > >> From: Andreas Schwab <address@hidden>
> > >> Cc: address@hidden,  address@hidden,  address@hidden,  address@hidden,  
> > >> address@hidden,  address@hidden
> > >> Date: Fri, 04 Sep 2015 11:26:46 +0200

> > >> Eli Zaretskii <address@hidden> writes:

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

> > >> That doesn't make sense.  They implement different intented meaning.

> > > Sorry, I lost you: what different meaning is that?

> > (elisp) Yes-or-No Queries

> Still no clue, sorry.

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

i.e. each formerly yes-or-no-p call would have to be something like

    (y-or-n-p "Really? " t)

.

> If you still think this is wrong, please elaborate.

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

-- 
Alan Mackenzie (Nuremberg, Germany).