[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#20943: 25.0.50; Dired buffers are not always auto-reverted
From: |
Eli Zaretskii |
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@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.
- bug#20943: 25.0.50; Dired buffers are not always auto-reverted, Mark Karpov, 2015/07/09
- bug#20943: 25.0.50; Dired buffers are not always auto-reverted, Eli Zaretskii, 2015/07/09
- bug#20943: 25.0.50; Dired buffers are not always auto-reverted, Mark Karpov, 2015/07/09
- bug#20943: 25.0.50; Dired buffers are not always auto-reverted, Michael Albinus, 2015/07/09
- bug#20943: 25.0.50; Dired buffers are not always auto-reverted, Mark Karpov, 2015/07/09
- bug#20943: 25.0.50; Dired buffers are not always auto-reverted, Eli Zaretskii, 2015/07/10
- bug#20943: 25.0.50; Dired buffers are not always auto-reverted, Michael Albinus, 2015/07/10
- bug#20943: 25.0.50; Dired buffers are not always auto-reverted,
Eli Zaretskii <=
- bug#20943: 25.0.50; Dired buffers are not always auto-reverted, Michael Albinus, 2015/07/10
- bug#20943: 25.0.50; Dired buffers are not always auto-reverted, Michael Albinus, 2015/07/16
- bug#20943: 25.0.50; Dired buffers are not always auto-reverted, Mark Karpov, 2015/07/17
- bug#20943: 25.0.50; Dired buffers are not always auto-reverted, Michael Albinus, 2015/07/18
- bug#20943: 25.0.50; Dired buffers are not always auto-reverted, Mark Karpov, 2015/07/18
- bug#20943: 25.0.50; Dired buffers are not always auto-reverted, Michael Albinus, 2015/07/14
- bug#20943: 25.0.50; Dired buffers are not always auto-reverted, Mark Karpov, 2015/07/09
- bug#20943: 25.0.50; Dired buffers are not always auto-reverted, Eli Zaretskii, 2015/07/10
- bug#20943: 25.0.50; Dired buffers are not always auto-reverted, Mark Karpov, 2015/07/10
- bug#20943: 25.0.50; Dired buffers are not always auto-reverted, Eli Zaretskii, 2015/07/10