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

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Tassilo Horn <tsdh <at> gnu.org>
Cc: 75626 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, michael.albinus <at> gmx.de
Subject: Re: bug#75626: 31.0.50; Dired misses or double-processes files when
 auto-revert-mode is enabled
Date: Wed, 22 Jan 2025 01:21:05 +0100

Tassilo Horn <tsdh <at> gnu.org> writes:

> I have to declare emacs programming bankruptcy.  The current version
> with dired--inhibit-auto-revert works fine.  Now I wanted to change that
> into a more general inhibit-auto-revert.  Here's the patch (with -b to
> make it easier to grasp):

Unfortunately it doesn't apply here.

> That last hunk in dired-internal-do-deletions is due to a wrong fix for
> the bug#71264.  When auto-revert-mode itself is bound to nil when
> auto-revert kicks in, the buffer will be removed from
> auto-revert-buffer-list causing auto-revert to be disabled forever in
> that buffer.  (At least that's my reading of the code...)

I think your reading is correct.

> Anyway, the above solution with the new inhibit-auto-revert does not
> work.  auto-revert-buffers is called from a timer and eventually
> auto-revert-handler is called for my dired buffer where the compression
> of 1000 is still ongoing but inhibit-auto-revert is nil there and
> revert-buffer is called causing the issue of this bug again.
>
> I can't understand why it doesn't see the non-nil inhibit-auto-revert
> binding in the expansion of dired-map-over-marks.  Where is the
> difference to the current working solution with
> dired--inhibit-auto-revert?  It's bound the same way and accessed from
> auto-revert-handler via the funcall to the dired buffer's
> buffer-stale-function, i.e., dired-buffer-stale-p.

I hope it's not related to the auto-revert-mode -> nil binding?

Anyway, as Ship Mints already mentioned, you never created a buffer
local binding.  A `let' binds the visible binding which is in your case
the global one - since there was no local variable binding yet.

So you bind the global variable - which is not what we want but that
binding should be visible nonetheless.  I'm not sure why it does not
work as expected.

In some situations it can help to use a variable watcher to log
variable binding changes:

  (info "(elisp) Watching Variables")


Michael.

Previous Next

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