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
Message #145 received at 75626 <at> debbugs.gnu.org (full text, mbox):
> > > > An operation on marked files - which really
> > > > means, for this macro, an operation on marked
> > > > _lines_, CAN DO ANYTHING.
> > >
> > > Auto-reverting is not something the operation on files does, it is
> > > something that happens behind the operation's back.
> >
> > Yes (though the macro doesn't necessarily invoke
> > any operation on files).
> >
> > And auto-reverting could occur while the macro is
> > iterating over the marked lines, and while it's
> > invoking its ARG function with point on a given
> > line.
> >
> > And yes, that can be a bother, and it's usually
> > _not_ what you want or expect. Agreed on all of
> > that. Is it _always_ not what you want/expect?
>
> Yes. Because the only way this macro can work predictably and
> reliably is if it works on a snapshot of the directory's state. It
> cannot allow changed in the files that its body did not cause and does
> not know about.
Again, it's not about changes in the files. The
macro carries out an action on the marked _lines_.
Not the same thing as acting on the files marked
on those lines.
Sorry, but I'm not convinced that you can make
such an "always" statement, logically. You can
make a "usually" statement, to which I've agreed.
> > > It affects the list of files that the operation
> > > wants to map over, and could easily cause the
> > > operation to never terminate.
> >
> > Yes, I can see that. I'd suggest letting that
> > happen, by default, and add a note in the doc
> > telling you how you can prevent that when/where
> > you _call_ the macro.
>
> If features like auto-revert are allowed to run during the macro's
> operation, there's _nothing_ you can do to prevent these problems.
> That's what the discussion of this bug reveals.
You can bind `revert-buffer-function' to `ignore'
around the call to `dired-map-over-marks'.
Yes, that can't prevent some other code that
somehow gets run during `d-m-o-m' from, itself,
binding `revert-function' to `dired-revert' (or
to `foobar', which sparks nuclear war), but I
don't think that needs to be worried about.
It's not what this bug report points to, I'm
guessing. Isn't the bug about preventing
auto-reversion (or other-provoked reversion)
during `dired-map-over-marks'?
Have you tried that: in `dired-do-compress' or
whatever other place you feel there's a problem,
just bind `revert-buffer-function' to `ignore'
around the call to `d-m-o-m'. Doesn't that fix
the reported problem? Or am I just being naïve?
> > That's my only disagreement. I don't see that
> > fixing the bug requires changing the macro's
> > behavior in a general way.
>
> Because otherwise the macro itself has a bug that cannot be possibly
> fixed in the body.
Not in the body, no. But outside the `d-m-o-m'
call: wrap it with a let-binding - a common
idiom to affect the behavior of code within the
let scope. (Likewise for `flet' and `labels',
and even advice, if you really need to get into
the nitty gritty of the function.)
> > OTOH, if you make that change, is there some
> > way for a user to modify the behavior for a
> > given macro call, to _allow_ what would now be
> > prevented in a general way?
>
> No, and neither should there be such a way.
You haven't given a reason why not. You've only
give a reason why it's _usually_ bad to allow
reversion during `dired-map-over-marks'.
> That way is a way of introducing bugs into a
> program, and we don't write code that produces
> buggy behavior.
Sorry, but that's hyperbole. As Eli Z. is wont
to say, Elisp provides lots of rope for coders
to hang themselves with. Intentionally. To
give coders more flexibility.
> > If there's no way for a user to override the
> > behavior to be newly imposed then that seems
> > a shame, to me.
>
> I challenge you to come up with a problem whose solution requires to
> allow auto-revert to modify the list of files while the macro runs.
I challenge you to prove it's necessary to
_always_ prevent reversion. Not just argue that
it's usually helpful to prevent it, to which I
agree wholeheartedly.
> If you can come up with such a problem, we could then discuss this and
> see what followup changes might be needed. Otherwise, I see no reason
> to continue this discussion, since we are talking about problems that
> don't exist in practice, AFAIK.
Today the possibility exists. Tomorrow it
won't, even should someone want to take
advantage of it for <whatever> reason.
(OK, they will of course still be able to
redefine `d-m-o-m'. That's not the kind of
control by code users have today, which is
what I have in mind.)
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.