bug#27979: tab completion for "(yes or no)?"

bug#27979: tab completion for "(yes or no)?"

[積丹尼 Dan Jacobson]

You know those programs that ask you "(yes or no)?"
Well wouldn't it be great if one could hit y<TAB> and then it would
become "yes" etc.

Ah, yes-or-no-p is a built-in function in ‘C source code’.

bug#27979: tab completion for "(yes or no)?"

[Tino Calancha]

積丹尼 Dan Jacobson <jidanni@jidanni.org> writes:

> You know those programs that ask you "(yes or no)?"
> Well wouldn't it be great if one could hit y<TAB> and then it would
> become "yes" etc.
>
> Ah, yes-or-no-p is a built-in function in ‘C source code’.
IMO, Emacs prefers `yes-or-no-p' for dangerous actions, and it
uses `y-or-n-p' for safe ones.  I think this is good, to protect
beginners from lost important data; offering TAB completion would
somehow contradict this idiom.

Some experts have in their Emacs init file:
(fset 'yes-or-no-p 'y-or-n-p)

;; So that they will be prompted with (y or n).

bug#27979: tab completion for "(yes or no)?"

[Drew Adams]

> IMO, Emacs prefers `yes-or-no-p' for dangerous actions, and it
> uses `y-or-n-p' for safe ones.  I think this is good, to protect
> beginners from lost important data; offering TAB completion would
> somehow contradict this idiom.

+1
 
> Some experts have in their Emacs init file:
>   (fset 'yes-or-no-p 'y-or-n-p)
> So that they will be prompted with (y or n).

More newbies than experts, methinks. ;-)

bug#27979: tab completion for "(yes or no)?"

[Tino Calancha]

On Sun, 6 Aug 2017, Drew Adams wrote:

>> Some experts have in their Emacs init file:
>>   (fset 'yes-or-no-p 'y-or-n-p)
>> So that they will be prompted with (y or n).
>
> More newbies than experts, methinks. ;-)

I have:
(defalias 'yes-or-no-p 'y-or-n-p)

so i am neither expert nor beginner (an outsider or a secret
agent, maybe).

bug#27979: tab completion for "(yes or no)?"

[Drew Adams]

> >> Some experts have in their Emacs init file:
> >>   (fset 'yes-or-no-p 'y-or-n-p)
> >> So that they will be prompted with (y or n).
> >
> > More newbies than experts, methinks. ;-)
> 
> I have: (defalias 'yes-or-no-p 'y-or-n-p)
> so i am neither expert nor beginner (an outsider
> or a secret agent, maybe).

Actually, my reply was partly to discourage a possible
misimpression that such an alias is a sign of expertise
or will likely increase expertise.  (Not that you
suggested any such thing.)

But mainly: even (some) experts can benefit from
having to type `yes', and few (I think) really gain
much by just hitting `y'.

It's a cost/benefit thing.  If you never hit `y'
accidentally or too quickly in a critical situation
then the gain of not typing `es' and not hitting `RET'
is maybe worth it (maybe not).  If you do ever make
such a mistake then the cost can be great.

Experts (however defined) generally have more pilot
hours, and so are more likely to have been through a
few such crises and perhaps learned from them to be
careful.

A newbie, whether driving a car or driving Emacs,
can, from lack of such unfortunate experiences,
sometimes be overconfident and think that some
things, like looking in the rear-view mirror or not
texting, are just an unnecessary bother - something
only "newbies" really need.  Having a few accidents
can do wonders for teaching the value of paying
attention.

Wrt driving, a recent US study pointed out that the
youngest drivers (e.g. 16 years old) are much more
careful than are those who are just a little bit
older (e.g. 17 years old) - much more likely to
drive slower, to pay attention to other cars, not
to text, etc.  IOW, a little experience/knowledge
can be a dangerous thing.

Telling new drivers that some "expert" drivers
never need to look in the rear-view mirror would
not be a great thing to do (IMO).  And I doubt
that it would be true that some expert drivers
never do look in the mirror.

bug#27979: tab completion for "(yes or no)?"

