GNU bug report logs - #71264
30.0.50; Dired deletion moves point under auto-revert

Previous Next

Package: emacs;

Reported by: "Basil L. Contovounesios" <basil <at> contovou.net>

Date: Wed, 29 May 2024 21:49:02 UTC

Severity: normal

Found in version 30.0.50

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


Message #50 received at 71264 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Manuel Giraud <manuel <at> ledu-giraud.fr>
Cc: basil <at> contovou.net, 71264 <at> debbugs.gnu.org
Subject: Re: bug#71264: 30.0.50; Dired deletion moves point under auto-revert
Date: Tue, 04 Jun 2024 17:26:50 +0300
> From: Manuel Giraud <manuel <at> ledu-giraud.fr>
> Cc: basil <at> contovou.net,  71264 <at> debbugs.gnu.org
> Date: Mon, 03 Jun 2024 22:00:47 +0200
> 
> Eli Zaretskii <eliz <at> 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.




This bug report was last modified 332 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.