shifting the normalise_range() method onto a trait would allow it to more easily be applied to e.g. LeafNode, Index, etc.

it could be perhaps something like:

byte_index(char_index, offset = 0) -> byte_index | (char_index, offset)

the need for an enum to return could make it a little fiddly, though you could also just try each Run in sequence to get the eventual answer, as it can handle checking the char count against the char_index, calculating the final byte_index on a match, and decrement char_index and increment offset on a miss.

the enum aspect could be shifted to cover just the (str|l + r) part, allowing for heavier nodes with e.g. indexes and shit.

at minimum the 'length' field should probably be pulled out, as there is no real need to duplicate it and defer through etc. etc...

with that said, length itself may possibly be superceded by something from the new index module.

atm all Splittable are also ranged.

however, CharWidth & Newline (from index) are both able (and required) to be split(), but are unaware of their ending bounds.

could remove the Ranged parent from Splittable, and add in a new RangedSplittable (for example) which is essentially just Splittable with some assertions and such applied for error checking purposes?