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

From: Drew Adams <[email-masked]>
Date: Mon, 20 Jan 2025 22:32:52 +0000

> > > > 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.)