GNU bug report logs - #75626
31.0.50; Dired misses or double-processes files when auto-revert-mode is enabled

Previous Next

Full log

Message #163 received at 75626 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: "michael_heerdegen <at> web.de" <michael_heerdegen <at> web.de>,
 "75626 <at> debbugs.gnu.org" <75626 <at> debbugs.gnu.org>, "tsdh <at> gnu.org" <tsdh <at> gnu.org>
Subject: RE: [External] : Re: bug#75626: 31.0.50; Dired misses or
 double-processes files when auto-revert-mode is enabled
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?

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

That's my only disagreement.  I don't see that
fixing the bug requires changing the macro's
behavior in a general way.

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?

If so, that would be OK too.  Just how can a
user do that?  I haven't followed the patch
etc., but I'm guessing that it's not sufficient
just to turn off `auto-revert-mode', or just
bind some variable, around the macro call.

If there's no way for a user to override the
behavior to be newly imposed then that seems
a shame, to me.  Is there no reasonable
alternative that would allow prevention by
default but would let users override that
prevention in a given case?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.