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

[Drew Adams]

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

throw-yes-no.el
Description: Binary data