Rewatch files on change event

[TrevorBurnham]

See discussion at #1853. Somehow, at least one application (the TextMate 2 alpha) is saving files in such a way that a single change event is emitted—and then the file no longer emits events, as if it had been deleted. My hunch is that the change event is somehow shadowing a rename event.

It's unclear whose bug this really is. Maybe it's something that can be fixed in fs.watch? Or maybe TM2 is doing something it shouldn't do? But we can work around it by re-watching files on every change, just as we re-watch them on every rename. With this patch, coffee --watch treats all file events as synonymous, hopefully giving us more consistent behavior.

[TrevorBurnham]

Uhh, not sure why all those extra commits got added to this pull req... only the last two are relevant. Sigh.

[jashkenas]

I think you got this pull request mixed up with some other changes?

[TrevorBurnham]

It's a very small change; might be easier to do it manually on your end, Jeremy. It's just replacing

  if event is 'change'
    compile()
  else if event is 'rename'
    watcher.close()
    wait 250, ->
      compile()
      try
        watcher = fs.watch source, callback
      catch e
        watchErr e

with

  compile()
  wait 250, ->
    try
      watcher.close()
      watcher = fs.watch source, callback
    catch e
      watchErr e

[jashkenas]

Don't you need to wait before the recompile, on renames?

[TrevorBurnham]

There's already a 25ms delay between compile being called and the fs.stat being run. That seems to be sufficient for Coda saves to work (the original motivation for adding the delay). Though that's on a fast system with an SSD and nothing else interacting with the drive.

Actually, a bigger concern is that when the fs.stat hits an ENOENT, removeSource is called; but if the file is then replaced and re-watched, the file isn't added back into sources. I'll keep working on this...

[TrevorBurnham]

Migrated to #1964.