all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* bug#71264: 30.0.50; Dired deletion moves point under auto-revert
@ 2024-05-29 21:48 Basil L. Contovounesios
  2024-05-31  9:29 ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 1 reply; 21+ messages in thread
From: Basil L. Contovounesios @ 2024-05-29 21:48 UTC (permalink / raw)
  To: 71264

0. emacs -Q
1. M-: (add-hook 'dired-mode-hook #'auto-revert-mode) RET
2. M-: (require 'dired-x) RET
3. C-x d /tmp RET
4. C-x C-f foo RET C-x C-s C-x C-j
5. d x yes RET y

Point is now at BOB instead of the line from which the file was deleted.
Both steps 1 and 2 are needed to reproduce.
Emacs 24.5 does not reproduce; 25.3 and 26.3 behave like 30.

Thanks,
-- 
Basil

In GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo
 version 1.18.0, Xaw3d scroll bars) of 2024-05-29 built on tia
Repository revision: a9af70849d2d9ad2b6d2b81ba4ef4d4342bff6d8
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12101011
System Description: Debian GNU/Linux trixie/sid

Configured using:
 'configure 'CFLAGS=-Og -ggdb3' -C --prefix=/home/blc/.local
 --enable-checking=structs --without-native-compilation
 --with-file-notification=yes --with-x-toolkit=lucid --with-x'

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

Important settings:
  value of $LANG: en_IE.UTF-8
  value of $XMODIFIERS: @im=ibus
  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
  minibuffer-regexp-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 dired
dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg rfc6068
epg-config gnus-util text-property-search time-date subr-x mm-decode
mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader
cl-loaddefs cl-lib sendmail rfc2047 rfc2045 ietf-drums mm-util
mail-prsvr mail-utils 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 touch-screen 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 x-toolkit
xinput2 x multi-tty move-toolbar make-network-process emacs)

Memory information:
((conses 16 39827 22028) (symbols 48 5369 0) (strings 32 13400 2255)
 (string-bytes 1 316857) (vectors 16 9317)
 (vector-slots 8 111126 10072) (floats 8 23 25) (intervals 56 267 0)
 (buffers 992 10))





^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#71264: 30.0.50; Dired deletion moves point under auto-revert
  2024-05-29 21:48 bug#71264: 30.0.50; Dired deletion moves point under auto-revert Basil L. Contovounesios
@ 2024-05-31  9:29 ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2024-05-31  9:42   ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 1 reply; 21+ messages in thread
From: Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-05-31  9:29 UTC (permalink / raw)
  To: Basil L. Contovounesios; +Cc: 71264

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

