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.
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)
This is to provide more flexibility when providing the private key.
It would be preferably to allow setting the shell (globally) but such feature was not desired by the maintainer of ninja: https://github.com/ninja-build/ninja/pull/827
Using background-size: 50% results in really bad scrolling performance and
doesn't not achieve the effect of scaling the image to double the pixel density,
it rather sets the image width to 50% of the element.
Using the non-retina image size solves both the problems.
A similar issue was found in this SO page: https://stackoverflow.com/a/7034772
Trying to save a file as /path/to/symlink will fail with “file does not exist” using the new NSFileManager API, even when the symbolic link does point to an existing file.
I’m keeping it in the sources though as it provides semantic value and may be required if the build system is updated, e.g. we may want to create static libraries for some targets and would thus need to know which symbols to export.
This is done by setting `atomicSave` to one of the following values:
always Always use atomic saving (default)
externalVolumes Use for non-internal volumes (e.g. USB drives)
remoteVolumes Use for non-local volumes (e.g. network mounts)
never Never use atomic saving
legacy Always enabled, but do not use NSFileManager
Setting it to `externalVolumes` also includes `remoteVolumes`.
NSFileManager’s approach is inferior to exchangedata(), but as this feature is no longer supported with Apple’s default file system (APFS), there is little reason to maintain our own implementation of the fallback code required when we cannot use exchangedata(), especially as the OS know more about file references (aliases), metadata, and other stuff that should be preserved when writing a new (replacement) file.
In theory the NSFileManager strategy can fail to create the temporary destination, in which case we will pass NULL to open() and crash.
Will fix this in a later commit.
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 intermediate_t type now wraps the actual saving strategy to make it easier to change strategy based on the destination file system, user preferences, or other factors.
When searching for a regular expression with captures, we have $1-n available in the replacement (format) string.
If this format string does further replacements with optional captures (e.g. /^(_)?foo/) then $1 would be inherited from the parent match, when the optional capture did not match anything.
This bug was introduced in 0b1496011f.
