Re: [PATCH] Added inotify support.

[Eli Zaretskii]

> From: Rüdiger Sonderfeld <address@hidden>
> Date: Mon, 01 Oct 2012 16:09:55 +0200
> Cc: Leo <address@hidden>, address@hidden
> 
> On Monday 01 October 2012 00:38:09 Stefan Monnier wrote:
> > If there's a good chance this won't work without breaking compatibility,
> > maybe a better option is to provide a low-level API that maps very
> > closely to inotify and then an Elisp layer on top which abstracts away
> > differences between different systems.  In that case we can install the
> > inotify support right away while we're still experimenting with the
> > higher-level abstraction.
> 
> That's probably the best approach here.  I changed the patch to provide a low
> level inotify interface.  However I did not provide an inotify_init(2) like 
> function and instead initialization and closing of the inotify handle is done
> internally.  I don't think that this should be exposed to elisp even in the 
> low level interface.
> 
> > But if they're unlikely to be important in practice, then
> > I guess the current solution might be acceptable.
> 
> I think we are safe.  I added that `equal' should be used to compare cookies. 
>  
> So we can easily change it without breaking the API.
> 
> > I think the cleaner option is to define a new object type for it.
> > It could be either a new Lisp_Misc type, so you can make them print as
> > something like "#<file-watcher NNN>" (take a look at "enum
> > Lisp_Misc_Type" and "union Lisp_Misc" in src/lisp.h for starters; adding
> > a new type will require adding corresponding branches to the switch
> > statements in alloc.c and in print.c).
> 
> That sounds like the best option.  I haven't implemented it yet.  Is it 
> possible to make the Lisp_Misc_Type comparable with `equal'? Because the 
> watch-descriptor has to be comparable.

Any news on this?  The corresponding w32 implementation collects dust
in my local branch, waiting for the inotify based implementation to be
committed.