> 0. emacs -Q
> 1. M-: (add-hook 'dired-mode-hook #'auto-revert-mode) RET
> 2. M-: (require 'dired-x) RET
> 3. C-x d /tmp RET
> 4. C-x C-f foo RET C-x C-s C-x C-j
> 5. d x yes RET y
>
> Point is now at BOB instead of the line from which the file was deleted.
> Both steps 1 and 2 are needed to reproduce.
> Emacs 24.5 does not reproduce; 25.3 and 26.3 behave like 30.

Hi Basil,

I confirm the behaviour you observe on master.  I'm trying to track this
down and it seems to come from the dired clean-up after a deletion.

Customizing `dired-clean-up-buffers-too' to nil, fixes this issue for
me.  Do you see the same?
-- 
Manuel Giraud





^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#71264: 30.0.50; Dired deletion moves point under auto-revert
  2024-05-31  9:29 ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-05-31  9:42   ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2024-05-31 12:10     ` Basil L. Contovounesios
  0 siblings, 1 reply; 21+ messages in thread
From: Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-05-31  9:42 UTC (permalink / raw)
  To: 71264; +Cc: basil

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

> "Basil L. Contovounesios" <basil@contovou.net> writes:
>
>> 0. emacs -Q
>> 1. M-: (add-hook 'dired-mode-hook #'auto-revert-mode) RET
>> 2. M-: (require 'dired-x) RET
>> 3. C-x d /tmp RET
>> 4. C-x C-f foo RET C-x C-s C-x C-j
>> 5. d x yes RET y
>>
>> Point is now at BOB instead of the line from which the file was deleted.
>> Both steps 1 and 2 are needed to reproduce.
>> Emacs 24.5 does not reproduce; 25.3 and 26.3 behave like 30.
>
> Hi Basil,
>
> I confirm the behaviour you observe on master.  I'm trying to track this
> down and it seems to come from the dired clean-up after a deletion.
>
> 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.
-- 
Manuel Giraud





^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#71264: 30.0.50; Dired deletion moves point under auto-revert
  2024-05-31  9:42   ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-05-31 12:10     ` Basil L. Contovounesios
  2024-05-31 12:54       ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2024-06-01 17:19       ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 2 replies; 21+ messages in thread
From: Basil L. Contovounesios @ 2024-05-31 12:10 UTC (permalink / raw)
  To: Manuel Giraud; +Cc: 71264

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

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.

Thanks,
-- 
Basil





^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#71264: 30.0.50; Dired deletion moves point under auto-revert
  2024-05-31 12:10     ` Basil L. Contovounesios
@ 2024-05-31 12:54       ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2024-05-31 15:48         ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2024-06-01 17:19       ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
  1 sibling, 1 reply; 21+ messages in thread
From: Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-05-31 12:54 UTC (permalink / raw)
  To: Basil L. Contovounesios; +Cc: 71264

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

^ permalink raw reply related	[flat|nested] 21+ messages in thread

* bug#71264: 30.0.50; Dired deletion moves point under auto-revert
  2024-05-31 12:54       ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-05-31 15:48         ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 0 replies; 21+ messages in thread
From: Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-05-31 15:48 UTC (permalink / raw)
  To: Basil L. Contovounesios; +Cc: 71264

Manuel Giraud <manuel@ledu-giraud.fr> writes:

[...]

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

Sorry my bad, this patch does nothing.  I forgot to activate the
'auto-revert-mode' before testing.
-- 
Manuel Giraud





^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#71264: 30.0.50; Dired deletion moves point under auto-revert
  2024-05-31 12:10     ` Basil L. Contovounesios
  2024-05-31 12:54       ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-06-01 17:19       ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2024-06-01 17:59         ` Eli Zaretskii
  1 sibling, 1 reply; 21+ messages in thread
From: Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-06-01 17:19 UTC (permalink / raw)
  To: Basil L. Contovounesios; +Cc: 71264

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

Hi Basil,

I think I'm onto something regarding this bug.  We can observe the same
misbehavior with the following patch:

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

diff --git a/lisp/dired.el b/lisp/dired.el
index f2a75df6ef1..325c61627c2 100644
--- a/lisp/dired.el
+++ b/lisp/dired.el
@@ -4100,9 +4100,7 @@ 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))))
+                    (sit-for 0.3))
                (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: 304 bytes --]


It seems to me that the 'y-or-n-p' call gives the opportunity of a time
window for the dired buffer to be reverted.  But then, when this revert
happen the file "foo" has already disappeared so it cannot be found and
the point ends up at the BOB.

I don't know how to prevent this yet.
-- 
Manuel Giraud

^ permalink raw reply related	[flat|nested] 21+ messages in thread

* bug#71264: 30.0.50; Dired deletion moves point under auto-revert
  2024-06-01 17:19       ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-06-01 17:59         ` Eli Zaretskii
  2024-06-02 14:59           ` Basil L. Contovounesios
  0 siblings, 1 reply; 21+ messages in thread
From: Eli Zaretskii @ 2024-06-01 17:59 UTC (permalink / raw)
  To: Manuel Giraud; +Cc: basil, 71264

> Cc: 71264@debbugs.gnu.org
> Date: Sat, 01 Jun 2024 19:19:12 +0200
> From:  Manuel Giraud via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> 
> It seems to me that the 'y-or-n-p' call gives the opportunity of a time
> window for the dired buffer to be reverted.

Yes, of course.  When Emacs waits for keyboard input, the
file-notification events are accepted and acted upon.

> But then, when this revert happen the file "foo" has already
> disappeared so it cannot be found and the point ends up at the BOB.

Can you explain why the disappearance of "foo" causes point to be
positioned at BOB?

> I don't know how to prevent this yet.

I'm not sure I understand why we need to prevent that.





