GNU bug report logs - #20943
25.0.50; Dired buffers are not always auto-reverterd

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: 20943 <at> debbugs.gnu.org, markkarpov <at> openmailbox.org
Subject: bug#20943: 25.0.50; Dired buffers are not always auto-reverted
Date: Fri, 10 Jul 2015 10:10:22 +0300

> From: Michael Albinus <michael.albinus <at> gmx.de>
> Cc: Mark Karpov <markkarpov <at> openmailbox.org>,  20943 <at> debbugs.gnu.org
> Date: Fri, 10 Jul 2015 08:01:48 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > How about instead introducing a buffer-local variable, say
> > auto-revert-when-modified, which Dired will set to a non-nil value,
> > and auto-revert will test?  Then, when this variable is non-nil,
> > auto-revert could disregard the modified status, and revert the
> > buffer, if stale, anyway.
> 
> I believe we could use the existing <foo>-stale-p mechanism for that
> purpose. dired-stale-p shall decide to return a proper value, even if
> the dired buffer is modified.

What Mark was trying to tell you is that dired-stale-p is not even
called when buffer-modified-p returns non-nil.  So what you suggest is
impossible without a thorough rewrite of the beginning of
auto-revert-handler.

My suggestion was intended to allow much less invasive changes in that
complicated logic.

> It will follow the same logic as you have proposed above. And we
> could implement different logic, depending whether default-directory
> is a remote file name.

Why is such a different logic a good idea?  If the user requests
auto-reverts in a remote directory, she should get what she asked for,
IMO.  It would be confusing to have different results depending on
whether the directory is local or not.

> auto-revert-handler shall not cease to work unconditionally, when
> buffer-modified-p is non-nil. This check shall be done only for buffers
> with a related file (buffer-file-name is non-nil). For all other
> buffers, <foo>-stale-p shall decide, whether buffer-modified-p must be
> taken into account.

Again, you are talking about inverting the current logic.  If you are
certain this won't produce unintended consequences, by all means go
ahead.  But I still don't understand why your suggestion is better
than mine.  You didn't point out any downsides in my suggestion.

Previous Next

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