Issues with Macvim #4

sebv opened this Issue Nov 19, 2012 · 9 comments


None yet

4 participants

sebv commented Nov 19, 2012

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') {
shama commented Nov 19, 2012

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 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 commented Nov 20, 2012

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 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 commented Nov 20, 2012

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 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 then use it but if not at least will continue to function with fs.watchFile albeit slower.

Thanks for reporting btw.

sebv commented Nov 20, 2012

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.

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


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 commented Dec 10, 2012

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 commented Dec 11, 2012

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


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

shama commented Dec 14, 2012

@jgallen23 Thanks! Will use that as reference.

@shama shama closed this in 6ed645e Dec 14, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment