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: Stephen J. Turnbull
Subject: Re: yes-or-no-p prompt conditionally broken in master?
Date: Sat, 05 Sep 2015 14:02:18 +0900

Marcin Borkowski writes:
 > On 2015-09-04, at 11:26, Andreas Schwab <address@hidden> wrote:
 > > 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.

The API would need an argument to control it, and in that sense Eli's
proposal is incomplete.  But it makes sense.

 > +1.  They serve different purposes, and they are both needed.

Both semantics are useful, but they serve the same basic purpose.
There's no good reason for having separate APIs, and it's arguable
that maintaining parallel syntax is sufficient reason for unifying as
a single API, given some core developers' aversion to making promises
about consistency of API.

If I were a "I never saw a behavior that I wouldn't make optional"
fanatic, I'd go on to propose an elaborate API and UI, where the main
function would be

    (defun user-confirmation (prompt oracle)   ; not optional!!
      "The docstring is left as an exercise for the reader."
      (if (functionp oracle)
          (funcall oracle prompt)
        t))                ; #### too fragile in the face of typos?

And the options would be stuff like:

    (defcustom user-confirmation-fatfinger-fandango 'y-or-n-p)
    (defcustom user-confirmation-irreversible-change 'yes-or-no-p)
    (defcustom user-confirmation-truly-timid-user "don't bother me!")
    (defcustom user-confirmation-authenticate 'reauthenticate-user)

But I really don't see the need for a unification or generalization.
The two levels are enough.  Security-relevant cases will probably
have their own mechanisms anyway, and nobody would be very likely to
want to set truly-timid-user to anything other than "don't bug me".

Nor can I see any reason why the syntax would need to diverge.  Just
promise that (defalias 'yes-or-no-p 'y-or-n-p) will work forever.  If
necessary to change one or the other's signature, add dummy arguments
to the function whose implementation doesn't change.




reply via email to

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