Previously when multiple windows had unsaved changes we would use the frontmost window (with unsaved changes) for all the dialogs. Now we always bring to front the document for which we are presenting a sheet (like a save panel or encoding error).
Our previous save code was incompatible with the app termination event loop, so we had to abort app termination, but the updated code does not seem to have any issue.
With this change we only have OakTextView observe its current document.
This does mean that currently pre and post bundle actions are only executed for the selected document.
We would only set the “default” project directory and rely on the effective project directory being set when opening first document, however, for untitled documents we need the effective project directory to be setup prior to opening (to read the correct settings).
We would previously use the documentPath property which does mirror the selected document’s path, but this will change to the logical path. Though for external scope attributes (such as which SCM or build system is used, only the real path makes sense).
A document has both a virtual and an actual path. The virtual path is relevant e.g. when opening files via rmate, where we want to lookup file-type specific settings based on the remote path (filename) rather than the local temporary file. However, if there is no virtual path, we should fallback on the actual path, which broke when we made document_t a wrapper for OakDocument.
There is now a new logical_path getter which return the virtual path and fallback on the actual path.
Closestextmate/bugs#21
This can be disabled using:
defaults write com.macromates.TextMate.preview disableBundleSuggestions -bool YES
Though the user can also hold option and select “Never” for a suggestions to never see that again, and once the user has a custom binding for a document’s type, no suggestion will be shown.
If OakDocument itself is unable to find one we look at the fileType .tm_properties setting, either looking it up using ‘attr.untitled’ for untitled documents, or ‘attr.file.unknown-type’ for documents with a path.
If nothing is found we fallback to ‘text.plain’.
When we close a tab then we select the tab to the left, for this reason it makes most sense to select the last tab added, so that ⌘W will effectively go to the “next tab inserted”.
The exception is when we create a new project, here we select the first tab since there are no tabs to the left, so ⌘W will still work as a “next tab” button. Though I may later change this so that the behavior is consistent.
I believe this used to be a requirement (presumably since a const reference can be treated as a pointer by Objective-C) but recent versions of clang have no problem with complex C++ data types in Objective-C class interfaces.
Without full keyboard access enabled (System Preferences → Keyboard) the text view in the Unknown Encoding dialog would be the initial first responder, and while it’s read-only, pressing return would make the text view give up focus, rather than send the key to the window’s default button.
Previously when providing a project UUID while opening a document, and no project used this UUID, TextMate would create a new project (with this UUID).
This was both a way to force a file to open in its own project, and to open multiple files in the same project, even though they did not share project folder.
The problem is that `mate` will read the `TM_PROJECT_UUID` environment variable and use as target project, which is generally desired, but incase we launch a new application from TextMate, and this application later opens a file via `mate`, it will use the old `TM_PROJECT_UUID` value, which might no longer exist.
We still allow forcing files to open in their own project by introducing a special “null UUID”, but with this change, it is no longer possible to use multiple invocations of `mate` to open unrelated files in the same project. Should this be desired, we can re-introduce this feature but require that `mate` is given the UUID via its -p/--project argument.
Fixestextmate/latex.tmbundle#150
When our application is activated and our key window is on a non-active desktop with windows on the active desktop, the system will give focus to one of the windows on the active desktop.
To workaround this we make our window key after our application has become active.
It used to be that if we called unhideWithoutActivation followed by makeKeyAndOrderFont:, and finally activateIgnoringOtherApps: then we would end with only the key window on top of other windows in the desktop space.
E.g. from a terminal (with TextMate hidden) using “mate -w” would cause only a single window to open on top of the terminal window, which seemed like desired behavior.
Unfortunately Apple have changed the behavior so there is no need to explicitly call unhideWithoutActivation as this is implied by activateIgnoringOtherApps:.
Some targets were including headers from frameworks not specified in their link dependencies. For a clean build this could cause an issue because the header was not available at the time of building the target.
The updated link dependencies are also based on what a target’s tests require. Ideally tests would have separate link dependencies, but as we don’t want to maintain this manually, this will have to wait until the build system automatically handles link dependencies.
Currently the commit command uses constants from the CommitWindow framework but should actually not be linked with it. However, the optimizer will strip dead code, so it should not result in much if any difference in the resulting binary and does solve a build dependency issue.