^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#71264: 30.0.50; Dired deletion moves point under auto-revert
  2024-06-01 17:59         ` Eli Zaretskii
@ 2024-06-02 14:59           ` Basil L. Contovounesios
  2024-06-02 15:23             ` Eli Zaretskii
  0 siblings, 1 reply; 21+ messages in thread
From: Basil L. Contovounesios @ 2024-06-02 14:59 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: Manuel Giraud, 71264

Eli Zaretskii [2024-06-01 20:59 +0300] wrote:

>> Cc: 71264@debbugs.gnu.org
>> Date: Sat, 01 Jun 2024 19:19:12 +0200
>> From:  Manuel Giraud via "Bug reports for GNU Emacs,
>>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
>> 
>> I don't know how to prevent this yet.
>
> I'm not sure I understand why we need to prevent that.

I encounter this most often in my homedir: it contains ~140 subdirs and
files, meaning BOB and EOB are separated by ~2 pagefuls.  Files are
sorted by name in groups: subdirs first, then dotfiles, then the rest.
Each time some program, such as a screenshot application, stores a file
in my homedir, it appears near EOB.  And each time I delete such a file,
I lose my current position and have to scroll down 2 pagefuls again.

I understand that auto-revert-mode can come with limitations, but I
don't think this UX is right, and I imagine Dired can do better.

Thanks,
-- 
Basil





^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#71264: 30.0.50; Dired deletion moves point under auto-revert
  2024-06-02 14:59           ` Basil L. Contovounesios
@ 2024-06-02 15:23             ` Eli Zaretskii
  2024-06-02 17:02               ` Basil L. Contovounesios
  0 siblings, 1 reply; 21+ messages in thread
From: Eli Zaretskii @ 2024-06-02 15:23 UTC (permalink / raw)
  To: Basil L. Contovounesios; +Cc: manuel, 71264

> From: "Basil L. Contovounesios" <basil@contovou.net>
> Cc: Manuel Giraud <manuel@ledu-giraud.fr>,  71264@debbugs.gnu.org
> Date: Sun, 02 Jun 2024 16:59:55 +0200
> 
> Eli Zaretskii [2024-06-01 20:59 +0300] wrote:
> 
> >> Cc: 71264@debbugs.gnu.org
> >> Date: Sat, 01 Jun 2024 19:19:12 +0200
> >> From:  Manuel Giraud via "Bug reports for GNU Emacs,
> >>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> >> 
> >> I don't know how to prevent this yet.
> >
> > I'm not sure I understand why we need to prevent that.
> 
> I encounter this most often in my homedir: it contains ~140 subdirs and
> files, meaning BOB and EOB are separated by ~2 pagefuls.  Files are
> sorted by name in groups: subdirs first, then dotfiles, then the rest.
> Each time some program, such as a screenshot application, stores a file
> in my homedir, it appears near EOB.  And each time I delete such a file,
> I lose my current position and have to scroll down 2 pagefuls again.
> 
> I understand that auto-revert-mode can come with limitations, but I
> don't think this UX is right, and I imagine Dired can do better.

Maybe I misunderstood what was meant by "this" in "how to prevent
this".  The preceding text was:

> It seems to me that the 'y-or-n-p' call gives the opportunity of a time
> window for the dired buffer to be reverted.  But then, when this revert
> happen the file "foo" has already disappeared so it cannot be found and
> the point ends up at the BOB.

So which part of this did Manuel want "to prevent"?  That y-or-n-p
doesn't block file notifications is AFAIU by design, and preventing
that could cause much more serious problems.  What I don't understand
is two things:

  . why the fact that "foo"s buffer was reverted affects Dired, and
    what is expected from Dired when a file and its buffer are deleted?
  . why the effect is to move point to BOB?





^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#71264: 30.0.50; Dired deletion moves point under auto-revert
  2024-06-02 15:23             ` Eli Zaretskii
@ 2024-06-02 17:02               ` Basil L. Contovounesios
  2024-06-03 18:53                 ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 1 reply; 21+ messages in thread
From: Basil L. Contovounesios @ 2024-06-02 17:02 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: manuel, 71264

Eli Zaretskii [2024-06-02 18:23 +0300] wrote:

> Maybe I misunderstood what was meant by "this" in "how to prevent
> this".  The preceding text was:
>
>> It seems to me that the 'y-or-n-p' call gives the opportunity of a time
>> window for the dired buffer to be reverted.  But then, when this revert
>> happen the file "foo" has already disappeared so it cannot be found and
>> the point ends up at the BOB.
>
> So which part of this did Manuel want "to prevent"?

