From: Michael Albinus <michael.albinus@gmx.de>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 20943@debbugs.gnu.org, markkarpov@openmailbox.org
Subject: bug#20943: 25.0.50; Dired buffers are not always auto-reverted
Date: Fri, 10 Jul 2015 10:46:50 +0200 [thread overview]
Message-ID: <87pp40z9fp.fsf@gmx.de> (raw)
In-Reply-To: <83lheobi8x.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 10 Jul 2015 10:10:22 +0300")
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.
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.
next prev parent reply other threads:[~2015-07-10 8:46 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-30 18:19 bug#20943: 25.0.50; Dired buffers are not always auto-reverterd Mark Karpov
2015-06-30 19:58 ` Eli Zaretskii
2015-07-01 5:58 ` Michael Albinus
2015-07-01 7:15 ` Mark Karpov
2015-07-01 8:55 ` Michael Albinus
2015-07-01 9:09 ` Mark Karpov
2015-07-01 15:38 ` Eli Zaretskii
2015-07-01 15:25 ` Eli Zaretskii
[not found] ` <87y4j0fj8m.fsf@openmailbox.org>
2015-07-01 15:24 ` Eli Zaretskii
2015-07-02 8:02 ` Mark Karpov
2015-07-02 14:52 ` Eli Zaretskii
2015-07-03 7:33 ` Mark Karpov
2015-07-03 8:18 ` Eli Zaretskii
2015-07-03 9:39 ` Mark Karpov
2015-07-03 12:10 ` Eli Zaretskii
2015-07-03 12:37 ` Mark Karpov
2015-07-03 13:02 ` Mark Karpov
2015-07-03 13:43 ` Eli Zaretskii
2015-07-03 13:49 ` Mark Karpov
2015-07-03 16:08 ` Mark Karpov
2015-07-04 8:31 ` Eli Zaretskii
2015-07-04 8:49 ` Mark Karpov
2015-07-04 9:20 ` Michael Albinus
2015-07-04 9:32 ` Eli Zaretskii
2015-07-04 14:35 ` Drew Adams
2015-07-04 14:33 ` Drew Adams
2015-07-01 7:23 ` Mark Karpov
2015-07-02 10:49 ` Mark Karpov
2015-07-09 13:24 ` bug#20943: 25.0.50; Dired buffers are not always auto-reverted Mark Karpov
2015-07-09 14:47 ` Eli Zaretskii
2015-07-09 15:30 ` Mark Karpov
2015-07-09 18:41 ` Michael Albinus
2015-07-09 19:42 ` Mark Karpov
2015-07-10 5:46 ` Eli Zaretskii
2015-07-10 6:01 ` Michael Albinus
2015-07-10 7:10 ` Eli Zaretskii
2015-07-10 8:46 ` Michael Albinus [this message]
2015-07-16 18:12 ` Michael Albinus
2015-07-17 20:40 ` Mark Karpov
2015-07-18 10:37 ` Michael Albinus
2015-07-18 18:20 ` Mark Karpov
2015-07-14 16:28 ` Michael Albinus
2015-07-09 19:50 ` Mark Karpov
2015-07-10 5:43 ` Eli Zaretskii
2015-07-10 6:20 ` Mark Karpov
2015-07-10 7:13 ` Eli Zaretskii
2015-07-10 7:46 ` Mark Karpov
2015-07-10 8:03 ` Eli Zaretskii
2015-07-09 15:40 ` Mark Karpov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87pp40z9fp.fsf@gmx.de \
--to=michael.albinus@gmx.de \
--cc=20943@debbugs.gnu.org \
--cc=eliz@gnu.org \
--cc=markkarpov@openmailbox.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.