Subject: Re: bug#75626: 31.0.50; Dired misses or double-processes files when auto-revert-mode is enabled

From: Tassilo Horn <[email-masked]>
Date: Fri, 17 Jan 2025 15:13:24 +0100

Eli Zaretskii <[email-masked]> writes:

>> First, I wanted to say that this wouldn't help because nobody hinders
>> the user to refresh himself.
>
> Sure, but is this a reasonable solution?  Users who turn on
> auto-revert-mode don't expect to need to revert manually, I think.

Of course.  What I mean is that I expected to be able to trigger the bug
also by reverting manually by hitting g, i.e., without having
auto-revert-mode turned on.  But that seems to be at least much harder.

>> But apparently no matter how hard I try to hit g after starting the Z
>> operation on all files, I can't reproduce the issue.  I even ramped
>> up to 1000 instead of 100 files.
>> 
>> What is the difference between auto-revert and manually reverting?
>> It seems that with just manual reverting (repeatedly hitting g during
>> the (un)compress operation on many files), I only get one refresh
>> initially which doesn't change the sorting order (or possibly only
>> with very exact timing) and then Emacs is blocked until all files are
>> (un)compressed.  With auto-revert-mode, I get many intermediate
>> refreshes during the operation.
>
> Yes, because auto-revert-mode works as part of the Emacs's main loop,
> whereas user input is processed only when Emacs is idle.

I see.  Can emacs become idle when waiting for a process to finish (like
gunzip)?  If so, the problem could also happen with manual reverts
instead of auto-revert-mode.

> Does let-binding inhibit-redisplay in the auto-revert function help in
> any way?

Not at all.  (I've bound it to t in the top let in dired-revert which is
the revert-buffer-function in dired buffers.  That's what you meant,
right?)

Bye,
Tassilo