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.
We previously did this for InfoPlist.vstrings files, but the changed extension was only a temporary workaround for not allowing multiple filters to run on a build input.
Previously we would download and archive the default bundles as part of ./configure and place the result in our source directory, this however both pollutes the source directory with generated files, but also had the ./configure step actually do a partial build, since we need to build the ‘bl’ executable to download bundles.
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.
To get scroll content behind title/toolbar we need to set NSWindowStyleMaskFullSizeContentView which appears to have been inferred with the old (deprecated) WebView.
This was done using search and replace. Presumably it should be done in Xcode so that it can adjust the xib for the new deployment target, otherwise what is the point of storing deployment version in the xib and provide it as a command line argument to the xib compiler as well (only to get a warning if the versions do not match)?
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.
Git will re-use the file, but with new content, so we do not want to remember caret position or similar.
Previously we recommended setting the git editor to ‘mate -wl1’ but disabling metadata is a better solution.
Inconveniencing all users with the “TextMate wants to access your contacts” dialog is not worth having the ability to contact users about their crash reports.
This was previously placed in the file browser’s action menu and thus probably overlooked by many, even though ⇧⌘A is a very useful key equivalent, since many commands work on the entire project when there is no selection in the file browser.
The Navigate menu now contains a mixture of items with prefixes "Jump to", "Go to" or none at all. The "Go to" prefix is especially inconsistent since we have already have a dedicate "Go" item in the Main menu bar. For consistency, change them to use the "Jump to" prefix.
The commit also renames the appropriate dialog boxes and updates some documentation to refer to the new names.
This is consistent with Next/Previous Bookmark shortcuts bound to F2/⇧F2.
The problem with ⌘> and ⌘< is that these keys are used to cycle through windows on some keyboard layouts.
Discussion at issue #1316.
