The prior version worked fine for the typical single insertion/removal
cases. But when larger imbalances happened due to bulk insertion or
removal it wouldn't work correctly.
The new improved version works on any tree whose children are themselves
balanced, even if they are extremely different heights when compared to
each other. It works in O(log N) time.
It doesn't use an intermediate conversion to a string anymore, and should
execute in O(log N) as long as the right-hand rope is equal length or
smaller than the left.
It may also be O(log N) for the left-hand rope being smaller, but that
depends on whether the rebalance code executes in O(log N) time when
the left and right hand side are individually balanced. I haven't
analysed it yet, so dunno.
The rope uses a large leaf-node text length, so in the vast majority of
cases this ends up being the same as directly storing the string data.
But in the case that the line becomes extremely long, this will allow
for reasonable performance