From: Mark Karpov <markkarpov@openmailbox.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 20943@debbugs.gnu.org
Subject: bug#20943: 25.0.50; Dired buffers are not always auto-reverted
Date: Thu, 09 Jul 2015 21:30:10 +0600 [thread overview]
Message-ID: <874mldtkl9.fsf@openmailbox.org> (raw)
In-Reply-To: <83615tv14o.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 09 Jul 2015 17:47:35 +0300")
> We need to come up with a way of telling auto-revert that although the
> buffer was modified by the commands you mentioned, it's okay to revert
> it. Can you suggest a change along those lines?
I propose two changes:
1. In ‘auto-revert-handler’, autorevert modified files if current buffer
is a Dired buffer:
(defun auto-revert-handler ()
"Revert current buffer, if appropriate.
This is an internal function used by Auto-Revert Mode."
(when (or auto-revert-tail-mode
(eq major-mode dired-mode)
(not (buffer-modified-p)))
...))
This removes «freezing» of modified buffers (‘auto-revert-buffer’ is
only called when auto-revert mode is enabled right? this should not
affect users who don't use auto-revert). This is what I currently
use. Control flow goes into body of ‘when’ and for Dired buffers this
boils down to conditions that check if current buffer is stale, and if
it is, then the function revert it.
2. To eliminate adverse effects (reordering of files because of
auto-revert mode), we need to write down all functions (commands) that
can insert new elements out of order in Dired buffer, then at the end of
every such a command, add:
(when auto-revert-mode
(revert-buffer nil t t)) ;; not sure about the collection of args
This should be done only for Dired-specific commands (that are used only
in Dired mode, if there is uncertainty, add additional condition to test
that current major mode is ‘dired-mode’), of course.
In principle, a macro can be written for this set of functions, but I
don't think it's a good idea for Elisp, given such limited use case.
The only thing I cannot do myself from this is form full list of
functions that should call ‘revert-buffer’ when ‘auto-revert-mode’ is
enabled. You should be able to do it better than me.
These functions should contain reverting code in themselves because
‘auto-revert-handler’ cannot help here — its period is too long.
Maybe I don't see some corner cases? If you disagree with this plan,
let's discuss it.
next prev parent reply other threads:[~2015-07-09 15:30 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 [this message]
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
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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=874mldtkl9.fsf@openmailbox.org \
--to=markkarpov@openmailbox.org \
--cc=20943@debbugs.gnu.org \
--cc=eliz@gnu.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 public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).