GNU bug report logs - #46594
Use short answers

Previous Next

Package: emacs;

Reported by: Juri Linkov <juri <at> linkov.net>

Date: Wed, 17 Feb 2021 19:11:02 UTC

Severity: normal

Tags: fixed, patch

Fixed in version 28.0.50

Done: Juri Linkov <juri <at> linkov.net>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 46594 in the body.
You can then email your comments to 46594 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#46594; Package emacs. (Wed, 17 Feb 2021 19:11:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Juri Linkov <juri <at> linkov.net>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Wed, 17 Feb 2021 19:11:02 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: bug-gnu-emacs <at> gnu.org
Subject: Use short answers
Date: Wed, 17 Feb 2021 20:59:47 +0200
[Message part 1 (text/plain, inline)]
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?
[use-short-answers.patch (text/x-diff, inline)]
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);

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#46594; Package emacs. (Mon, 22 Feb 2021 15:14:02 GMT) Full text and rfc822 format available.

Message #8 received at 46594 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: 46594 <at> debbugs.gnu.org
Subject: Re: bug#46594: Use short answers
Date: Mon, 22 Feb 2021 16:13:34 +0100
Juri Linkov <juri <at> 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




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#46594; Package emacs. (Mon, 22 Feb 2021 17:14:01 GMT) Full text and rfc822 format available.

Message #11 received at 46594 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>, Juri Linkov <juri <at> linkov.net>
Cc: "46594 <at> debbugs.gnu.org" <46594 <at> debbugs.gnu.org>
Subject: RE: [External] : bug#46594: Use short answers
Date: Mon, 22 Feb 2021 17:13:28 +0000
> > 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.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#46594; Package emacs. (Wed, 24 Feb 2021 18:49:01 GMT) Full text and rfc822 format available.

Message #14 received at 46594 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>,
 "46594 <at> debbugs.gnu.org" <46594 <at> debbugs.gnu.org>
Subject: Re: [External] : bug#46594: Use short answers
Date: Wed, 24 Feb 2021 20:44:51 +0200
[Message part 1 (text/plain, inline)]
>> > 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'.

[use-short-answers.patch (text/x-diff, inline)]
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);

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#46594; Package emacs. (Wed, 24 Feb 2021 19:28:02 GMT) Full text and rfc822 format available.

Message #17 received at 46594 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: larsi <at> gnus.org, 46594 <at> debbugs.gnu.org, drew.adams <at> oracle.com
Subject: Re: bug#46594: [External] : bug#46594: Use short answers
Date: Wed, 24 Feb 2021 21:26:38 +0200
> From: Juri Linkov <juri <at> linkov.net>
> Date: Wed, 24 Feb 2021 20:44:51 +0200
> Cc: Lars Ingebrigtsen <larsi <at> gnus.org>,
>  "46594 <at> debbugs.gnu.org" <46594 <at> 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.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#46594; Package emacs. (Wed, 24 Feb 2021 19:51:02 GMT) Full text and rfc822 format available.

Message #20 received at 46594 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: larsi <at> gnus.org, 46594 <at> debbugs.gnu.org, drew.adams <at> oracle.com
Subject: Re: bug#46594: [External] : bug#46594: Use short answers
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'.

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




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#46594; Package emacs. (Wed, 24 Feb 2021 20:29:02 GMT) Full text and rfc822 format available.

Message #23 received at 46594 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: larsi <at> gnus.org, 46594 <at> debbugs.gnu.org, drew.adams <at> oracle.com
Subject: Re: bug#46594: [External] : bug#46594: Use short answers
Date: Wed, 24 Feb 2021 22:27:49 +0200
> From: Juri Linkov <juri <at> linkov.net>
> Cc: drew.adams <at> oracle.com,  larsi <at> gnus.org,  46594 <at> 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?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#46594; Package emacs. (Wed, 24 Feb 2021 20:51:01 GMT) Full text and rfc822 format available.

Message #26 received at 46594 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: larsi <at> gnus.org, 46594 <at> debbugs.gnu.org, drew.adams <at> oracle.com
Subject: Re: bug#46594: [External] : bug#46594: Use short answers
Date: Wed, 24 Feb 2021 22:50:21 +0200
[Message part 1 (text/plain, inline)]
>> 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:

[use-short-answers-2.patch (text/x-diff, inline)]
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);

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#46594; Package emacs. (Wed, 24 Feb 2021 23:56:01 GMT) Full text and rfc822 format available.

Message #29 received at 46594 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Juri Linkov <juri <at> linkov.net>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>,
 "46594 <at> debbugs.gnu.org" <46594 <at> debbugs.gnu.org>
Subject: RE: [External] : bug#46594: Use short answers
Date: Wed, 24 Feb 2021 23:55:30 +0000
> > 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.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#46594; Package emacs. (Thu, 25 Feb 2021 09:23:02 GMT) Full text and rfc822 format available.

Message #32 received at 46594 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>,
 "46594 <at> debbugs.gnu.org" <46594 <at> debbugs.gnu.org>
Subject: Re: [External] : bug#46594: Use short answers
Date: Thu, 25 Feb 2021 11:20:34 +0200
> 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.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#46594; Package emacs. (Thu, 25 Feb 2021 15:05:01 GMT) Full text and rfc822 format available.

Message #35 received at 46594 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: larsi <at> gnus.org, 46594 <at> debbugs.gnu.org, drew.adams <at> oracle.com
Subject: Re: bug#46594: [External] : bug#46594: Use short answers
Date: Thu, 25 Feb 2021 17:04:01 +0200
> From: Juri Linkov <juri <at> linkov.net>
> Cc: drew.adams <at> oracle.com,  larsi <at> gnus.org,  46594 <at> 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.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#46594; Package emacs. (Thu, 25 Feb 2021 16:41:02 GMT) Full text and rfc822 format available.

Message #38 received at 46594 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Juri Linkov <juri <at> linkov.net>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>,
 "46594 <at> debbugs.gnu.org" <46594 <at> debbugs.gnu.org>
Subject: RE: [External] : bug#46594: Use short answers
Date: Thu, 25 Feb 2021 16:40:45 +0000
> 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.

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#46594; Package emacs. (Thu, 25 Feb 2021 18:48:01 GMT) Full text and rfc822 format available.

Message #41 received at 46594 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: larsi <at> gnus.org, 46594 <at> debbugs.gnu.org, drew.adams <at> oracle.com
Subject: Re: bug#46594: [External] : bug#46594: Use short answers
Date: Thu, 25 Feb 2021 20:45:59 +0200
tags 46594 fixed
close 46594 28.0.50
quit

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

Now pushed to master and closed.




Added tag(s) fixed. Request was from Juri Linkov <juri <at> linkov.net> to control <at> debbugs.gnu.org. (Thu, 25 Feb 2021 18:48:02 GMT) Full text and rfc822 format available.

bug marked as fixed in version 28.0.50, send any further explanations to 46594 <at> debbugs.gnu.org and Juri Linkov <juri <at> linkov.net> Request was from Juri Linkov <juri <at> linkov.net> to control <at> debbugs.gnu.org. (Thu, 25 Feb 2021 18:48:02 GMT) Full text and rfc822 format available.

bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Fri, 26 Mar 2021 11:24:08 GMT) Full text and rfc822 format available.

This bug report was last modified 3 years and 25 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.