bug#30073: 27.0.50; dired-do-delete ignores customization for short answers

[Drew Adams]

> Neither (fset 'yes-or-no-p 'y-or-n-p) nor
> (advice-add 'yes-or-no-p :override #'y-or-n-p)
> are good methods of customization, so dired-deletion-confirmer
> and dired-recursive-deletion-confirmer are equally bad.
> 
> What I'm thinking about is introducing a boolean customizable variable
> that would define whether abbreviated answers are preferred by the user.
> Then a new minibuffer-reading function could accept a list of
> abbreviations and map them to long full answers.
> 
> Something like ‘read-multiple-choice’ or ‘map-y-or-n-p’, but that
> would allow either long or short answers depending on customization
> like ‘rmail-confirm-expunge’, ‘url-confirmation-func’,
> ‘org-confirm-shell-link-function’, ‘org-confirm-elisp-link-function’,
> or on its argument like ‘strong-query’ in ‘custom-command-apply’.
> 
> WDYT?

(I haven't been following this thread.  Apologies if I
misunderstand/misspeak.)

First, why is this being discussed (only) in the context of
Dired?  Isn't this something to consider more generally?

Do we all agree on the following points?

1. Users advising the yes/no confirmation-prompt functions
   is not a good solution to users wanting to sometimes (or
   always) use a different prompting approach from the one
   chosen by the author of the code that prompts.

2. Choosing a single prompt approach (e.g. `y-or-n-p' or
   `yes-or-no-p') for all contexts might be appropriate for
   some users, but it is probably not a great idea in general.

3. Even a given user might appreciate that a given prompting
   context asks them using the slow approach (`yes-or-no-p')
   at first, or most of the time, but she might sometimes,
   or even generally after some experience, prefer that that
   prompting context use a faster approach (e.g. `y-or-n-p').

   IOW, it would be good for a user to be able to easily
   specify anytime, for a given prompting context, which
   prompting approach to use.

An code author chooses which confirmation-prompting approach
s?he thinks is most appropriate for most users in a given
context.  Typically, contexts where the wrong answer can have
graver consequences get the `yes-or-no-p' approach.

IIUC, this bug discussion is looking into the possibility of
giving users a simple way to choose one or the other approach
generally, i.e., for use everywhere, or at least everywhere
within some overall context (e.g. Dired).  Is that right?
If so, that responds to #1 above, but not to #2 (or #3).

Along those lines, instead of a Boolean value for a user
option, to choose one or the other approach everywhere,
perhaps an alist value would be good, with the alist entries
(somehow) characterizing the prompting approach to use for
different contexts (defined how?).

Even so, though helpful, that would not really be a good
response to #3 above.

______

I've proposed the following before, but I'll mention it again.
It doesn't respond to #1 or #2, so it is likely complementary
to what I think you're proposing, which is a user option to
choose generally, as an alternative to advising.  That is, it
could be complementary.

The first thing needed here is for confirmation-prompting
functions to be able to (and preferably to do it) specify the
current context in which they are called.  That will give
users a way to specify what they want for a particular such
context.

A start in that direction is to provide to the prompting
function the name of the function that is calling it.

No, that won't distinguish particular calls (occurrences).
But it will be a good start.

For example, if `y-or-n-p' is called from function `foo',
and if the call records that fact, then a user can specify
that all `y-or-n-p' calls from `foo' should be handled as
if they were `yes-or-no-p' calls.

This means adding an optional argument to `y-or-n-p' and
`yes-or-no-p' (and other confirmation-prompting functions).

If function `foo' wants to give a user control then it
would use `(y-or-n-p "Do you agree? " 'foo)' instead of
just `(y-or-n-p "Do you agree? ")'.  Likewise, for
`yes-or-no-p'.  That's the only change needed, to give
users control here.

I've implemented this in library `yes-no.el'.  I think it's
a good start.  Combined with a user option as discussed
above, and overriding the option's more general behavior,
it could offer quite a lot of user control unobtrusively
and straightforwardly.

`yes-no.el' works by allowing, besides the y/n and yes/no
responses, a response that says "Switch to using the other
prompting method from now on".  It thus lets users change
the prompting function interactively for the given calling
function.

In addition or alternatively, users can specify such
preferences using a user option.  Specifying behavior
interactively updates the option value and saves it.  IOW,
interactive specification is an on-the-fly shortcut to
using Customize.

Rather than describe here just what it does and how, I
invite you to have a look at the Commentary or code of
the library, if you're interested.  But the easiest way
to see what it does is just to try it.

https://www.emacswiki.org/emacs/download/yes-no.el

I think it responds to the twin needs for (1) code author
being able to judge which behavior is preferable for most
users most of the time and (2) user being able to change
the behavior anytime.