> > Date: Sat, 12 Sep 2009 18:36:47 +0200
> > From: Antoine Levitt <antoine.levitt@gmail.com>
> > Cc: lennart.borgman@gmail.com, joakim@verona.se, emacs-devel@gnu.org
> >
> > If possible, polling should be avoided, though.
>
> Why?
Well, I don't know much about file systems, but isn't it always better
to be notified than to poll ? First, having a notification system
means it's instantaneous. Second, I'd imagine querying the state of a
file has a cost (especially if it can't be cached and needs a real
access to the hard drive). Third, it'd avoid a waste of CPU resources
(which may be important for power consumption, since, from what I
understood, the more a program has fixed timers, the more it wakes the
CPU from sleep). Fourth, being notified is more high-level, since the
notification itself can be implemented by polling. One could imagine a
notification API where the backend would use inotify if available,
polling if not.
> But it could also be a pain in the neck to have these changes occur
> while you're moving around in the Dired buffer and making changes.
Agreed. Maybe couple it with a condition like "the user hasn't done
anything to the buffer for n seconds" ?
I also agree that notification for files shouldn't be turned on by
default. When dealing with files that are modified in more than one
place at the same time, the simpler and safer the default is, the
better. It would be interesting to provide the feature for advanced users though (ie users who know what they want). In any case, an inotify API could be a nice basis for customisation/other modes (kinda like the dbus interface)