Issues with Macvim

[sebv]

Couple of things:

• After a few save Macvim only riggers rename events wich are ignored. (Or moves the file around rather than saving, so Gaze is loosing track of the file.)
• Small bug line 341

    if (_this.options.forceWatchMethod === false || _this.options.forceWatchMethod === 'old') {

• You should consider using this package to handle the low level file stuff: https://github.com/paulmillr/chokidar.git.

[shama]

Ha I originally used chokidar but it has it's own set of issues (unlink doesnt fire on osx, fires add events when just adding files to be watched/at start up, no tests, ignores folders, maintainer is busy). So I built gaze and fixed all those issues. Also chokidar matched too many files and we had to check if the file matched after the event... rather then before like gaze does. So It's more efficient having file matching built in.

I also considered https://github.com/medikoo/fs2 but it doesn't support node v0.6 (which neither does Grunt v0.4 now) and it was slower. It's still in development so I may reconsider it later. But for now, gaze must handle the low level stuff.

• What is the bug in L341?
• I'll check on renamed events. They should be supported in the lastest version of gaze.

[sebv]

Actually you already had a TODO note for L341 (And it was L339). Both method are setup when forceWatchMethod is false, which is a bit strange.

Try to test with macvim or (vim/vi). I'had this kind of fs.watch issues with derby.js and socketstream and it was only fixed when they moved to chokidar. I've started to wonder, if it is weird side effects of using encrypted drives.

I saw this nodejs/node-v0.x-archive#3343, hopefully should be better with node 0.9.

[shama]

I wonder if it is the same issue as this gruntjs/grunt-contrib-watch#13. What version of OSX are you running? I'm running on 10.6 atm but am going to try to upgrade soon to look into this.

I have gaze by default use both fs.watch and fs.watchFile and then whichever method responds first kills off the other. That is why they're both setup when false. I figured if you're system supports the faster fs.watch then use it but if not at least will continue to function with fs.watchFile albeit slower.

Thanks for reporting btw.

[sebv]

Am running the latest stable osx/node, but it is not OSX version dependent, I have been having this kind of issue for a long time, it's why I am wondering wether It has something to do with using encrypted drive, since some people don't have the issue at all while others do.

Am now trying to do a fix similar to coffeescript, this rewatch thing works.
https://github.com/jashkenas/coffee-script/blob/master/src/command.coffee#L177

Fix here, added a rewatch option to the new method. 754d47d

[jsoverson]

That rewatch fix works for me and is substantially faster than using forceWatchMethod : 'old'. It might be a workaround for gruntjs/grunt-contrib-watch#13.

@shama, do you want a PR from @sebv?

[shama]

I think I finally understand the real issue here to write a test case to duplicate. If @sebv wanted to open a PR it would be greatly appreciated!

[shama]

Here is a test to simulate a safe write event: 8f6c61e8d825d72730715d5c1b9ccfbfd092f038

[jgallen23]

This is how socketstream dealt with it: socketstream/socketstream@8785805

[shama]

@jgallen23 Thanks! Will use that as reference.