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
> >> >> The macro itself should stay general & unassuming.
> >> >
> >> > The plan is to change dired-buffer-stale-p so that it returns nil
> >> > when inhibit-read-only is bound to a non-nil value which is the
> >> > case during the execution of the code generated by
> >> > dired-map-over-marks and might catch other cases, too. The macro
> >> > itself stays as-is.
> >>
> >> The missing part: this change hinders auto-revert-mode from reverting
> >> the dired buffer during an operation on marked files.
> >
> > That shouldn't happen, IMO. Too general,
> > and I doubt it's needed.
>
> This bug contains a recipe showing at least one ocassion where it is
> needed.
It's needed for the _macro_ to do? I don't see
that demonstrated.
An occasion where the macro is used and you want
to prevent XYZ should be handled by the _code
that invokes the macro_, not by the macro itself,
i.e., not by expanding the macro.
> > One might very well want to allow reversion
> > during some particular operation on marked
> > files. Let's not assume otherwise.
>
> Sure, and that's still allowed, e.g., the code given as BODY of
> dired-map-over-marks could explicitly call revert-buffer if it can
> handle the result.
When you say BODY, do you mean the _function_
passed to the macro as its ARG, or the BODY
argument?
In any case, how is an invocation of the macro
supposed to override the denial of reversion?
Can it simply let-bind a variable around the
macro call? I was guessing that, with your
change the macro code itself would override
that, e.g., with its own such binding, making
it impossible to control the behavior from
_around_ the macro call.
> The point is that auto-revert-mode reverts at _unpredictable_ moments
> where chances are high that the dired buffer contents change in a way
> that the processing logic goes wrong, e.g., a marked and not yet
> processed file is now before point and will be skipped, or the other way
> round, an already processed file is now after point and will be
> processed again.
Yes, I made clear that I understand that.
And I explicitly agreed that that's a no-no.
My point was that, until now, it was up to
a _user_ to just _not do that_, i.e., not
to shoot herself in the foot. IIUC, Emacs is
now preventing her from reverting the buffer,
including, but not limited to, via
`auto-revert-mode'.
If so, I'd prefer the original, more general
behavior: leave it up to the _calling_ code to
decide whether to limit the behavior in that
way (or in any other way). If it's important
for the particular use case to prevent doing
XYZ then the _calling code_ can, and should,
prevent doing XYZ. The macro shouldn't try to
guess what should be prevented - even in the
case of buffer reversion, which, I agree, is
usually something to be prevented.
> > An operation on marked files - which really
> > means, for this macro, an operation on marked
> > _lines_, CAN DO ANYTHING. Whatever you might
> > want to do to, or with, the Dired buffer
> > display/listing you can do. That is, you
> > could until now, it sounds like.
>
> I don't see what feature you think I have stolen from you. We just
> prevent auto-revert-mode from reverting the dired buffer as long as an
> operation on marked files is in progress.
Why? Because usually that's a good thing to
prevent? Not good/general enough. Leave it up
to calling code to prevent that. Add a note
about this to the doc string, if you like. But
why have the _macro_ prevent it?
> Progress is still visible
> (SHOW-PROGRESS arg of dired-map-over-marks), i.e., the dired buffer is
> periodically redisplayed showing the changes so far because that has
> nothing to do with auto-revert-mode.
No one questioned visibility of progress.
Dunno why you mention that.
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.