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

Previous Next

Full log

View this message in rfc822 format

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

Michael Heerdegen <michael_heerdegen <at> web.de> writes:

> I <michael_heerdegen <at> web.de> wrote:
>
>> So i would rather consider to rename the variable
>> `buffer-stale-function' for the discoverability

To what?  Especially with the "boolean or function" semantics below I
can hardly come up with a suitable yet discoverable name.

That aside, I think it's hard to rename and give new semantics to a
variable which is as old as Emacs 22.1 and might be used by external
packages.

>> - or just leave things as they are.

That would also be fine by me given the actual bug is fixed.  (I'd add
another commit using dired--inhibit-auto-revert for properly fixing
bug#71264 without accidentially deactivating auto-revert-mode
altogether.)

> We could also rename the variable and pretend it is normally boolean -
> but a function value is possible in addition and has a special
> meaning.  A not uncommon solution.  Maybe this is what you had in
> mind?

At least not me.  One difference between buffer-stale-function and
inhibit-auto-revert is that the latter inhibits all auto-reverts while
buffer-stale-function is not consulted at all for file-visiting buffers
when auto-revert-tail-mode is active.

> There are caveats, though:
>
> - People could be tempted to set `inhibit-auto-revert' to t and later
>   to nil, erasing the former non-nil function value by accident.
>
> - People could try to inhibit auto revert globally (which would not be
>   possible once buffer local bindings exits), or may overlook the fact
>   that binding this variable may affect a global or a local binding.
>
> I think this is something to consider: catchy names increase the risk
> that such details are overlooked.

Probably right.

I don't have a strong preference for either way.  Maybe we should just
keep it as-is until some other use-case besides dired pops up which
might never happen.

Bye,
Tassilo

Previous Next

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