I assumed it was the undesirable motion.

> That y-or-n-p doesn't block file notifications is AFAIU by design, and
> preventing that could cause much more serious problems.

Agreed.

> What I don't understand is two things:
>
>   . why the fact that "foo"s buffer was reverted affects Dired, [...]
>   . why the effect is to move point to BOB?

I suspect answering these is tantamount to fixing the bug.

> [...] what is expected from Dired when a file and its buffer are deleted?

I'd be happy with the same behaviour as when auto-revert-mode is
disabled: point remains on the same line; either on the next file in the
listing, or at EOB if there is no next file.

-- 
Basil





^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#71264: 30.0.50; Dired deletion moves point under auto-revert
  2024-06-02 17:02               ` Basil L. Contovounesios
@ 2024-06-03 18:53                 ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2024-06-03 19:02                   ` Eli Zaretskii
  0 siblings, 1 reply; 21+ messages in thread
From: Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-06-03 18:53 UTC (permalink / raw)
  To: Basil L. Contovounesios; +Cc: Eli Zaretskii, 71264

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

> Eli Zaretskii [2024-06-02 18:23 +0300] wrote:
>
>> Maybe I misunderstood what was meant by "this" in "how to prevent
>> this".  The preceding text was:
>>
>>> It seems to me that the 'y-or-n-p' call gives the opportunity of a time
>>> window for the dired buffer to be reverted.  But then, when this revert
>>> happen the file "foo" has already disappeared so it cannot be found and
>>> the point ends up at the BOB.
>>
>> So which part of this did Manuel want "to prevent"?
>
> I assumed it was the undesirable motion.

Yes that's it.  This is the bug AFAIU.  Keeping the point on the file
right after the one that has been deleted would be the "correct"
behaviour.

>> That y-or-n-p doesn't block file notifications is AFAIU by design, and
>> preventing that could cause much more serious problems.
>
> Agreed.

Ok, sure.

>> What I don't understand is two things:
>>
>>   . why the fact that "foo"s buffer was reverted affects Dired, [...]
>>   . why the effect is to move point to BOB?
>
> I suspect answering these is tantamount to fixing the bug.

This I'm not sure and I have to check.  But it seems that dired keeps
the information of « what is the current file name » and go there after
having reverted the content.  If it is not found, the point stays at
BOB.

>> [...] what is expected from Dired when a file and its buffer are deleted?
>
> I'd be happy with the same behaviour as when auto-revert-mode is
> disabled: point remains on the same line; either on the next file in the
> listing, or at EOB if there is no next file.

-- 
Manuel Giraud





^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#71264: 30.0.50; Dired deletion moves point under auto-revert
  2024-06-03 18:53                 ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-06-03 19:02                   ` Eli Zaretskii
  2024-06-03 20:00                     ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 1 reply; 21+ messages in thread
From: Eli Zaretskii @ 2024-06-03 19:02 UTC (permalink / raw)
  To: Manuel Giraud; +Cc: basil, 71264

> From: Manuel Giraud <manuel@ledu-giraud.fr>
> Cc: Eli Zaretskii <eliz@gnu.org>,  71264@debbugs.gnu.org
> Date: Mon, 03 Jun 2024 20:53:46 +0200
> 
> >> What I don't understand is two things:
> >>
> >>   . why the fact that "foo"s buffer was reverted affects Dired, [...]
> >>   . why the effect is to move point to BOB?
> >
> > I suspect answering these is tantamount to fixing the bug.
> 
> This I'm not sure and I have to check.  But it seems that dired keeps
> the information of « what is the current file name » and go there after
> having reverted the content.  If it is not found, the point stays at
> BOB.

So how does Dired DTRT when you simply delete a file at point?  Why
doesn't it go to BOB in that case?





^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#71264: 30.0.50; Dired deletion moves point under auto-revert
  2024-06-03 19:02                   ` Eli Zaretskii
