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

From: Eli Zaretskii <[email-masked]>
Date: Mon, 20 Jan 2025 21:44:46 +0200

> From: Drew Adams <[email-masked]>
> CC: "[email-masked]" <[email-masked]>,
>         "[email-masked]"
> 	<[email-masked]>,
>         "[email-masked]" <[email-masked]>
> Date: Mon, 20 Jan 2025 19:31:34 +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.

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

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

> 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.  That way is a way of
introducing bugs into a program, and we don't write code that produces
buggy behavior.

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