bug#71264: 30.0.50; Dired deletion moves point under auto-revert

[Manuel Giraud via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

[-- Attachment #1: Type: text/plain, Size: 855 bytes --]

"Basil L. Contovounesios" <basil@contovou.net> writes:

> Manuel Giraud [2024-05-31 11:42 +0200] wrote:
>> Manuel Giraud writes:
>>> Customizing `dired-clean-up-buffers-too' to nil, fixes this issue for
>>> me.  Do you see the same?
>> BTW, customizing `dired-clean-confirm-killing-deleted-buffers' to nil
>> also solve this issue.
>
> ISTR that yes, disabling the prompt avoids the issue, maybe because the
> prompt allows auto-revert-mode to take effect (just speculating).

Ok.

> I wouldn't go as far as saying that disabling the prompt 'fixes' the
> issue - I would still like to keep the prompt enabled as a user-facing
> safety feature.

You're right: this is not a 'fix' per se just a circumvention of this
issue.  Anyway, I think I've made some progress.  It seems to come from
the following unnecessary funcall (maybe you could try this patch):

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: dired.diff --]
[-- Type: text/x-patch, Size: 770 bytes --]

diff --git a/lisp/dired.el b/lisp/dired.el
index f2a75df6ef1..518d581e3e6 100644
--- a/lisp/dired.el
+++ b/lisp/dired.el
@@ -4100,9 +4100,9 @@ dired-clean-up-after-deletion
     (let ((buf (get-file-buffer fn)))
       (and buf
            (or (and dired-clean-confirm-killing-deleted-buffers
-                    (funcall #'y-or-n-p
-                             (format "Kill buffer of %s, too? "
-                                     (file-name-nondirectory fn))))
+                    (y-or-n-p
+                     (format "Kill buffer of %s, too? "
+                             (file-name-nondirectory fn))))
                (not dired-clean-confirm-killing-deleted-buffers))
            (kill-buffer buf)))
     (let ((buf-list (dired-buffers-for-dir-or-subdir

[-- Attachment #3: Type: text/plain, Size: 76 bytes --]


As to why it causes this behaviour, I really don't know.
-- 
Manuel Giraud