Since this is internal API it should not be necessary to sanitize the range, but based on textmate/bugs#34 it is causing a lot of crashes on macOS 10.15.
Previously we used the system’s temporary directory and removed the script after use.
This is because macOS 10.15 will “call home” (notarization?) when executing a new script (that it has not seen before), so with an unstable network connection, running commands could take several seconds.
Apparently the window’s delegate is not used for context menu actions in full screen mode, although NSApp’s targetForAction: does find the receiver, so this appears to be a framework bug.
The specific issue being addressed is macOS 10.15 where the mount point for ~/Library/Application Support is under /System/Volumes/Data so our assertion that the relative path received in our callback can be appended to the mount point, to match the path being observed, is false.
As a workaround we call realpath() on the path we wish to observe, observe that path, and in our callback we calculate the relative path from the real observed path, and append that to the requested path.
In theory the caller could be made responsible for expanding paths to their real path, but the current abstraction allows observing non-existing paths, which is why it needs to handle this path rewriting.
If one event cycle triggered multiple re-layouts, we could end up reusing a tab bar view that had been removed from its superview because the weak pointer had not yet been cleared (as the view hadn’t yet been fully released).
This could happen during window construction in a scenario like this:
1. Window gets created at some size, tab bar views are created
2. Window size gets restored causing some tab bar views to be removed
3. Active tab gets restored bringing an overflow tab into the visible area, re-using a removed view
We don’t yet rely on any 10.12 specific API other than os_log which can be skipped without user impact.
Unfortunately when trying to build for 10.10 using latest Xcode/SDK the linker gives an error for missing symbol: _objc_loadClassref.
Going forward we will require 10.12 but as there is no non-beta build for 10.11 users yet, I wanted to make one.
The issue appears to be that accessing the clipboard, as part of setting up a normal document window, will stall when trying to connect to the system’s clipboard server.
Here’s the relevant stack trace:
-[OakPasteboard checkForExternalPasteboardChanges]
-[NSPasteboard stringForType:]
-[NSPasteboard _dataForType:securityScoped:]
-[NSPasteboard _dataForType:index:usesPboardTypes:combinesItems:securityScoped:]
-[NSPasteboard _dataWithoutConversionForTypeIdentifier:securityScoped:]
CFPasteboardCopyData (in CoreFoundation)
___onqueue_CFPasteboardRequestDataFromDaemon_block_invoke.341
usleep (in libsystem_c.dylib)
nanosleep (in libsystem_c.dylib)
__semwait_signal (in libsystem_kernel.dylib)
For example if we have a directory with files named 001-foo.txt, 002-bar.txt, and 003-fud.txt, duplicating one of these will result in the duplicate starting with 004.
Also improve support for finding dates in file names being duplicated. Previously we only looked for YYYY-MM-DD but now we also support YYYY_MM_DD and YYYYMMDD. If a date is found in the file name being duplicated, it is replaced with the current date in the duplicate.
The issue is that the types requested may be ‘NSStringPboardType’ but that symbol is deprecated (starting with 10.14), yet the replacement (‘NSPasteboardTypeString’) is not string-equivalent, therefore our simple string comparison would fail.
This effectively broke services starting with 1ef78b3af7 (where we adopted the new symbols).
Implementation of validRequestorForSendType:returnType: does not appear to be a problem, as that method is called with both ‘NSStringPboardType’ and ‘NSPasteboardTypeString’.
Also switched to using NSPasteboard’s writeObjects: so we don’t have to explicitly deal with the type of the data we write to the pasteboard (presumably NSString will declare it using both the old and new type).
I cannot find any information online about Apple dropping support for this, but I also cannot make it work, and it wouldn’t surprise me if they view localized folder names as a security problem.
The Find dialog was already using number formatters, but the tool tips shown in the text view (when doing searches or replacements without going through the find dialog) were not.
This makes a difference when the count is > 999, as it will then format the number with thousand separators.
This was unnecessary indirection as we don’t generally lookup strings for the UI (so TextMate is not actually localizable) and the catalog for the strings we did look up was actually out of date.
The use of an animator proxy is causing the initialize method to be called during animation, and when registering user defaults in initialize, we may trigger key/value observers to be notified, which for this code can result in a crash in OS code with the message: “Trying to recursively lock an os_unfair_lock”.
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)
