GNU bug report logs -
#75626
31.0.50; Dired misses or double-processes files when auto-revert-mode is enabled
Previous Next
Reported by: Tassilo Horn <tsdh <at> gnu.org>
Date: Fri, 17 Jan 2025 07:43:01 UTC
Severity: normal
Found in version 31.0.50
Done: Tassilo Horn <tsdh <at> gnu.org>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
Eli Zaretskii <eliz <at> gnu.org> writes:
>> > Probably testing inhibit-read-only is not TRT but the expansion of
>> > dired-map-over-marks should explicitly let-bind some new
>> > dired--map-over-marks-in-progress variable to make it more
>> > explicit...
>>
>> Yes. OTOH it's not bad either. `inhibit-read-only' bound (together
>> with buffer-read-only which we already have) is a good indicator for
>> that some operation is running and we should not auto revert.
>>
>> Unless I'm missing something I would prefer this solution.
>
> But inhibit-read-only is also nil in WDired. Do we want to disable
> auto-revert in that case?
Almost certainly.
> Why don't you prefer the new dired--map-over-marks-in-progress
> variable idea?
I can't think of a situation where inhibit-read-only is bound in a dired
buffer and auto-revert would be welcome.
Just to be clear, disabling auto-revert-mode like it's done in my patch
does not mean that you don't see the progress during a compression of
many files. dired-map-over-marks redisplays every now and then. So I
don't see a loss here.
> Or Drew's suggestion to bind revert-buffer-function to 'ignore while
> dired-map-over-marks runs?
That would also work.
> Both sound cleaner to me than relying on inhibit-read-only, which is
> used in gazillion places.
As said, my gut feeling says that inhibit-read-only in a dired buffer
suggests that auto-reverting is probably not a good idea.
Bye,
Tassilo
This bug report was last modified 196 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.