This worked previously because selected tab was stored using an index and we were only changing it (before reload) when closing tabs, so the new index would be valid both before and after reload.
With the new OakTabBarView the index of selected tab is instantly converted into a reference to a tab item.
This is for the “untitled save path” which is normally used for new untitled files, so we wouldn’t actually have a folder, however, the property is also used as a fallback for a “project folder” when that property is unset (which it generally shouldn’t be).
When opening a folder we test against the ‘projectPath’ property (on already open window controllers), but this is not setup until we have an open document, and documents are opened using a background queue, so code running in the same event loop cycle as the session restore, will not get the proper value for this property.
The problem this fixes is: open /path/to/foo and quit TextMate. Now drag /path/to/foo to TextMate’s app icon. TextMate would first restore session (which includes /path/to/foo) and then open /path/to/foo (not seeing the restored folder as being /path/to/foo due to the uninitialized ‘projectPath’ property).
Previously using ⌘F with a multiline selection would automatically set the “in”
pop-up to “Document”. This is no longer the case, but can be brought back by
running: `defaults write alwaysFindInDocument -bool YES`
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.
