The watcher currently creates a timer and later runs whatever is specified. This can lead to multiple runs of the same file and other "strange" behavior.
To get around this, a better approach would be to separate the timer from the watcher and just have one timer that looks at a shared table of changes. It's clearly a much better design and avoids this "strange" behavior.
Another part of this might be to also (maybe) have a built-in notifier for just this. Or some similar functionality. That way we could populate the table with the mapped files rather than the changed files (which would completely eliminate these multiple runs of the same file).
The trick here is to avoid changing any api:s and/or make them needlessly complex. Needs some thought.
The watcher currently creates a timer and later runs whatever is specified. This can lead to multiple runs of the same file and other "strange" behavior.
To get around this, a better approach would be to separate the timer from the watcher and just have one timer that looks at a shared table of changes. It's clearly a much better design and avoids this "strange" behavior.
Another part of this might be to also (maybe) have a built-in notifier for just this. Or some similar functionality. That way we could populate the table with the mapped files rather than the changed files (which would completely eliminate these multiple runs of the same file).
The trick here is to avoid changing any api:s and/or make them needlessly complex. Needs some thought.