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`.
Apple writes the encoding charset (e.g., com.apple.TextEncoding) in
all lowercase (at least since macOS 10.9); however, TextMate assumes that the
encoding will always be uppercase. So in order to avoid any issues with case
mismatches, when setting the charset, uppercase the given string.
See http://lists.macromates.com/textmate/2018-April/040602.html
Previously this database was loaded each time a file of unknown encoding was read, which could add a significant overhead when using “find in folder” with a large database and many files with unknown encoding.
Since creating new untitled documents go through the same “open” code they would have their newlines set to LF, this is no longer the case, so the global (or targeted) lineEndings setting now decide what to use (when saving the document).
Currently creating an untitled document from a buffer (e.g. `echo foo|mate`) will do newline detection and thus will ignore user settings during save, if the buffer had any newlines during initialization.
This may or may not be desired. Probably it should do newline detection when the data is provided by the user, but not when it is based on “internal” data, for example a command with “New Document” as output location.
We now check if an installed bundle has an extension that match the path, and if it is longer than the simple extension, we use the one from the bundle.
This would be relevant for file paths like ‘.git/config’, ‘CMakeLists.txt’, and ‘foo_spec.rb’.
This is similar to commit 26e66b887a but this change affects reading files.
If we have a command that runs on `callback.document.did-save` and that command writes to another (open) document, TextMate would hang as the save completion handler is indirectly invoked by `dispatch_async(dispatch_get_main_queue(), …)` so the main queue is blocked throughout the execution of the completion handler, and this completion handler may run commands (`callback.document.did-save`) which means it runs a local event loop, and thus while running this event loop, a new event can arrive which tells TextMate that files have changed (and should be reloaded).
While the previous changes were motivated by the tests, this one affects TextMate in that we run a local event loop if we want to wait for commands to finish, but as we previously used the main dispatch queue to send back command results, it meant that we could not wait for command completion from a block running in the main queue.
Currently the code works around this by using performSelector:withObject:afterDelay: when there is a chance of being in a local event loop, which is no longer required.
Some targets were including headers from frameworks not specified in their link dependencies. For a clean build this could cause an issue because the header was not available at the time of building the target.
The updated link dependencies are also based on what a target’s tests require. Ideally tests would have separate link dependencies, but as we don’t want to maintain this manually, this will have to wait until the build system automatically handles link dependencies.
Currently the commit command uses constants from the CommitWindow framework but should actually not be linked with it. However, the optimizer will strip dead code, so it should not result in much if any difference in the resulting binary and does solve a build dependency issue.
The problem is if the user sets a certain file type to open with grammar X and then uninstalls X, there will still be a setting binding the file type to X which means we skip trying to find another suitable grammar.
The problem is that during quit the OS will run a local event loop until we reply to the terminate event. In this local event loop we cannot use performSelector:withObject:afterDelay: but that is required to not block the main dispatch queue.
