This is because we rely on `-X` (skip extended attributes / resource forks) which is only available with Apple’s version of `cp`, and it is not unlikely that the user has GNU’s version of `cp` available via PATH.
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).
This is to avoid redundancy as ninja_required_version is hardcoded in the generator script and builddir is already passed via the --build-directory/-C option (and explicitly exported as a variable in the generator script).
There may be situations in which the user already have (generated) ninja build files which do not match our assertions.
This reverts commit b42cbb1f7e.
The C++20 feature list has been frozen although clang (and libc++) doesn’t yet have full support and the clang option we are using is -std=c++2a to indicate that things may still change.
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.
This seems like a logical separation, as the build directory now contains things 100% generated, whereas the “local” build file has variables that came from the original ./configure step and may be edited.
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.
