This is useful when working with one set of files in a project, then moving to another set without closing the original set first.
Alternate menu items are pretty subtle, but there are already a lot of ways to close tabs, and I didn't want to clutter the menu further.
This provided value during early development, but has been unused for years, and it would generate too much noise if converted to os_log.
So better to just remove it all and add os_log statements as needed.
We either set it explicitly or rely on automatic key view loop calculations.
As for the latter: When auto-layout was initially introduced, the automatic key view loop calculation broke, as it used the view frames before layout. It should have been fixed several OS versions ago though, so we can use it again, as long as we are not working with view-based table views.
Several places already used ‘token’ as the name for the result from NSNotificationCenter’s addObserver:… so this change is to be consistent.
While ‘token’ is less meaningful than ‘observerId’, the variable is only used with NSNotificationCenter API where the context makes it clear.
This is not made clear from the documentation, however, the documentation does state that the token will be strongly held by the notification center, until the notification is removed, therefore it is safe to only keep a weak reference to the token (even if the implementation should change).
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 avoids the need to map between the two enumeration constants, although we handle some of the constants before passing them to the find singleton, so the code has not yet been updated to remove the redundant mappings.
The property is renamed from ‘currentResponderIsOakTextView’ to the more appropriate ‘keyWindowHasBackAndForwardActions’.
Furthermore, the menu items are found via indexOfItemWithTarget:andAction: instead of by title, although the title of the submenus for these menu items is still hardcoded.
The problem is that if shiftLeft:/shiftRight: exist after goBack:/goForward: in the responder chain, we would prefer the former. This can happen because main window is after the key window in the responder chain, so if the former contains an OakTextView, a potential responder in the key window would never be found.
This is motivated by having received several crash reports from CFSocketManager over the years, example crash log from TextMate 2.0.8:
Thread 5 Crashed:: com.apple.CFSocket.private
0 libsystem_kernel.dylib os_fault_with_payload + 10
1 libsystem_kernel.dylib __darwin_check_fd_set_overflow.cold.1 + 31
2 libsystem_kernel.dylib __darwin_check_fd_set_overflow + 79
3 com.apple.CoreFoundation __CFSocketManager + 939
4 libsystem_pthread.dylib _pthread_start + 148
5 libsystem_pthread.dylib thread_start + 15
Some users report a significant delay from executing mate until the TextMate window is brought to front.
The debug information can be extracted by running the following in a terminal:
log show --predicate 'subsystem = "com.macromates.TextMate" && category = "BringToFront"'
Alternatively use `stream` instead of `log` to get a live stream of debug output.
See `man log` for options such as `--start date/time` (to limit the query to e.g. the last 10 minutes)
