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

[Drew Adams]

> I agree that advising the yes/no confirmation is not good
> from a customization standpoint.
> 
>> 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.
> 
> Please see an optional argument ‘short’ that I added to my previous
> patch.  It will allow using short answers even when customizable
> variable is nil where code authors deem appropriate.

I saw it.  That's not the problem to solve, IMO.

It's not just about giving users a cleaner way to get
`y-or-n-p' behavior globally, in place of advising
`yes-or-no-p'.  (I think/hope you agree with that much.)

But it's also not about letting code authors decide
which to use, even by overriding a user's preference.

There's no need for that at all, AFAICS.  Authors
can already get "short" behavior anytime they want,
and overriding a user setting that way would not be
helpful.

You're solving the wrong problem, I think.

It's not only about moving from long to short.  A user
can want to go the other way too.  And it's definitely
not just about a systematic move in one direction or
the other.

Just as each _author_ can (and does) decide, for any
given context, which kind of confirmation prompting to
use, so can a _user_ make her own judgment about that.
We're just not giving her a way to do that, today.

We don't provide library authors with just a binary
choice: ALL of your confirmation prompts must be long
or ALL of them must be short.  That would be silly.

For the exact same reasons we should allow _users_ the
same possibilities to judge and decide what behavior
they want here and there.  An author gets to decide
that; so should users - a fortiori.

We just need to provide an easy-to-use way to choose.

That's what I've tried to do with `yes-no.el'.  Other
approaches to solving that problem are possible.  But
that's the problem to solve, IMO.  Not just providing
a substitute for advising - another way to give users
an all-or-nothing choice.  And not giving authors a
way to override a user's choice.

Users are different.  They have different degrees of
familiarity with Emacs and different degrees of
confidence about the use of this or that part of Emacs.

And those things can and do change over time.  The
first time you use an operation that deletes a file
you might well want it to make you confirm slowly.
After using it 1000 times you might want it to let
you just hit `y'.  Or not.

>> 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').
> 
> I'm not sure if we need more fine-grained customization.
> If the user decides that a short answer is enough, enough is
> enough.

I disagree.  It's not about just a general movement,
everywhere from `yes-or-no-p' to `y-or-n-p'.  It's
about the particular user and the particular context.

A given library might (from a given user's point of
view) inappropriately use one or the other approach.
It might use `yes-or-no-p' behavior everywhere,
annoying many users.  Or it might inappropriately
use `y-or-n-p' behavior everywhere.

There is nothing that guarantees a match between an
author's idea of what is best overall and a user's
idea of what is best for her in a given context at
a given time.

Did you try `yes-no.el'?  The implementation and
use are pretty simple - not a big deal.