Hey !

Below is a second version of the previous patch.  It is somewhat
conservative, since neither did I attempt to

+ further simplify filenotify.el nor

+ handle differing masks in inotify.c .

--

I also thought about the test-cases and more generally about how to
develop a specification for this library, i.e. how do we want this to
behave.  Do we have the desire that it works uniformly across all
participating back-ends ? And is that even possible ?

I think it is to easy to adapt the tests for each back-end, until they
succeed and thereby potentially masking actual bugs.

One way to go about this would be to write a series of definitive
unit-tests which specify the intended behavior. Then, allow them to fail
for a specific back-end, until someone has fixed potential bugs for it
and confirmed that the test succeeds.  This would allow for an
incremental improvement on fairly solid grounds.  I'm assuming that
people of the future are interested in improving their used back-end
(e.g. make kqueue watch directories properly, if that is possible).

Anyway, I was bored today, so I took a look at what events these
libraries actually produce, the result of which you may also find below.

Finally, I'm tempted to suggest to get rid of the flags argument of
file-notify-add-watch.  As it is, things are already complicated enough
and we don't seem to have many people working on this.  I think we could
make it backward-compatible to a certain degree.  Note also, that many
file operations trigger both kinds of events anyway.

--