[Tino Calancha]

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



On Sun, 6 Aug 2017, Drew Adams wrote:

>>>> Some experts have in their Emacs init file:
>>>>   (fset 'yes-or-no-p 'y-or-n-p)
>>>> So that they will be prompted with (y or n).
>>>
>>> More newbies than experts, methinks. ;-)
>>
>> I have: (defalias 'yes-or-no-p 'y-or-n-p)
>> so i am neither expert nor beginner (an outsider
>> or a secret agent, maybe).
>
> Actually, my reply was partly to discourage a possible
> misimpression that such an alias is a sign of expertise
> or will likely increase expertise.  (Not that you
> suggested any such thing.)
>
> But mainly: even (some) experts can benefit from
> having to type `yes', and few (I think) really gain
> much by just hitting `y'.
>
> It's a cost/benefit thing.  If you never hit `y'
> accidentally or too quickly in a critical situation
> then the gain of not typing `es' and not hitting `RET'
> is maybe worth it (maybe not).  If you do ever make
> such a mistake then the cost can be great.
>
> Experts (however defined) generally have more pilot
> hours, and so are more likely to have been through a
> few such crises and perhaps learned from them to be
> careful.
>
> A newbie, whether driving a car or driving Emacs,
> can, from lack of such unfortunate experiences,
> sometimes be overconfident and think that some
> things, like looking in the rear-view mirror or not
> texting, are just an unnecessary bother - something
> only "newbies" really need.  Having a few accidents
> can do wonders for teaching the value of paying
> attention.
>
> Wrt driving, a recent US study pointed out that the
> youngest drivers (e.g. 16 years old) are much more
> careful than are those who are just a little bit
> older (e.g. 17 years old) - much more likely to
> drive slower, to pay attention to other cars, not
> to text, etc.  IOW, a little experience/knowledge
> can be a dangerous thing.
>
> Telling new drivers that some "expert" drivers
> never need to look in the rear-view mirror would
> not be a great thing to do (IMO).  And I doubt
> that it would be true that some expert drivers
> never do look in the mirror.
That's the reason i didn't want to admit i am one of those guys
overwritting 'yes-or-no-p'.  I tried to kept secret.  I want to be 
pedagogical with this topic: i cannot say don't do this thing that i am
doing (maybe because i am not father yet...).  So, please Dan, don't
use it! Plese write 'yes' or 'no'.  It's for your safety.

Someone from my circle lost important deta doing 'rm -rf' without
too much care.  Yeah, we must never encourage such bad habits.  I agree
with you: to use such things, as 'rm -rf' or `y-or-no-p' as `yes-or-no-p'
a long way must be walked (usualy with mistakes too).

Now some optimistic comment: IIRC, Newton suffered a fire in his home 
destroying all his notes.  After that he rewrote everything from his head
and published 'Philosophiæ Naturalis Principia Mathematica'.  The most
important is that we don't delete our heads.

I suffered car accidents after i got confident enough.  Yes, too much 
confident might decrease natural instinct brakes.  It's also true
that after the accidents i became a better driver.  We learn everyday.

bug#27979: tab completion for "(yes or no)?"

[Drew Adams]

Here's a thought -

Whoever writes a function that prompts for confirmation
decides whether to use `yes-or-no-p' or `y-or-n-p'.
A general choice is made for all users, based on the
importance of the decision, consequences, etc. in that
context.

But not all users will agree with that choice, for that
particular function's prompting.

We could perhaps give users a way to say, "From now on,
for this particular prompting (i.e., in this particular
function/context), use `y-or-n-p', not `yes-or-no-p'.

That would be a bit like what we do for commands, such
as `narrow-to-region', that are disabled out of the box.
We give users a way to enable them one by one.

Dunno how hard it would be to implement this.  Perhaps
`yes-or-no-p' could be changed somehow to:

1. Accept a third input, such as `use-y-or-n-p-here',
   that would record the current context as one in which
   `yes-or-no-p' would just use `y-or-n-p'.

