The latter is added when we detect a ‘_config.yml’ file in the project. This might cause false positives, but I am not aware of a better way to detect jekyll projects.
This makes it easier to enable auto-saving when TextMate loses focus and unlike using a command for this, files that cannot be saved will be silently skipped (as the user is leaving TextMate, so we should not throw up dialogs).
The problem is that during quit the OS will run a local event loop until we reply to the terminate event. In this local event loop we cannot use performSelector:withObject:afterDelay: but that is required to not block the main dispatch queue.
For example the bundle item “Execute Line / Selection” will (without a selection) show as “Execute Line” in the menu, and now also if the command causes the error sheet to appear or the user press ⌃C / ⌘. to prematurely kill it.
This was previously necessary because we do threaded saving and relied on our run-loop source to be notified when saving completed, but as application termination (presumably) causes TextMate to run in a special run loop mode, we would not receive this notification.
After switching to dispatch queues there no longer is a problem (at least on OS X 10.9.2).
Closes#1030
This would happen for a command that is set to re-use previous output window (when busy). We would kill the running command and wait (in the main dispatch queue) for it to stop, but since the runner is (now) using GCD as well, and updating the “did exit” status in the main queue, we would wait forever.
The state being restored here would be file browser state, which might confuse the user if they are opening a folder via “mate” and then get a file browser restored for that project folder that show another location than the actual folder they open.
The reason we ignore the state when loading, rather than not saving it in the first place, is that by saving the state we make the folder show up in File → Open Favorites…
Additionally, we only re-use a window when the command is the same as what was last associated with the window. So doing a documentation lookup and then building the project will not re-use the (non-busy) documentation window for the build progress.
Closes#733
This is only done for code where running it twice would actually cause a problem.
Dispatch_once is favored over a static boolean only because it seems to carry slightly more semantic information.
Presently this will also disable it if the folder is opened via the Recent Projects chooser. Ideally opening via this list should not disable folder state restoring.
