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.
It's possible that the path on the document is set even though it does not exist on disk. E.g., when using `mate` to create a new document from the command line.
This was done in an attempt to prevent the warning saying “This file is set to build for a version older than the project deployment target.”
Unfortunately saving all the xibs did not get rid of the warning, even though tehy are all set to have 10.7 as their build target.
The latest xib format does however remove about 10.000 lines of XML.
This could previously be done by creating a symbolic link and then selecting both the symbolic link and the original file, and selecting to open both at once.
Since the two tabs would have same identifier, the NSView for one of the two tabs could be left behind in the tab bar when manipulating the tabs.
For a project window where only some tabs are under version control, switching from one tab with version control info, to one without, would use the info from the previous tab with the new one (proxy icon badge and scope attributes).
The auto-calculated key view loop includes everything, which means dynamically added elements such as the close buttons for tab view items, but worse, the subviews of a view-based table view. So this change is required before switching to a view-based file browser.
Added a const reference to avoid the unnecessary copies when using `auto` in range-based for loops. One can find other instances in the code base where we could probably avoid making copies in similar situations, but I did not want to create the patch noise. The intention here is just to correct the obvious mistake and avoid repeating it in the future.
This was a problem for the saveOnBlur which takes a shortcut to saving, and previously wouldn’t save updated metadata.
This was a problem for folded text, as the old state of folded code was saved.
The problem is that cascadeTopLeftFromPoint: will change the window frame if the window frame is outside the visible screen rect.
It would appear that the way this API is supposed to be used is that new windows should be opened using the same frame as an existing, then cascadeTopLeftFromPoint: should be called on the new window, and the result should be passed to setFrameTopLeftPoint:.
Doing it like this would complicate our code because we currently want the window frame before opening the new window, and when finding the window frame, we check whether or not we should cascade to an existing window, so we would have to pass state around with the proposed new window frame (to indicate whether or not the window should be cascaded after opening it).
We set the attribute scopes `attr.scm.*` in two different places in DocumentController; however, we only export TM_SCM_NAME if the scm variables are present. So if `scmStatus` is not enabled, TM_SCM_NAME is never set or exported, but `attr.scm.*` can still be present.
It used to be that using activateIgnoringOtherApps: would bring all windows to front, which was the motivation for using SetFrontProcessWithOptions (supplying it with the kSetFrontProcessFrontWindowOnly option), but during testing (on 10.9) it appears that activateIgnoringOtherApps: brings only main/key window to front.
The reason we use the former is so that we can easily change our superclass to NSWindowController, though this will require 10.8 since we create weak references to our DocumentController objects.
Starting with 10.10 re-using a closed HTML output window is prone to crashing, either when opening the window with the WebView, or when later closing it.
The disadvantage of not re-using HTML output windows is only that we lose potential history, for example doing multiple documentation lookups, closing the window in between, would previously allow the user to go back in the history of words that had been looked up.
Zoom or minimize windows before ordering them front, and for the latter, don’t actually order them front (as that magnifies them). Also order front windows without also setting the window as key window.