@ 2024-06-03 20:00                     ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2024-06-04 14:26                       ` Eli Zaretskii
  0 siblings, 1 reply; 21+ messages in thread
From: Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-06-03 20:00 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: basil, 71264

Eli Zaretskii <eliz@gnu.org> writes:

[...]

>> This I'm not sure and I have to check.  But it seems that dired keeps
>> the information of « what is the current file name » and go there after
>> having reverted the content.  If it is not found, the point stays at
>> BOB.
>
> So how does Dired DTRT when you simply delete a file at point?  Why
> doesn't it go to BOB in that case?

Because the dired buffer is not reverted (it does not re-read the ls
output in this case).  If I'm not mistaken, this takes place in
`dired-remove-entry' which removes the buffer line of the file that was
just deleted.
-- 
Manuel Giraud





^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#71264: 30.0.50; Dired deletion moves point under auto-revert
  2024-06-03 20:00                     ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-06-04 14:26                       ` Eli Zaretskii
  2024-06-04 19:51                         ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 1 reply; 21+ messages in thread
From: Eli Zaretskii @ 2024-06-04 14:26 UTC (permalink / raw)
  To: Manuel Giraud; +Cc: basil, 71264

> From: Manuel Giraud <manuel@ledu-giraud.fr>
> Cc: basil@contovou.net,  71264@debbugs.gnu.org
> Date: Mon, 03 Jun 2024 22:00:47 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> [...]
> 
> >> This I'm not sure and I have to check.  But it seems that dired keeps
> >> the information of « what is the current file name » and go there after
> >> having reverted the content.  If it is not found, the point stays at
> >> BOB.
> >
> > So how does Dired DTRT when you simply delete a file at point?  Why
> > doesn't it go to BOB in that case?
> 
> Because the dired buffer is not reverted (it does not re-read the ls
> output in this case).  If I'm not mistaken, this takes place in
> `dired-remove-entry' which removes the buffer line of the file that was
> just deleted.

AFAIR, when the Dired buffer is reverted, Dired attempts to preserve
important information, like markers etc.  So I think the problem could
be that the revert happens before Dired had time to record that
information, in which case rearranging some code should be a way
forward.





^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#71264: 30.0.50; Dired deletion moves point under auto-revert
  2024-06-04 14:26                       ` Eli Zaretskii
@ 2024-06-04 19:51                         ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2024-06-07 10:11                           ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 1 reply; 21+ messages in thread
From: Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-06-04 19:51 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: basil, 71264

Eli Zaretskii <eliz@gnu.org> writes:

[...]

> AFAIR, when the Dired buffer is reverted, Dired attempts to preserve
> important information, like markers etc.  So I think the problem could
> be that the revert happens before Dired had time to record that
> information, in which case rearranging some code should be a way
> forward.

Ok.  But it seems that the functions to preserve those informations
(`dired-save-positions', `dired-remember-marks'...) are all called from
`dired-revert'.  Which makes sense but now I'm confuse about how could
Dired loose those informations upon reverting.
-- 
Manuel Giraud





^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#71264: 30.0.50; Dired deletion moves point under auto-revert
  2024-06-04 19:51                         ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-06-07 10:11                           ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2024-06-08 16:11                             ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 1 reply; 21+ messages in thread
From: Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-06-07 10:11 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: basil, 71264

Hi,

There was a discussion that seems to be related to this issue in
bug#33458.  And here's something that Martin Rudalics said at the time:

--8<---------------cut here---------------start------------->8---
>> Maybe for dired store meta-information such as dired-filename
>> in window parameters.  Then when a dired buffer is restored in a window,
>> and dired-revert moved point-marker to the beginning of the dired buffer,
>> move point to the file from the window parameter.
>
> What if file referenced by such `dired-filename' was deleted? It is
> desirable to move to next or prev. filename but not to stay in the
> beginning of the dired buffer.

These others may have been deleted as well so I think that remaining
at the beginning of the dired buffer is more predictable here.  Note
also that the next or previous filename may depend on the order in
which filenames are shown - what if reverting changed that order?
--8<---------------cut here---------------end--------------->8---
-- 
Manuel Giraud





