Support accessibility in text view - VoiceOver and Zoom

[dusek]

These commits enable visually impaired and blind users on OS X to use VoiceOver and Zoom in the text component of TextMate. Both commits contain a bit more detailed description of the changes.

I have a few points which might use some discussion:

• is [OakTextView setSelectionString] the right place to track selection changes? It feels this is not the place where the selection model is defined (it is I guess in document or editor objects), but just reflected. I had no problem to find the right place for tracking of text model changes (buffer callbacks), but no luck finding right place to track selection model changes. However, tracking selection in setSelectionString seems to work absolutely fine.
• the nsRangeForRange and rangeForNSRange methods could be optimized for O(log n) in similar way as basic_tree_t is (as noted in the code comment). These methods could also be used in the relevant NSTextInput methods instead of the manual code currently present there - if there is interest, I can make a follow-up commit to use them for that code as well.

Both patches (commits) are released as public domain by my employer, BRAILCOM,o.p.s.

[sorbits]

Awesome work, thanks!

Pulled as commit 224ee5f and commit 5369b7c. I made a few syntactic changes and also prepended a commit that factors out the NSRange/ng::range conversion methods (which are now also used by the NSTextInput support methods, as you suggested — I prepended it to make your commit smaller, thus less to review).

As for your considerations: setSelectionString: would be the proper place. While the selection model is at a lower level, for accessibility we don’t want to “go down there” as it could be changed without any visual rendering (e.g. macro, script (in the future), etc.).

Performance of converting between UTF-8 and UTF-16 is indeed bothersome, but I think as these conversions are only done “on user requests” there is probably no actual performance issues (user input is limited to 30-50 per second, and even with humongous documents, doing the UTF-8/16 calculations should be faster than 1/30th of a second). So at least for now, this should be fine.

[dusek]

Thanks for reviewing and pulling these in. You are right that the UTF-8/UTF-16 conversions are not an issue in practice - I tried it with VoiceOver and there were no performance issues on a bigger document - which happened to be OakTextView.mm itself :-)