2 ms·
> Do you end up having a system that basically just observes the state of the string (in code points) before and after a user operation occurs? You're describi
by josephg 4y ago
> Do you end up having a system that basically just observes the state of the string (in code points) before and after a user operation occurs?
You're describing diffing, which is one way (probably the worst way) for my code to find out what edits a user made. Good editing libraries will fire editing events instead, for each change made to the document. So in this case, I'd get an event handler firing with an insert event at position 3 & with content "8 9". But yeah, you still sometimes need to reverse engineer edits by looking at the before / after strings and diffing them.
We need to send that insert event over the network to other peers, and save it in a database. The question we're debating is: How should we express the edit position? Should we count the number of UTF8 bytes before the insert position ("1 2 3")? Or the number of unicode scalars? Or the number of grapheme clusters?
Eg, should a Ukrainian flag have a length of 8 (utf8 bytes), a length of 2 (unicode scalars) or a length of 1 (grapheme cluster)?
> If grapheme clustering rules change all the time, and the above was done on Windows 11, and then someone views it on an 8-year-old Android phone, can we have confidence that it will be rendered the same? Is it even possible to make that work properly?
Nope! New unicode characters (and new grapheme clusters) are being added all the time. For example, the polar bear emoji is made up of 3 unicode scalar values - (Bear) + (Zero-width joiner) + (Snowflake). If you look at this page[1] on an 8 year old android phone, you might just see BearSnowflake instead of the emoji.
The collaborative editing system can't fix the polar bear's rendering. But I want everything else to still work. I still want you to be able to delete those characters if you want, or edit anywhere else in the document correctly. I want my collaborative editing server to work with new emoji that haven't been released yet.
If we count characters using grapheme clusters, imagine a document which starts with a polar bear. An old android phone might count that as having a length of 3 (since it doesn't know to join them all together). All the edits made on that android device will look wonky for everyone else, since the editing positions will appear in the wrong locations. If we count characters using the other methods, we don't have this problem.
[1] https://emojipedia.org/polar-bear/ https://emojipedia.org/polar-bear/