Issues with Macvim #4

Closed
sebv opened this Issue Nov 19, 2012 · 9 comments

Projects

None yet

4 participants

@sebv
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
Owner
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 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
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 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
Owner
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 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
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.
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
Owner
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
Owner
shama commented Dec 11, 2012

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

@jgallen23

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

@shama
Owner
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