^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#71264: 30.0.50; Dired deletion moves point under auto-revert
  2024-06-07 10:11                           ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-06-08 16:11                             ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2024-06-15  8:52                               ` Eli Zaretskii
  0 siblings, 1 reply; 21+ messages in thread
From: Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-06-08 16:11 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: basil, 71264

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

Hi,

I don't know if this is the right approach but the following patch gives
me the expected behaviour.

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Prevent-auto-revert-when-deleting-entry-bug-71264.patch --]
[-- Type: text/x-patch, Size: 1111 bytes --]

From 4aa18aa0e60a8af0bbc8d333fc5e07caf6b3ab0a Mon Sep 17 00:00:00 2001
From: Manuel Giraud <manuel@ledu-giraud.fr>
Date: Sat, 8 Jun 2024 18:08:28 +0200
Subject: [PATCH] Prevent auto-revert when deleting entry(bug#71264)

* lisp/dired.el (dired-internal-do-deletions): Temporarily
  prevent auto-revert.
---
 lisp/dired.el | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/lisp/dired.el b/lisp/dired.el
index c51e5e42c29..67683c4ab93 100644
--- a/lisp/dired.el
+++ b/lisp/dired.el
@@ -4015,7 +4015,11 @@ dired-internal-do-deletions
               (dired-move-to-filename)
 	      (let ((inhibit-read-only t))
 		(condition-case err
-		    (let ((fn (car (car l))))
+		    (let ((fn (car (car l)))
+                          ;; Temporarily prevent auto-revert while
+                          ;; deleting entry in the dired buffer.
+                          (auto-revert-mode nil)
+                          (dired-auto-revert-buffer nil))
 		      (dired-delete-file fn dired-recursive-deletes trash)
 		      ;; if we get here, removing worked
 		      (setq succ (1+ succ))
-- 
2.45.1


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

-- 
Manuel Giraud

^ permalink raw reply related	[flat|nested] 21+ messages in thread

* bug#71264: 30.0.50; Dired deletion moves point under auto-revert
  2024-06-08 16:11                             ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-06-15  8:52                               ` Eli Zaretskii
  2024-06-17  9:29                                 ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 1 reply; 21+ messages in thread
From: Eli Zaretskii @ 2024-06-15  8:52 UTC (permalink / raw)
  To: Manuel Giraud; +Cc: basil, 71264

> From: Manuel Giraud <manuel@ledu-giraud.fr>
> Cc: basil@contovou.net,  71264@debbugs.gnu.org
> Date: Sat, 08 Jun 2024 18:11:53 +0200
> 
> I don't know if this is the right approach but the following patch gives
> me the expected behaviour.

I think we should install this, but byte-compiling it produces a
warning:

  In dired-internal-do-deletions:
  dired.el:4021:28: Warning: Unused lexical variable `auto-revert-mode'

Can you fix this and resubmit?

Also, I presume all the Dired tests in the test suite still pass after
the change?

Thanks.





^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#71264: 30.0.50; Dired deletion moves point under auto-revert
  2024-06-15  8:52                               ` Eli Zaretskii
@ 2024-06-17  9:29                                 ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2024-06-22  8:53                                   ` Eli Zaretskii
  0 siblings, 1 reply; 21+ messages in thread
From: Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-06-17  9:29 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: basil, 71264

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

Eli Zaretskii <eliz@gnu.org> writes:

> I think we should install this, but byte-compiling it produces a
> warning:
>
>   In dired-internal-do-deletions:
>   dired.el:4021:28: Warning: Unused lexical variable `auto-revert-mode'
>
> Can you fix this and resubmit?

Thanks Eli.  Here is an updated version of this patch.  I also removed
the setting of `dired-auto-revert-buffer' that has nothing to do with
this bug and added a reference to the bug number in the comments.

> Also, I presume all the Dired tests in the test suite still pass after
> the change?

I have attached the following logs: dir-tests.log, dired-aux-tests.log
and dired-x-tests.log.

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Prevent-auto-revert-when-deleting-entry-bug-71264.patch --]
[-- Type: text/x-patch, Size: 1409 bytes --]

From b4b3e32a7f1375ff228bc25311a56062d64aa049 Mon Sep 17 00:00:00 2001
From: Manuel Giraud <manuel@ledu-giraud.fr>
Date: Mon, 17 Jun 2024 11:06:28 +0200
Subject: [PATCH] Prevent auto-revert when deleting entry(bug#71264)

* lisp/dired.el (require): Require "autorevert" for
`auto-revert-mode' usage.
(dired-internal-do-deletions): Temporarily prevent auto-revert.
---
 lisp/dired.el | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/lisp/dired.el b/lisp/dired.el
index c51e5e42c29..0adf06f471e 100644
--- a/lisp/dired.el
+++ b/lisp/dired.el
@@ -36,6 +36,7 @@
 
 (eval-when-compile (require 'subr-x))
 (eval-when-compile (require 'cl-lib))
+(eval-when-compile (require 'autorevert))
 ;; When bootstrapping dired-loaddefs has not been generated.
 (require 'dired-loaddefs nil t)
 (require 'dnd)
@@ -4015,7 +4016,11 @@ dired-internal-do-deletions
               (dired-move-to-filename)
 	      (let ((inhibit-read-only t))
 		(condition-case err
-		    (let ((fn (car (car l))))
+		    (let ((fn (car (car l)))
+                          ;; Temporarily prevent auto-revert while
+                          ;; deleting entry in the dired buffer
+                          ;; (bug#71264).
+                          (auto-revert-mode nil))
 		      (dired-delete-file fn dired-recursive-deletes trash)
 		      ;; if we get here, removing worked
 		      (setq succ (1+ succ))
-- 
2.45.2


[-- Attachment #3: dired-tests.log --]
[-- Type: text/plain, Size: 2146 bytes --]

Running 16 tests (2024-06-17 11:19:04+0200, selector ‘(not (or (tag :expensive-test) (tag :unstable) (tag :nativecomp)))’)
   passed   1/16  dired-autoload (0.000141 sec)
Marking matching files...
Checking /home/manuel/emacs-repo/test/bug22694/test
1 matching file marked
   passed   2/16  dired-test-bug22694 (0.085776 sec)
Copy: 1 of 1
Copy: 1 file done
Copy: 1 of 1
Copy: 1 file done
   passed   3/16  dired-test-bug25609 (0.034042 sec)
Saved pos: ((#<buffer emacs-test-tp9Za3-dired> nil 4) nil nil)
Saved pos: ((#<buffer emacs-test-tp9Za3-dired> "/tmp/emacs-test-tp9Za3-dired/test-subdir" 4) ((#<window 1 on emacs-test-tp9Za3-dired> "/tmp/emacs-test-tp9Za3-dired/test-subdir" 4)) nil)
Saved pos: ((#<buffer emacs-test-tp9Za3-dired> "/tmp/emacs-test-tp9Za3-dired/test-subdir" 4) ((#<window 1 on emacs-test-tp9Za3-dired> "/tmp/emacs-test-tp9Za3-dired/test-subdir" 4)) nil)
Saved pos: ((#<buffer emacs-test-tp9Za3-dired> "/tmp/emacs-test-tp9Za3-dired/test-subdir" 4) ((#<window 1 on emacs-test-tp9Za3-dired> "/tmp/emacs-test-tp9Za3-dired/test-subdir" 4)) nil)
Saved pos: ((#<buffer emacs-test-tp9Za3-dired> "/tmp/emacs-test-tp9Za3-dired/test-subdir" 4) ((#<window 1 on emacs-test-tp9Za3-dired> "/tmp/emacs-test-tp9Za3-dired/test-subdir" 4)) nil)
   passed   4/16  dired-test-bug27243-01 (0.042852 sec)
   passed   5/16  dired-test-bug27243-02 (0.041971 sec)
   passed   6/16  dired-test-bug27243-03 (0.094497 sec)
   passed   7/16  dired-test-bug27631 (0.013950 sec)
   passed   8/16  dired-test-bug27940 (0.086650 sec)
   passed   9/16  dired-test-bug27968 (0.021243 sec)
   passed  10/16  dired-test-bug59047 (0.037082 sec)
   passed  11/16  dired-test-bug7131 (0.088727 sec)
   passed  12/16  dired-test-directory-files (0.003667 sec)
   passed  13/16  dired-test-directory-files-and-attributes (0.002743 sec)
   passed  14/16  files-tests-bug-50630 (0.010067 sec)
   passed  15/16  files-tests-insert-directory-shows-files (0.009958 sec)
   passed  16/16  files-tests-insert-directory-shows-free (0.010036 sec)

Ran 16 tests, 16 results as expected, 0 unexpected (2024-06-17 11:19:05+0200, 0.585970 sec)


[-- Attachment #4: dired-aux-tests.log --]
[-- Type: text/plain, Size: 729 bytes --]

Running 5 tests (2024-06-17 11:19:04+0200, selector ‘(not (or (tag :expensive-test) (tag :unstable) (tag :nativecomp)))’)
   passed  1/5  dired-guess-default (0.000328 sec)
/tmp/emacs-test-6LIEqx-dired-aux
/tmp/emacs-test-6LIEqx-dired-aux
/tmp/emacs-test-6LIEqx-dired-aux
/tmp/emacs-test-6LIEqx-dired-aux
ls: .//tmp/emacs-test-6LIEqx-dired-aux: No such file or directory
/tmp/emacs-test-6LIEqx-dired-aux
   passed  2/5  dired-test-bug27496 (0.046338 sec)
   passed  3/5  dired-test-bug28834 (0.003451 sec)
   passed  4/5  dired-test-bug30624 (0.023089 sec)
   passed  5/5  dired-test-highlight-metachar (0.000178 sec)

Ran 5 tests, 5 results as expected, 0 unexpected (2024-06-17 11:19:04+0200, 0.074519 sec)


[-- Attachment #5: dired-x-tests.log --]
[-- Type: text/plain, Size: 453 bytes --]

Running 2 tests (2024-06-17 11:19:05+0200, selector ‘(not (or (tag :expensive-test) (tag :unstable) (tag :nativecomp)))’)
Marking matching files...
2 matching files marked
2 marks removed
Marking matching files...
6 matching files marked
   passed  1/2  dired-test-bug25942 (0.025861 sec)
   passed  2/2  dired-x--string-to-number (0.000086 sec)

Ran 2 tests, 2 results as expected, 0 unexpected (2024-06-17 11:19:05+0200, 0.026748 sec)


[-- Attachment #6: Type: text/plain, Size: 18 bytes --]

-- 
Manuel Giraud

^ permalink raw reply related	[flat|nested] 21+ messages in thread

* bug#71264: 30.0.50; Dired deletion moves point under auto-revert
  2024-06-17  9:29                                 ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-06-22  8:53                                   ` Eli Zaretskii
  0 siblings, 0 replies; 21+ messages in thread
From: Eli Zaretskii @ 2024-06-22  8:53 UTC (permalink / raw)
  To: Manuel Giraud; +Cc: 71264-done, basil

> From: Manuel Giraud <manuel@ledu-giraud.fr>
> Cc: basil@contovou.net,  71264@debbugs.gnu.org
> Date: Mon, 17 Jun 2024 11:29:01 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I think we should install this, but byte-compiling it produces a
> > warning:
> >
> >   In dired-internal-do-deletions:
> >   dired.el:4021:28: Warning: Unused lexical variable `auto-revert-mode'
> >
> > Can you fix this and resubmit?
> 
> Thanks Eli.  Here is an updated version of this patch.  I also removed
> the setting of `dired-auto-revert-buffer' that has nothing to do with
> this bug and added a reference to the bug number in the comments.
> 
> > Also, I presume all the Dired tests in the test suite still pass after
> > the change?
> 
> I have attached the following logs: dir-tests.log, dired-aux-tests.log
> and dired-x-tests.log.

Thanks, installed, and closing the bug.





^ permalink raw reply	[flat|nested] 21+ messages in thread

end of thread, other threads:[~2024-06-22  8:53 UTC | newest]

Thread overview: 21+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-05-29 21:48 bug#71264: 30.0.50; Dired deletion moves point under auto-revert Basil L. Contovounesios
2024-05-31  9:29 ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-05-31  9:42   ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-05-31 12:10     ` Basil L. Contovounesios
2024-05-31 12:54       ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-05-31 15:48         ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-06-01 17:19       ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-06-01 17:59         ` Eli Zaretskii
2024-06-02 14:59           ` Basil L. Contovounesios
2024-06-02 15:23             ` Eli Zaretskii
2024-06-02 17:02               ` Basil L. Contovounesios
2024-06-03 18:53                 ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-06-03 19:02                   ` Eli Zaretskii
2024-06-03 20:00                     ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-06-04 14:26                       ` Eli Zaretskii
2024-06-04 19:51                         ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-06-07 10:11                           ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-06-08 16:11                             ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-06-15  8:52                               ` Eli Zaretskii
2024-06-17  9:29                                 ` Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-06-22  8:53                                   ` Eli Zaretskii

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.