From: Eli Zaretskii <eliz@gnu.org>
To: Michael Albinus <michael.albinus@gmx.de>
Cc: emacs-devel@gnu.org
Subject: Re: File watch support in autorevert.el
Date: Fri, 11 Jan 2013 12:05:51 +0200 [thread overview]
Message-ID: <83fw28uj9c.fsf@gnu.org> (raw)
In-Reply-To: <878v819kok.fsf@gmx.de>
> From: Michael Albinus <michael.albinus@gmx.de>
> Date: Thu, 10 Jan 2013 15:28:27 +0100
>
> As a proof of concept, I have installed a patch in autorevert.el
> implementing file watches. This shall work for `auto-revert-mode' and
> `global-auto-revert-mode' for buffers visiting files.
> `auto-revert-tail-mode' is not supported (yet).
Thanks.
> The implementation uses `inotify-*-watch' functions. I have also added
> the calls for `w32-*-watch' functions, but this is untested.
The functions' names are w32notify-*-watch. I fixed that in the trunk
revision 111482. I also did some simple testing, and it seems to
generally work (but see the problems described below).
> Any feedback is welcome.
My feedback is as follows:
. The code as written is too naive: it blindly assumes that every
single notification reported by the filesystem for a given watch is
necessarily the one requested in the auto-revert-notify-add-watch
call. But that assumption is false, at least on Windows, where the
implementation actually watches events to the entire parent
directory of the file we are interested in. So Emacs reverts the
file whenever _any_ file in the same directory was changed. I
believe similar problems can happen with inotify, albeit much more
rarely. For that reason, I think auto-revert-notify-handler should
filter events by ASPECTS/ACTION member, and on Windows also by FILE
member of the event.
. It isn't clear to me that using IN_CLOSE_WRITE with inotify is TRT:
AFAIU, that would mean we only revert a file when the application
writing to it closes its descriptor. IOW, if the application makes
several changes to the file during a prolonged operation, and
doesn't close and reopen the file in between, we will only see the
changes at the end, but not during the operation. Wouldn't it be
better to use IN_MODIFY instead?
. At least on Windows, turning on auto-revert-mode and then modifying
and saving the file announces that it was auto-reverted. This
didn't happen with the auto-revert method that doesn't use file
notifications. Is this a bug?
. I believe some of the features added to autorevert.el, such as a
hash list of watch descriptors, should be in some infrastructure
with appropriate APIs.
next prev parent reply other threads:[~2013-01-11 10:05 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-10 14:28 File watch support in autorevert.el Michael Albinus
2013-01-10 17:11 ` Stefan Monnier
2013-01-10 17:14 ` Lennart Borgman
2013-01-10 20:38 ` Michael Albinus
2013-01-11 10:05 ` Eli Zaretskii [this message]
2013-01-11 14:34 ` Stefan Monnier
2013-01-11 14:43 ` Eli Zaretskii
2013-01-11 15:01 ` Michael Albinus
2013-01-11 15:50 ` Eli Zaretskii
2013-01-11 16:09 ` Michael Albinus
2013-01-11 19:19 ` Eli Zaretskii
2013-01-11 16:19 ` Michael Albinus
2013-01-11 16:39 ` Stefan Monnier
2013-01-11 22:43 ` Michael Albinus
2013-01-12 11:28 ` Eli Zaretskii
2013-01-12 13:34 ` Michael Albinus
2013-01-12 15:09 ` Eli Zaretskii
2013-01-12 19:08 ` Michael Albinus
2013-01-17 9:38 ` Michael Albinus
2013-01-17 16:54 ` Eli Zaretskii
2013-01-17 19:19 ` Michael Albinus
2013-01-17 19:39 ` Eli Zaretskii
2013-01-11 15:57 ` Stefan Monnier
2013-01-11 15:18 ` Michael Albinus
2013-01-11 15:57 ` Eli Zaretskii
2013-01-11 16:31 ` Michael Albinus
2013-01-11 18:47 ` Eli Zaretskii
2013-01-11 16:44 ` Stefan Monnier
2013-01-11 22:47 ` Michael Albinus
2013-01-12 11:36 ` Eli Zaretskii
2013-01-12 13:14 ` Michael Albinus
2013-01-12 14:06 ` Eli Zaretskii
2013-01-12 14:16 ` Michael Albinus
2013-01-11 22:39 ` Michael Albinus
2013-01-11 23:01 ` Michael Albinus
2013-01-12 11:31 ` Eli Zaretskii
2013-01-12 13:08 ` Michael Albinus
2013-01-12 13:26 ` Michael Albinus
2013-01-12 14:03 ` Eli Zaretskii
2013-01-12 14:12 ` Michael Albinus
2013-01-12 14:39 ` Eli Zaretskii
2013-01-12 19:04 ` Michael Albinus
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=83fw28uj9c.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=michael.albinus@gmx.de \
/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).