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

Previous Next

Full log

Message #134 received at 20943 <at> debbugs.gnu.org (full text, mbox):

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

That's why I have proposed to remove the buffer-modified-p check from
auto-revert-handler. It shall be checked in <foo>-stale-p, if desired.

>> 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.

I haven't said that we must do this. But it would be possible.

>> 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.

Avoiding spaghetti code. The existing interface with <foo>-stale-p is
sufficient, I believe. Adding an additional interface (setting
buffer-local auto-revert-when-modified) would introduce another
interface, maybe in concurrency to <foo>-stale-p.

Best regards, Michael.

Previous Next

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