We only run uniqueSpellDocumentTag and closeSpellDocumentWithTag: on the main thread, as the spelling methods themselves should be thread safe and do not cause any tests to fail (even when running them in parallel).
The way we check if we must “jump” to main thread is done by looking at our current run loop rather than using the deprecated (as of 10.9) dispatch_get_current_queue() function. Since we are looking at the run loop, we now use CFRunLoopPerformBlock() instead of the dispatch functions.
This is significantly faster on OS X 10.11.
The API is slightly different so this is probably still faster in macOS 10.12 where there should be less of a performance difference between using Foundation and CoreFoundation.
This partially reverts changes of 3fdc72b93a:
Support spell checking being “automatic by language”.
Before 3fdc72b spellingLanguage .tm_properties setting (default "en") was the
only way to set spelling language for file (buffer). English was default
language for all files. 3fdc72b introduced change that when “automatic by
language” was selected in system's spelling panel then TextMate was ignoring
spellingLanguage setting and was using automatic by language.
However because “automatic by language” is default on OS X, effectively 3fdc72b
makes spellingLanguage setting no longer effective. To make it work one needs
to set explicit spelling language either in System Preferences or in spelling
panel upon each TextMate run (since this is getting reset after application
restart) - which is counter-intuitive, can be treated as regression and it is
vaguely described in ChangeLog:
* Support spell checking being “automatic by language”. This is set via the
spelling panel.
This change presents alternative approach, introducing new empty
spellingLanguage setting "" (which is now default), which makes use system
panel language setting, including “automatic by language”.
From now on all files will be checked against system panel selected language
(or automatic), unless .tm_properties project specifies explicitly language for
given file using, eg.:
[ locale-en_US.ini ]
spellingLanguage = en_US
[ locale-pl_PL.ini ]
spellingLanguage = pl_PL
Or automatically depending on file name:
[ locale-*.ini ]
spellingLanguage = '${TM_FILEPATH/^.*locale-([a-z]+_[A-Z]+).*$/$1/}'
The SDK for 10.11 (Xcode 7 GM and Xcode 7.1 beta) declares this enum using CF_ENUM instead of CF_OPTIONS, which forces us to explicitly cast back to the typedef type. <rdar://22743357>
Hopefully, we can revert this after OS 10.11 is officially released.
This must be set in the spelling panel and changing language via the spelling panel does not update the buffer (recheck the text with the new spelling language), so toggle automatic spelling after using the spelling panel to change language.
Closes#1139
If control (⌃) is down and the system gives us a non-ASCII key string then we will disregard it and instead convert the virtual key code to its ANSI character.
This will convert the event string to the proper glyphs and lookup function key glyphs in the font and set the proper glyph info attributes (if found).
The first time we ask for the shared spell checker it does some setup involving AppKit (creating the shared spelling panel?). While we already ensure that the spell checker is only called from the main queue, it seems this setup code must run on thread 0, which, when we are not in a Cocoa application, is not necessarily the thread used for the main queue.
I have been told that the spell checker should be thread safe (except for the spelling panel) but after moving to concurrent execution of the integration tests, several segmentation faults have pointed toward the spell checker not being thread safe.
We now explicitly disable it for targets that hasn’t yet been upgraded to ARC. This way, it’s easier to get an overview of which targets hasn’t yet been upgraded and ensures new targets has ARC enabled.
There are several crashes reported from firstRectForCharacterRange: which indicate that the system may ask for indexes “out of range”, hence why we now effectively just cap such request.
This means pressing e.g. ⌘/ (using the slash on the numeric keypad) will still work to toggle comments.
It also means that we can no longer bind specifically to the numeric keypad keys, but I don’t think anyone actually does that (given that few have numeric keypads).
The ideal solution would be to first do a literal check and then, if there was no match and the key event had the numeric keypad flag set, do a test with this flag removed, but that would change the simple string compare we presently use plus the easy caching and binary search of finding the item that matches a key event, i.e. it would add complexity to the code with no known argument in favor of this flexibility.
