bug#46594: Use short answers

bug#46594: Use short answers

[Juri Linkov]

[-- Attachment #1: Type: text/plain, Size: 512 bytes --]

Tags: patch

As discussed in
https://lists.gnu.org/archive/html/emacs-devel/2020-12/msg01915.html
here is an option that accomplishes the mapping of
(defalias 'yes-or-no-p 'y-or-n-p)

> It's a bit more than just
>
>   Non-nil means `yes-or-no-p' uses shorter answers "y" or "n".
>
> because short circuiting it to 'y-or-n-p' means it will also obey
> 'y-or-n-p-use-read-key'.

This is a related option, but I'm not sure if it should be mentioned
in the docstring.  Maybe a simple reference should be sufficient?

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: use-short-answers.patch --]
[-- Type: text/x-diff, Size: 1808 bytes --]

diff --git a/lisp/cus-start.el b/lisp/cus-start.el
index c0a4a6dda0..d17c419c36 100644
--- a/lisp/cus-start.el
+++ b/lisp/cus-start.el
@@ -302,6 +302,7 @@ minibuffer-prompt-properties--setter
 	     ;; fns.c
 	     (use-dialog-box menu boolean "21.1")
 	     (use-file-dialog menu boolean "22.1")
+	     (use-short-answers menu boolean "28.1")
 	     (focus-follows-mouse
               frames (choice
                       (const :tag "Off (nil)" :value nil)
diff --git a/lisp/emacs-lisp/map-ynp.el b/lisp/emacs-lisp/map-ynp.el
index 14112a1c14..6be57a4fca 100644
--- a/lisp/emacs-lisp/map-ynp.el
+++ b/lisp/emacs-lisp/map-ynp.el
@@ -304,7 +304,8 @@ read-answer
 
 When `use-dialog-box' is t, pop up a dialog window to get user input."
   (let* ((short (if (eq read-answer-short 'auto)
-                    (eq (symbol-function 'yes-or-no-p) 'y-or-n-p)
+                    (or use-short-answers
+                        (eq (symbol-function 'yes-or-no-p) 'y-or-n-p))
                   read-answer-short))
          (answers-with-help
           (if (assoc "help" answers)
diff --git a/src/fns.c b/src/fns.c
index c16f9c6399..f51ef2781d 100644
--- a/src/fns.c
+++ b/src/fns.c
@@ -2873,6 +2873,11 @@ DEFUN ("yes-or-no-p", Fyes_or_no_p, Syes_or_no_p, 1, 1, 0,
       return obj;
     }
 
+  if (use_short_answers)
+    {
+      return call1 (intern ("y-or-n-p"), prompt);
+    }
+
   AUTO_STRING (yes_or_no, "(yes or no) ");
   prompt = CALLN (Fconcat, prompt, yes_or_no);
 
@@ -5904,6 +5909,10 @@ syms_of_fns (void)
 this variable.  */);
   use_file_dialog = true;
 
+  DEFVAR_BOOL ("use-short-answers", use_short_answers,
+    doc: /* Non-nil means `yes-or-no-p' uses shorter answers "y" or "n".  */);
+  use_short_answers = false;
+
   defsubr (&Sidentity);
   defsubr (&Srandom);
   defsubr (&Slength);

bug#46594: Use short answers

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

> As discussed in
> https://lists.gnu.org/archive/html/emacs-devel/2020-12/msg01915.html
> here is an option that accomplishes the mapping of
> (defalias 'yes-or-no-p 'y-or-n-p)

Makes sense to me -- having a variable instead of this extremely common
defalias is better design.

> This is a related option, but I'm not sure if it should be mentioned
> in the docstring.  Maybe a simple reference should be sufficient?

I think mentioning it in the `yes-or-no-p' doc string would be good.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#46594: [External] : bug#46594: Use short answers

[Drew Adams]

> > As discussed in
> > https://urldefense.com/v3/__https://lists.gnu.org/archive/html/emacs-
> devel/2020-12/msg01915.html__;!!GqivPVa7Brio!PKOEWigE5iDrORKbgYbHKSe-
> DDgDExr74sBYZX3qybMC-I407gDeDkA8tD-MtISo$
> > here is an option that accomplishes the mapping of
> > (defalias 'yes-or-no-p 'y-or-n-p)
> 
> Makes sense to me -- having a variable instead of this extremely common
> defalias is better design.

Is it?  Jaywalking is extremely common (and I'm a major offender), but it's against the law for a reason: saves lives.  Speeding is extremely common, but speed limits are there for a reason.  Etc.

> > This is a related option, but I'm not sure if it should be mentioned
> > in the docstring.  Maybe a simple reference should be sufficient?
> 
> I think mentioning it in the `yes-or-no-p' doc string would be good.

I think that the doc for this option should explicitly discourage using the value that abbreviates, and say why.

It should say that `yes-or-no-p' is _intended_ to be used when it's thought that you should not respond too quickly.  At least point that out, for users to think about before customizing.

Otherwise, we're, in effect, encouraging `y-or-n-p' behavior, in the end.  There's a reason Emacs has two such UIs.

Yes, whoever writes code that uses one of them might sometimes use judgment that a given user might disagree with.  But this option doesn't affect just one or two poor uses of such a function - it affects all of them.

Presumably this option is being added because there are apparently a lot of users who don't want to be slowed down by `yes-or-no-p'.  But that's exactly the point of `yes-or-no-p'.  

Users who really want to always get `y-or-n-p' behavior have gone to the trouble of adding an alias.  That's not a lot of trouble.  Maybe the fact that they've had to jump that extra hurdle was a good, not a bad, thing?

Users can turn off automatic backup of files, and all kinds of things that they might find as bothersome or cumbersome.  Such things are there to protect us from shooting ourselves in the foot - by default.  It's fine to have user options to turn off such protection (we have option `make-backup-files', for instance.  But it can also be a good idea for the doc to point out the possible downsides.

bug#46594: [External] : bug#46594: Use short answers

[Juri Linkov]

[-- Attachment #1: Type: text/plain, Size: 1126 bytes --]

>> > This is a related option, but I'm not sure if it should be mentioned
>> > in the docstring.  Maybe a simple reference should be sufficient?
>> 
>> I think mentioning it in the `yes-or-no-p' doc string would be good.
>
> I think that the doc for this option should explicitly discourage
> using the value that abbreviates, and say why.
>
> It should say that `yes-or-no-p' is _intended_ to be used when it's
> thought that you should not respond too quickly.  At least point that
> out, for users to think about before customizing.

Thanks for suggestions.  Now below is a new patch with these changes.

> Presumably this option is being added because there are apparently
> a lot of users who don't want to be slowed down by `yes-or-no-p'.
> But that's exactly the point of `yes-or-no-p'.

For many users using longer answers doesn't protect from mistakes.
Sometimes I execute a command without verifying if it's right,
e.g. first running a harmless command, then a more dangerous,
then I forget about the last command, and thinking that the last one
was the harmless command, quickly type a key sequence 'M-! M-p RET'.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: use-short-answers.patch --]
[-- Type: text/x-diff, Size: 3316 bytes --]

diff --git a/etc/NEWS b/etc/NEWS
index 2bad41f5ee..590fea5c97 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -2408,6 +2408,11 @@ and display the result.
 When non-nil, then functions 'read-char-choice' and 'y-or-n-p' (respectively)
 use the function 'read-key' to read a character instead of using the minibuffer.
 
+---
+** New variable 'use-short-answers' to use 'y-or-n-p' instead of 'yes-or-no-p'.
+This relieves of the need to define an alias that maps one to another
+in the init file.
+
 +++
 ** 'set-window-configuration' now takes an optional 'dont-set-frame'
 parameter which, when non-nil, instructs the function not to select
diff --git a/lisp/cus-start.el b/lisp/cus-start.el
index c0a4a6dda0..d17c419c36 100644
--- a/lisp/cus-start.el
+++ b/lisp/cus-start.el
@@ -302,6 +302,7 @@ minibuffer-prompt-properties--setter
 	     ;; fns.c
 	     (use-dialog-box menu boolean "21.1")
 	     (use-file-dialog menu boolean "22.1")
+	     (use-short-answers menu boolean "28.1")
 	     (focus-follows-mouse
               frames (choice
                       (const :tag "Off (nil)" :value nil)
diff --git a/lisp/emacs-lisp/map-ynp.el b/lisp/emacs-lisp/map-ynp.el
index 14112a1c14..86a0c76fd1 100644
--- a/lisp/emacs-lisp/map-ynp.el
+++ b/lisp/emacs-lisp/map-ynp.el
@@ -265,7 +265,8 @@ read-answer-short
   "If non-nil, `read-answer' accepts single-character answers.
 If t, accept short (single key-press) answers to the question.
 If nil, require long answers.  If `auto', accept short answers if
-the function cell of `yes-or-no-p' is set to `y-or-n-p'."
+`use-short-answers' is non-nil, or the function cell of `yes-or-no-p'
+is set to `y-or-n-p'."
   :type '(choice (const :tag "Accept short answers" t)
                  (const :tag "Require long answer" nil)
                  (const :tag "Guess preference" auto))
@@ -304,7 +305,8 @@ read-answer
 
 When `use-dialog-box' is t, pop up a dialog window to get user input."
   (let* ((short (if (eq read-answer-short 'auto)
-                    (eq (symbol-function 'yes-or-no-p) 'y-or-n-p)
+                    (or use-short-answers
+                        (eq (symbol-function 'yes-or-no-p) 'y-or-n-p))
                   read-answer-short))
          (answers-with-help
           (if (assoc "help" answers)
diff --git a/src/fns.c b/src/fns.c
index c16f9c6399..7ab4bb525d 100644
--- a/src/fns.c
+++ b/src/fns.c
@@ -2873,6 +2873,11 @@ DEFUN ("yes-or-no-p", Fyes_or_no_p, Syes_or_no_p, 1, 1, 0,
       return obj;
     }
 
+  if (use_short_answers)
+    {
+      return call1 (intern ("y-or-n-p"), prompt);
+    }
+
   AUTO_STRING (yes_or_no, "(yes or no) ");
   prompt = CALLN (Fconcat, prompt, yes_or_no);
 
@@ -5904,6 +5909,15 @@ syms_of_fns (void)
 this variable.  */);
   use_file_dialog = true;
 
+  DEFVAR_BOOL ("use-short-answers", use_short_answers,
+    doc: /* Non-nil means `yes-or-no-p' uses shorter answers "y" or "n".
+It's discouraged to use single-key answers because `yes-or-no-p' is
+intended to be used when it's thought that you should not respond too
+quickly, and giving the wrong answer would have serious consequences.
+When non-nil, it uses `y-or-n-p'.  In this case it means also obeying
+the value of `y-or-n-p-use-read-key'.  */);
+  use_short_answers = false;
+
   defsubr (&Sidentity);
   defsubr (&Srandom);
   defsubr (&Slength);

bug#46594: [External] : bug#46594: Use short answers

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Date: Wed, 24 Feb 2021 20:44:51 +0200
> Cc: Lars Ingebrigtsen <larsi@gnus.org>,
>  "46594@debbugs.gnu.org" <46594@debbugs.gnu.org>
> 
> +** New variable 'use-short-answers' to use 'y-or-n-p' instead of 'yes-or-no-p'.
> +This relieves of the need to define an alias that maps one to another
> +in the init file.

is this only about y-or-n-p vs yes-or-no-p?  Or do we expect to use
this variable for other answers?  In the former case, perhaps the name
of the variable should include "yes-or-no" somewhere, since
"use-short-answers" sounds too general to hint on its use, IMO.

bug#46594: [External] : bug#46594: Use short answers

[Juri Linkov]

>> +** New variable 'use-short-answers' to use 'y-or-n-p' instead of 'yes-or-no-p'.
>> +This relieves of the need to define an alias that maps one to another
>> +in the init file.
>
> is this only about y-or-n-p vs yes-or-no-p?  Or do we expect to use
> this variable for other answers?  In the former case, perhaps the name
> of the variable should include "yes-or-no" somewhere, since
> "use-short-answers" sounds too general to hint on its use, IMO.

This is not only about about y-or-n-p/yes-or-no-p.  It also affects
the function 'read-answer' and its option 'read-answer-short'.

BTW, a related question: maybe recently added 'y-or-n-p-use-read-key'
and 'read-char-choice-use-read-key' could be joined into one option,
e.g. 'use-read-key'?

bug#46594: [External] : bug#46594: Use short answers

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: drew.adams@oracle.com,  larsi@gnus.org,  46594@debbugs.gnu.org
> Date: Wed, 24 Feb 2021 21:49:19 +0200
> 
> >> +** New variable 'use-short-answers' to use 'y-or-n-p' instead of 'yes-or-no-p'.
> >> +This relieves of the need to define an alias that maps one to another
> >> +in the init file.
> >
> > is this only about y-or-n-p vs yes-or-no-p?  Or do we expect to use
> > this variable for other answers?  In the former case, perhaps the name
> > of the variable should include "yes-or-no" somewhere, since
> > "use-short-answers" sounds too general to hint on its use, IMO.
> 
> This is not only about about y-or-n-p/yes-or-no-p.  It also affects
> the function 'read-answer' and its option 'read-answer-short'.

Then why neither NEWS nor the doc string mention those other APIs?

bug#46594: [External] : bug#46594: Use short answers

[Juri Linkov]

[-- Attachment #1: Type: text/plain, Size: 242 bytes --]

>> This is not only about about y-or-n-p/yes-or-no-p.  It also affects
>> the function 'read-answer' and its option 'read-answer-short'.
>
> Then why neither NEWS nor the doc string mention those other APIs?

Sorry, this fixes the omission:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: use-short-answers-2.patch --]
[-- Type: text/x-diff, Size: 1508 bytes --]

diff --git a/etc/NEWS b/etc/NEWS
index caa366aaef..1ec080a6db 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -2414,6 +2414,11 @@ and display the result.
 When non-nil, then functions 'read-char-choice' and 'y-or-n-p' (respectively)
 use the function 'read-key' to read a character instead of using the minibuffer.
 
+---
+** New variable 'use-short-answers' to use 'y-or-n-p' instead of 'yes-or-no-p'.
+This relieves of the need to define an alias that maps one to another
+in the init file.  The same variable also affects the function 'read-answer'.
+
 +++
 ** 'set-window-configuration' now takes an optional 'dont-set-frame'
 parameter which, when non-nil, instructs the function not to select
diff --git a/src/fns.c b/src/fns.c
index c16f9c6399..7c35957e0f 100644
--- a/src/fns.c
+++ b/src/fns.c
@@ -5904,6 +5909,16 @@ syms_of_fns (void)
 this variable.  */);
   use_file_dialog = true;
 
+  DEFVAR_BOOL ("use-short-answers", use_short_answers,
+    doc: /* Non-nil means `yes-or-no-p' uses shorter answers "y" or "n".
+It's discouraged to use single-key answers because `yes-or-no-p' is
+intended to be used when it's thought that you should not respond too
+quickly, and giving the wrong answer would have serious consequences.
+When non-nil, it uses `y-or-n-p'.  In this case it means also obeying
+the value of `y-or-n-p-use-read-key'.  The same variable also affects
+the function `read-answer'.  */);
+  use_short_answers = false;
+
   defsubr (&Sidentity);
   defsubr (&Srandom);
   defsubr (&Slength);

bug#46594: [External] : bug#46594: Use short answers

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: drew.adams@oracle.com,  larsi@gnus.org,  46594@debbugs.gnu.org
> Date: Wed, 24 Feb 2021 22:50:21 +0200
> 
> >> This is not only about about y-or-n-p/yes-or-no-p.  It also affects
> >> the function 'read-answer' and its option 'read-answer-short'.
> >
> > Then why neither NEWS nor the doc string mention those other APIs?
> 
> Sorry, this fixes the omission:

Thanks.

bug#46594: [External] : bug#46594: Use short answers

[Juri Linkov]

tags 46594 fixed
close 46594 28.0.50
quit

>> Sorry, this fixes the omission:
>
> Thanks.

Now pushed to master and closed.

bug#46594: [External] : bug#46594: Use short answers

[Drew Adams]

> > I think that the doc for this option should explicitly discourage
> > using the value that abbreviates, and say why.
> >
> > It should say that `yes-or-no-p' is _intended_ to be used when it's
> > thought that you should not respond too quickly.  At least point that
> > out, for users to think about before customizing.
> 
> Thanks for suggestions.  Now below is a new patch with these changes.

I'm not sure we should include this:

  and giving the wrong answer would have serious consequences

That's not necessary, IMO.  Not even if you change
"would" (which is wrong) to "could".

It's enough to say that presumably yes-or-no-p is
used so you take time and perhaps think more about
the answer.  No need to imply serious consequences.

Why do we say this?

  In this case it means also obeying the value of
  `y-or-n-p-use-read-key'.

Doesn't that follow, if the behavior is that of
y-or-n-p (I don't know)?  If it does, then just
refer them to the doc for y-or-n-p; don't repeat
any of that doc here.

> > Presumably this option is being added because there are apparently
> > a lot of users who don't want to be slowed down by `yes-or-no-p'.
> > But that's exactly the point of `yes-or-no-p'.
> 
> For many users using longer answers doesn't protect from mistakes.
> Sometimes I execute a command without verifying if it's right,
> e.g. first running a harmless command, then a more dangerous,
> then I forget about the last command, and thinking that the last one
> was the harmless command, quickly type a key sequence 'M-! M-p RET'.

Yes, but this is a gross hammer (IIUC), just like
defaliasing is.  The fact that some particular
author chose yes-or-no-p for some command, and
some particular user wants y-or-n-p instead for
that command, means that they don't have the same
judgment.  And yes, the user's will should prevail.

But does it follow that because of that occurrence
our user wants to make all yes-or-no-p act like
y-or-n-p?  I think we both agree that use of one
or the other is a judgment call.  What we should
do, IMO is twofold:

1. Discourage blanket aliasing (whether by an option
or another way), to replace all yes-or-no-p by
y-or-n-p behavior.

2. Provide a way for users to establish their
preference for a given occurrence.  Not provide
only a way to replace ALL yes-or-no-p behavior
with y-or-n-p behavior.

How to do #2, I don't know.  Give users some
way to be asked what they want?

E.g., yes-or-no-p could accept some input besides
"yes" or "no", which would cause them to be
prompted whether to change THIS occurrence to
y-or-n-p behavior, or ALL occurrences, or cancel
(no change - return to yes/no prompt).

I don't think this is a great solution, but I
do think that we should try to find some way to
accommodate #2.  It's not right to just give
users defaliasing as the only solution.

Another possibility, for part of this, would be
to have your variable accept a value of `ask',
which would prompt as just mentioned (e.g. the
first time for a given occurrence).  IOW, let
users choose, for the option: (1) replace always,
never asking, (2) ask about replacing for an
occurrence, or (3) no replacement and no asking.

bug#46594: [External] : bug#46594: Use short answers

[Juri Linkov]

> I'm not sure we should include this:
>
>   and giving the wrong answer would have serious consequences
>
> That's not necessary, IMO.  Not even if you change
> "would" (which is wrong) to "could".

I copied this text verbatim from the Emacs manual
from the node (info "(emacs) Yes or No Prompts"):

     The second type of yes-or-no query is typically employed if giving
  the wrong answer would have serious consequences; it thus features a
  longer prompt ending with ‘(yes or no)’.

Now I noticed it has "if" before.

> It's enough to say that presumably yes-or-no-p is
> used so you take time and perhaps think more about
> the answer.  No need to imply serious consequences.
>
> Why do we say this?
>
>   In this case it means also obeying the value of
>   `y-or-n-p-use-read-key'.
>
> Doesn't that follow, if the behavior is that of
> y-or-n-p (I don't know)?  If it does, then just
> refer them to the doc for y-or-n-p; don't repeat
> any of that doc here.

Ok.

bug#46594: [External] : bug#46594: Use short answers

[Drew Adams]

> from "(emacs) Yes or No Prompts":
> 
>   The second type of yes-or-no query is typically employed if giving
>   the wrong answer would have serious consequences; it thus features a
>   longer prompt ending with ‘(yes or no)’.
> 
> Now I noticed it has "if" before.

Yes.

  would have serious consequences => yes-or-no-p

But not:

  yes-or-no-p => would have serious consequences

Thx.