emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Using glib's g_file_monitor_file and g_file_monitor_directory


From: Michael Albinus
Subject: Re: Using glib's g_file_monitor_file and g_file_monitor_directory
Date: Tue, 28 May 2013 12:39:15 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)

Stefan Monnier <address@hidden> writes:

>>> What about adding this interface to Emacs, on C level? It could be in
>>> parallel to, or replacing the inotify interface.
>
> That sounds good.  AFAIK Emacs almost always links to glib indirectly
> nowadays, so it would probably be OK to replace the inotify version with
> the glib version.

I've appended a patch which I have tested successfully under GNU/Linux.
There is a new gfilenotify.c, which uses glib's functionality. There is
also a new config option --with-file-notification=LIB, LIB can be "yes",
"no", "gfile" or "inotify". Default on non-w32 machines is "gfile" if
applicable. For w32 machines, this option is not taken into account yet,
emacs undonditionally links w32notify (maybe we want also support "no"
there?).

Furthermore, all file notification libraries use now the same lisp event
`file-notify' instead of `file-inotify' and `file-w32notify'.

Changelog entries and proper documentation are not part of this patch yet.

Comments on the patch are welcome. And we should also start to design an
upper layer over gfilenotify.c, inotify.c and w32notify.c, which
abstracts from the respective file notification events. They are very
different for every library, which complicates a convenient use in other
elisp packages. See the changes in autorevert.el in that patch.

>         Stefan

Best regards, Michael.

Attachment: bzr.diff
Description: Text Data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]