Previously we would automatically pick up an Info.plist file copied using any of the CP_* keys, and both move it to the correct location (when belonging to target built) or ignore it, if we were copying it from an imported target.
To simplify the logic in the build system, it is however better to be explicit about this, also because we could actually want an Info.plist file among our copied files.
Theme is now stored only with OakTextView (observed by OakDocumentView) and the “global” setting is stored in user defaults (not Global.tmProperties), though it is still possible to override theme on a file-by-file basis via .tm_properties files.
The advantages are:
- More compatible with version control
- Easier to copy/paste menus and menu items between other projects
- Easier to setup menu delegates or obtain pointers to menu items
- We can use symbolic names when setting a menu item’s tag
- More transparent: We can read the declaration in a few minutes, use search, etc.
There are two disadvantage that I can think of:
1. We currently need to use private API to create the Open Recent submenu. Should this become a problem in a future macOS update, we can always create a single Open Recent menu in MainMenu.nib and use that when building our menu.
2. If you make a typo in the menu declaration then the compiler error will often just point to the first line of the declaration rather than the line with the incorrectly declared item. One can comment out sections to narrow it down, if many edits have been made since last compile.
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.
This allows the commit command line tool to open a window as “native”.
We use distributed objects for talking to TextMate and getting a response. For the response, we release the connection in the next iteration of the event loop and then gracefully exit the program. Though it’s not clear if this is enough time for distributed objects to reply the client (if not, an exception is thrown in the client about “connection disappeared while waiting for a reply”).
There is currently no way to add a TextMate (1.x) license to the key chain, but those who used TextMate r9147 or earlier should have one stored already.
Previously we installed this from the Bundle Support bundle’s support path.
While the Bundle Support bundle is a requirement to work with TextMate, including mate in the resources section should ensure we always get the latest build and address issue 53.