2. Recognize the calling context somehow, and substitute
   `y-or-n-p' if that context is recognized and if it
   has been recorded by the user as one where `y-or-n-p'
   should be used.

Dunno how hard that would be - in particular #2.  Or
whether it would be worth doing.  But I can see the
possibility of someone not wanting to do `yes-or-no-p'
in some particular contexts but also not wanting to
replace `yes-or-no-p' by `y-or-n-p' everywhere.

(Of course, such a user could always advise or redefine
the particular calling function, replacing `yes-or-no-p'
by `y-or-n-p'.)

bug#27979: tab completion for "(yes or no)?"

[Drew Adams]

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

> We could perhaps give users a way to say, "From now on,
> for this particular prompting (i.e., in this particular
> function/context), use `y-or-n-p', not `yes-or-no-p'.

Here's a rough bit along those lines (attached), to play with.
Just something quick & dirty, unfinished (doc etc.) and only
summarily tested.  (I did nothing with the code for dialog
boxes and `noninteractive'.)

What it does:

1. Add a CALLER optional arg to `yes-or-no-p' and `y-or-n-p'.
   It is the symbol for the function that is calling the
   confirmation-prompt function.  If CALLER is not present,
   the behavior is the same as now.

   If something like this were adopted then we would presumably
   add CALLER to calls of these functions.  For example, in the
   definition of `help-mode-revert-buffer' we would use this:
   (yes-or-no-p "Revert help buffer? " 'help-mode-revert-buffer)

2. For `yes-or-no-p', if CALLER is present then: 

   * If CALLER has non-nil property `use-y-or-n-p' then
     use `y-or-n-p' (in place of the rest of `yes-or-no-p').

   * Otherwise, `use-y-or-n-p' is a possible user input.
     If this is the input then `(put CALLER 'use-y-or-n-p t)'
     and prompt again, but with `y-or-n-p'.

3. For `y-or-n-p', if CALLER is present then:

   * Input of `e' (bound to `edit-replacement' in the keymap)
     does `(put CALLER 'use-y-or-n-p nil)', then prompts again,
     but with `yes-or-no-p'.

Let me know if you find a problem.  (BTW, why is `yes-or-no-p'
defined in C code?)

[-- Attachment #2: throw-yes-no.el --]
[-- Type: application/octet-stream, Size: 6298 bytes --]

;;; TEST:
;;; (yes-or-no-p "Agreed? ")
;;; (yes-or-no-p "Agreed? " 'help-mode-revert-buffer)
;;; (y-or-n-p "Agreed? " 'help-mode-revert-buffer)

(defun yes-or-no-p (prompt &optional caller)
  "Ask user a yes-or-no question.
Return t if answer is `yes', and nil if the answer is `no'.

If CALLER is non-nil then it is the symbol of a function that calls
`yes-or-no-p'.  In this case, the answer can also be `use-y-or-n-p',
meaning from now on use `y-or-n-p' instead of `yes-or-no-p' for
CALLER.  (In this case, `y-or-n-p' is called immediately.)

PROMPT is the string to display to ask the question.  It should end in
a space; `yes-or-no-p' adds \"(yes or no) \" to it.

The user must confirm the answer with `RET', and can edit the
input until using `RET'.

If dialog boxes are supported, a dialog box will be used
if `last-nonmenu-event' is nil, and `use-dialog-box' is non-nil."
  (if (and caller  (get caller 'use-y-or-n-p))
      (y-or-n-p prompt caller)
    (let* ((input   (intern (read-from-minibuffer (concat prompt "(yes or no) "))))
           (nogood  (not (memq input (if caller '(yes no use-y-or-n-p) '(yes no))))))
      (cond (nogood
             (message "Please answer `yes'%s"
                      (if caller ", `no', or `use-y-or-n-p'." " or `no'."))
             (sit-for 2.0)
             (yes-or-no-p prompt caller))
            ((eq input 'yes) t)
            ((eq input 'use-y-or-n-p)
             (message "`y-or-n-p' will be used here from now on.")
             (sit-for 2.0)
             (put caller 'use-y-or-n-p t)
             (y-or-n-p prompt caller))))))

(defun y-or-n-p (prompt &optional caller)
  "Ask user a \"y or n\" question.
Return t if answer is \"y\" and nil if it is \"n\".
PROMPT is the string to display to ask the question.  It should
end in a space; `y-or-n-p' adds \"(y or n) \" to it.

If CALLER is non-nil then it is the symbol of a function that calls
`y-or-n-p'.  In this case, the answer can also be \"e\", meaning from
now on use `yes-or-no-p' instead of`y-or-n-p', for CALLER.  (In this
case, `yes-or-no-p' is called immediately.)

No confirmation of the answer is requested; a single character is
enough.  SPC also means yes, and DEL means no.

To be precise, this function translates user input into responses by
consulting the bindings in `query-replace-map'; see the documentation
of that variable for more information.  In this case, the useful
bindings are `act', `skip', `recenter', `scroll-up', `scroll-down',
`quit', and `edit-replacement' (bound to \"e\").  An `act' response
means yes, and a `skip' response means no.  A `quit' response means to
invoke `keyboard-quit'.  If the user enters `recenter', `scroll-up',
or `scroll-down' responses, perform the requested window recentering
or scrolling and ask again.

Under a windowing system a dialog box will be used if `last-nonmenu-event'
is nil and `use-dialog-box' is non-nil."
  ;; ¡Beware! when I tried to edebug this code, Emacs got into a weird state
  ;; where all the keys were unbound (i.e. it somehow got triggered
  ;; within read-key, apparently).  I had to kill it.
  (let ((answer 'recenter)
        (oprompt prompt)                ; @@@
        (padded (lambda (prompt &optional dialog)
                  (let ((l (length prompt)))
                    (concat prompt
                            (if (or (zerop l) (eq ?\s (aref prompt (1- l))))
                                "" " ")
                            (if dialog "" "(y or n) "))))))
    (cond
      (noninteractive
       (setq prompt (funcall padded prompt))
       (let ((temp-prompt prompt))
         (while (not (memq answer '(act skip)))
           (let ((str (read-string temp-prompt)))
             (cond ((member str '("y" "Y")) (setq answer 'act))
                   ((member str '("n" "N")) (setq answer 'skip))
                   (t (setq temp-prompt (concat "Please answer y or n.  "
                                                prompt))))))))
      ((and (display-popup-menus-p)
            last-input-event            ; not during startup
            (listp last-nonmenu-event)
            use-dialog-box)
       (setq prompt (funcall padded prompt t)
             answer (x-popup-dialog t `(,prompt ("Yes" . act) ("No" . skip)))))
      (t
       (setq prompt (funcall padded prompt))
       (while
           (let* ((scroll-actions '(recenter scroll-up scroll-down
                                    scroll-other-window scroll-other-window-down))
                  (key
                   (let ((cursor-in-echo-area t))
                     (when minibuffer-auto-raise
                       (raise-frame (window-frame (minibuffer-window))))
                     (read-key (propertize (if (or (memq answer scroll-actions)
                                                   (eq answer 'edit-replacement))
                                               prompt
                                             (concat "Please answer y or n.  " prompt))
                                           'face 'minibuffer-prompt)))))
             (unless (eq answer 'edit-replacement)
               (setq answer (lookup-key query-replace-map (vector key) t)))
             (cond
               ((and caller  (eq answer 'edit-replacement))
                (put caller 'use-y-or-n-p nil)
                (message "`yes-or-no-p' will be used here from now on.")
                (sit-for 2.0)
                (setq answer  'exit)
                (yes-or-no-p oprompt caller))
               ((memq answer '(skip act)) nil)
               ((eq answer 'recenter)
                (recenter) t)
               ((eq answer 'scroll-up)
                (ignore-errors (scroll-up-command)) t)
               ((eq answer 'scroll-down)
                (ignore-errors (scroll-down-command)) t)
               ((eq answer 'scroll-other-window)
                (ignore-errors (scroll-other-window)) t)
               ((eq answer 'scroll-other-window-down)
                (ignore-errors (scroll-other-window-down)) t)
               ((or (memq answer '(exit-prefix quit)) (eq key ?\e))
                (signal 'quit nil) t)
               (t t)))
         (ding)
         (discard-input))))
    (let ((ret (eq answer 'act)))
      (unless noninteractive
        (message "%s%c" prompt (if ret ?y ?n)))
      ret)))

bug#27979: tab completion for "(yes or no)?"

[Eli Zaretskii]

> From: Tino Calancha <tino.calancha@gmail.com>
> Date: Sun, 06 Aug 2017 15:59:33 +0900
> Cc: 27979@debbugs.gnu.org
> 
> IMO, Emacs prefers `yes-or-no-p' for dangerous actions, and it
> uses `y-or-n-p' for safe ones.  I think this is good, to protect
> beginners from lost important data; offering TAB completion would
> somehow contradict this idiom.

Agreed.

bug#27979: tab completion for "(yes or no)?"

[積丹尼 Dan Jacobson]

>>>>> "TC" == Tino Calancha <tino.calancha@gmail.com> writes:
TC> offering TAB completion would somehow contradict this idiom.

Well I discovered for a second and subsequent yes, one can just hit the up arrow.

(But I hope that is not now going to be removed too, now that I revealed it.)

bug#27979: tab completion for "(yes or no)?"

[Tino Calancha]

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



On Sun, 6 Aug 2017, 積丹尼 Dan Jacobson wrote:

>>>>>> "TC" == Tino Calancha <tino.calancha@gmail.com> writes:
> TC> offering TAB completion would somehow contradict this idiom.
>
> Well I discovered for a second and subsequent yes, one can just hit the up arrow.
What?? Oh noo!
> (But I hope that is not now going to be removed too, now that I revealed it.)
You should keep your secrets better :-).  I already canceled the auto 
completion in the recursive deletion or dirs: now the full word is 
required.  I must thank your this report, it opened my eyes about my 
previous mistake ;-)

I really prefer that users input the full word when they are about to
run such kind of commands: commands that might destroy months-years of 
someones work.

bug#27979: tab completion for "(yes or no)?"

[Tino Calancha]

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



On Sun, 6 Aug 2017, Tino Calancha wrote:

>
>
> On Sun, 6 Aug 2017, 積丹尼 Dan Jacobson wrote:
>
>>>>>>> "TC" == Tino Calancha <tino.calancha@gmail.com> writes:
>> TC> offering TAB completion would somehow contradict this idiom.
>> 
>> Well I discovered for a second and subsequent yes, one can just hit the up 
>> arrow.
> What?? Oh noo!
>> (But I hope that is not now going to be removed too, now that I revealed 
>> it.)
My comment above (What?? Oh noo!) was just a joke.  It's perfectly 
fine that you use the arrows to repeat a previous answer.  That must work 
in almost every situation.

bug#27979: tab completion for "(yes or no)?"

[積丹尼 Dan Jacobson]

I just want TAB to act consistently.
I don't think TAB knows passwords, so don't worry about completing those.

bug#27979: tab completion for "(yes or no)?"

[Eli Zaretskii]

> From: 積丹尼 Dan Jacobson
> 	<jidanni@jidanni.org>
> Date: Mon, 07 Aug 2017 00:15:03 +0800
> Cc: 27979@debbugs.gnu.org
> 
> I just want TAB to act consistently.
> I don't think TAB knows passwords, so don't worry about completing those.

These questions require explicit user consent, so TAB-completion is
not appropriate in those cases, IMO.

bug#27979: tab completion for "(yes or no)?"

[積丹尼 Dan Jacobson]

>>>>> "DA" == Drew Adams <drew.adams@oracle.com> writes:
DA> We could perhaps give users a way to say, "From now on,
DA> for this particular prompting (i.e., in this particular

Well to be complete, you would also have to offer them "never even ask,
just do it."

Once they accidentally choose that it is only a matter of time before
they delete themselves off the face of the earth.