bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Eli Zaretskii
Subject: bug#64493: 29.0.92; Setting ‘dired-no-confirm’ to t does not have the expected effect
Date: Thu, 06 Jul 2023 13:14:46 +0300

> 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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]