I want to use the Listeners and the abstraction for different platforms in another project (vimmate). This patch allows to specify a directory to listen on. The user can choose whether to receive relative or absolute paths.
Additionally I refactored the listener specs to the extend that every platform-specific listener behaves similar to the others. I could only test the linux and polling version. The latter had to be patched to report moved and deleted files.
can specify directory to listen to, still defaulting to pwd
create shared examples all listeners should behave like
must not use touch on Linux
refactor Polling Listener to catch deleted and moved files
can disable relativation of paths
can give path and options to Listener.select_and_init
Wow awesome refactoring! Thanks.
Actually the Darwin specs doesn't pass on Mac OS X, besides attr_reader :callback is missing in /listeners/darwin, rb-fsevents didn't support deleted & moved files (like rb-fchange on Windows). Right now, Guard didn't have any usages of deleted & moved (support of these on Linux, shouldn't be there either) so I think we should completely remove it.
What do you think about that?
@rymai, @yannlugrin, @netzpirat what your thought about that?
actually I though about adding events to the mix, so not only you get the (absolute/relative) path of a changed file, but the type of the change (:modify, :delete, :create etc) also. Maybe you'll need these later?
Would be nice to have a ruby library with (almost) platform independent fs notifications
An agnostic FS events listener gem seems interesting indeed! And you've almost done it already with these commits. Moreover, for the moment deleted & moved events are not detected in Guard so that's one more reason to externalize this "listener" functionality into an external gem, in which all events could be detected and Guard could choose to listen only "modified" events (at the beginning, maybe later it'll be useful to detect other events)...
There is already the fssm gem that is doing that (but without Windows support). If we add deleted & moved event, I'm little bit concerned about performance. That's why I have keep a more "keep it simple" approach in Guard without using fssm. @niklas did you known about fssm?
@thibaudgg I did not now fssm. And I looked for it for a while... Will have a look into it and will see if I can merge it with this code here.
I'd rather stab myself in the face than work with a windows box long enough to add support (to FSSM), even though that was one of the original goals... Just helping people out when they see bugs via polling is painful enough. Did you know that the pathname code returns entirely different values in cygwin than one would receive using the one-click installer? So that simply checking if you're running on windows isn't enough to determine whether you're dealing with windows style paths?
Merged & removed moved/deleted files support. Thanks for your work!