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

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

[Sebastian Miele]

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.

In GNU Emacs 29.0.92 (build 1, x86_64-pc-linux-gnu, GTK+ Version
 3.24.38, cairo version 1.17.8) of 2023-07-06 built on huette
Repository revision: c3fefb2b3ae098068bc03cc305b9181746d72751
Repository branch: HEAD
Windowing system distributor 'The X.Org Foundation', version 11.0.12101008
System Description: Arch Linux

Configured using:
 'configure --with-x-toolkit=gtk --with-native-compilation=yes
 --with-tree-sitter --with-json --with-mailutils --with-imagemagick'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ
IMAGEMAGICK JPEG JSON LCMS2 LIBOTF LIBSYSTEMD LIBXML2 M17N_FLT MODULES
NATIVE_COMP NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND SQLITE3
THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER WEBP X11 XDBE XIM XINPUT2
XPM GTK3 ZLIB

Important settings:
  value of $LC_COLLATE: C
  value of $LANG: C.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message mailcap yank-media puny rfc822
mml mml-sec password-cache epa derived epg rfc6068 epg-config gnus-util
text-property-search time-date mm-decode mm-bodies mm-encode mail-parse
rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045
ietf-drums mm-util mail-prsvr mail-utils tabify thingatpt help-fns
radix-tree cus-edit pp cus-start cus-load wid-edit dired-aux dired comp
comp-cstr warnings icons subr-x rx cl-seq cl-macs gv cl-extra help-mode
cl-loaddefs cl-lib bytecomp byte-compile dired-loaddefs rmc iso-transl
tooltip cconv eldoc paren electric uniquify ediff-hook vc-hooks
lisp-float-type elisp-mode mwheel term/x-win x-win term/common-win x-dnd
tool-bar dnd fontset image regexp-opt fringe tabulated-list replace
newcomment text-mode lisp-mode prog-mode register page tab-bar menu-bar
rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock
font-lock syntax font-core term/tty-colors frame minibuffer nadvice seq
simple cl-generic indonesian philippine cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese composite emoji-zwj charscript charprop case-table
epa-hook jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button
loaddefs theme-loaddefs faces cus-face macroexp files window
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget keymap hashtable-print-readable backquote threads dbusbind
inotify lcms2 dynamic-setting system-font-setting font-render-setting
cairo move-toolbar gtk x-toolkit xinput2 x multi-tty
make-network-process native-compile emacs)

Memory information:
((conses 16 128852 8294)
 (symbols 48 9029 0)
 (strings 32 36236 2204)
 (string-bytes 1 1061055)
 (vectors 16 24905)
 (vector-slots 8 413347 15262)
 (floats 8 53 21)
 (intervals 56 363 0)
 (buffers 984 14))

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

[Andreas Schwab]

On Jul 06 2023, Sebastian Miele wrote:

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

Actually, dired-no-confirm *only* has this meaning, since it was added
in 1992.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

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

[Eli Zaretskii]

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

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

[Eli Zaretskii]

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