bug#20943: 25.0.50; Dired buffers are not always auto-reverted

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: Mark Karpov <markkarpov@openmailbox.org>,  20943@debbugs.gnu.org
> Date: Fri, 10 Jul 2015 08:01:48 +0200
> 
> Eli Zaretskii <eliz@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.