NSTextStorage -string inefficient

[Nicola Pero]

Hi - I implemented [NSTextView -transpose:] some days ago.  -transpose:
simply exchange the last two characters which were typed.  To exchange the
two characters, I have to read them, and that proved difficult.  The only
way to do it seems to call [_textStorage string] and then read the chars
from the string.  The problem is that [_textStorage string] is returning a
copy of the whole string!  So if I'm editing a 10 Mb text, the gui will
copy the 10 Mb string just to read two characters.  It's pretty
inefficient.

I was wondering why NSAttributedString didn't provide a -characterAtIndex:
method like NSString does, then I noticed that the documentation says that
NSAttributedString -string should take O(1) time.  That means it can't
copy the string, otherwise it would take O(N) time, where N is the string
length.  If -string actually took O(1) time, then calling -string and then
-characterAtIndex: on the string would actually be efficient enough.  It
would make a lot of sense, as you could access the string attributes
efficiently without having to duplicate the whole string interface in
NSAttributedString or subclasses.

So - I suggest that - either we fix GSTextStorage so that -string just
returns _textChars, adding prominent comments that it's not copied so
after calling it you should read the chars you need from it and discard it
immediately (or else make your own copy).  We might need to fix callers to
make a copy in places where a copy is needed.  (for example, I think we
want to change NSTextView -string to return a copy).

Otherwise, if we don't implement it in O(1) time but keep our very lossy
O(N), I suggest we add -characterAtIndex: and other NSStringish methods to
access characters efficiently from an NSTextStorage.  Even that might
normally be not as efficient, because if you access, say, 1000 chars,
calling string + 1000 * characterAtIndex: probably takes less than calling
1000 * (2 * characterAtIndex:) (because NSTextStorage -characterAtIndex:
will return [_textChars charactersAtIndex:] so each call to NSTextStorage
actually implies another call to the actual string).  While it might not
be particularly relevant for speed now, it might be very relevant for the
speed of the layout manager in the future, as the layout manager has to
read huge amount of chars from the text storage.  Currently, we copy the
whole textstorage string each time we need to do a layout, or, for the
glyph code, each time we want to read a char from it ... this last one is
obviously not very efficient.