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 #124 received at 75626 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Tassilo Horn <tsdh <at> gnu.org>
Cc: Michael Heerdegen <michael_heerdegen <at> web.de>,
 "75626 <at> debbugs.gnu.org" <75626 <at> debbugs.gnu.org>, Eli Zaretskii <eliz <at> gnu.org>
Subject: RE: [External] : bug#75626: 31.0.50; Dired misses or double-processes
 files when auto-revert-mode is enabled
Date: Mon, 20 Jan 2025 17:32:37 +0000

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

One might very well want to allow reversion
during some particular operation on marked
files.  Let's not assume otherwise.

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.

We should not be making _any_ assumptions
about what use of the macro can be allowed
to do or should do.  The macro and whatever
affects its use generally should not control
behavior of the function that it invokes.

Instead, code that _invokes the macro_ can,
and should, do whatever it needs, to get
the control behavior _it_ needs.

I'm repeating myself, and yes, I'm still
being vague.  But it really smells/feels
like we're now going against the generality
(and utility) of this macro, and doing so
just to be able to fix some _particular_
uses of it.  That should be a no-no.

Can you not fix those uses in their own
contexts, instead of ____ing the macro and
limiting its uses?

Previous Next

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