bug#64493: 29.0.92; Setting ‘dired-no-confirm’ to t does not have the expected effect

[Eli Zaretskii <eliz@gnu.org>]

> Cc: 64493@debbugs.gnu.org
> Date: Thu, 06 Jul 2023 13:14:46 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> 
> > From: Sebastian Miele <iota@whxvd.name>
> > Date: Thu, 06 Jul 2023 11:25:23 +0200
> > 
> > Run src/emacs -Q.  Evaluate (setopt dired-no-confirm t).  Try to delete
> > one or more files using Dired (using d and x, or (m and) D).  Then Emacs
> > still asks for confirmation.  Expected: After pressing x or D, the files
> > get deleted without any further questions.
> > 
> > After also trying to rename (R) files, my impression is that setting
> > ‘dired-no-confirm’ to t currently just suppresses the pop-up buffer that
> > shows the list of marked/flagged files while the action is about to be
> > executed (i.e., while waiting for the confirmation when deleting, or
> > while finding the destination when renaming multiple files).
> > 
> > The fact that ‘dired-no-confirm’ does not actually suppress confirmation
> > questions (at least when deleting files, I did not try all other
> > possible actions) probably is a bug.
> > 
> > However, it also would be nice if ‘dired-no-confirm’ would not have the
> > double meaning of also suppressing the pop-up buffer listing the marked
> > files (e.g., when finding the destination for renaming).  Ideally there
> > would be a second variable controlling just that.
> 
> The name of the variable is unfortunate, because its only effect is
> indeed to prevent the pop-up window with the list of affected files to
> be shown.  This doesn't look like a bug, because this behavior existed
> since the time the variable was added (30 years ago).  It looks like
> intentional (albeit strange) behavior.
> 
> I have now updated the doc string on the emacs-29 branch to explain
> the actual effect of the variable.
> 
> If you want to avoid the confirmation prompts, you can write a custom
> dired-deletion-confirmer function that always returns t.
> 
> Patches implementing a new option that actually prevents the
> confirmation prompts will also be welcome.

No further comments, so I'm closing the bug now.  Feel free to reopen
if something else should be done, or if someone has patches for a new
option as described above.