Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!husc6!yale!Ram-Ashwin
From: Ram-Ashwin@cs.yale.edu (Ashwin Ram)
Newsgroups: comp.emacs
Subject: Re: ARGH!  Ahem.  Umm, answering prompts & abbreviating
Keywords: yes, no, y, n, !@^!@%!
Message-ID: <49807@yale-celray.yale.UUCP>
Date: 6 Feb 89 19:27:47 GMT
References: <17901@vax5.CIT.CORNELL.EDU>
Sender: root@yale.UUCP
Reply-To: Ram-Ashwin@cs.yale.edu (Ashwin Ram)
Distribution: comp
Organization: Computer Science, Yale University, New Haven, CT 06520-2158
Lines: 37
In-reply-to: rad@vax5.CIT.CORNELL.EDU

In article <17901@vax5.CIT.CORNELL.EDU>, rad@vax5.CIT.CORNELL.EDU writes:
> Well.  Does anyone have something that will let me type 'y' or 'n' in
> response to any prompt that asks for 'yes' or 'no'?  Suffice it to say that
> I am not at all agreeable with having to type 'yes' and 'no' when 'y' and
> 'n' would do nicely.

Me neither.  I asked this very question a while ago and I found opinion
divided on this point.  Although it is painful to have two y/n functions
around, the argument went that yes/no provided an extra degree of security
for highly destructive functions where it was too easy to hit 'y' (or space)
routinely.  Some of us disagreed since typing 'yes' routinely is not much
harder than typing 'y' routinely, and having two different functions can
really get on one's nerves sometimes (as you seem to have found out).

My suggestion at the time, and I still think it's a good one, was to get rid
of yes-and-no-p and add an optional CONFIRM? argument to y-or-n-p which, if
t, would cause it to reconfirm your y/n reply, using the same prompt with
"confirm?" added onto the end of it.  This is compatible with other uses of
confirmation (e.g., filename completion), eliminates the need for users to
offer their arms :-), yet retains the extra security that yes-or-no-p is
supposed to provide.  For compatibility, yes-or-no-p can be retained as a
call to y-or-n-p with confirm? = t.

Even better, in the Emacs tradition of customizability, the CONFIRM? argument
could cause y-or-n-p to invoke a user-definable function which could, by
default, behave as yes-or-no-p does now.  Then a user could either live with
the current state of affairs, or go with the second confirmation prompt as I
described above, or just define this function to do nothing and blow away the
safety feature if s/he so desired, or do anything else under the sun.

I hesitate to state which way is "better" since this is obviously a matter of
taste, not functionality.  All the more reason for customizability which I
trust would make everyone happy.  As it stands, the best you can do is to
(fset 'yes-or-no-p (symbol-function 'y-or-n-p)), which will not trap
pre-compiled calls to yes-or-no-p written in C.

-- Ashwin.