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

[Manuel Giraud]

"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