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.
