text VS xi-editor

It sounds like a generic length function in Unicode in 2023 is no longer a good idea. These articles complaining about the variety of lengths in Unicode are annoying at this point. Pretty much all of them can be summed up as, "Well, it depends." And, that isn't wrong. But nerds love to argue until they are blue in the face about the One Correct Answer. Sheesh.

This is the most interesting comparison article I have seen in years about Unicode processing in C++: https://thephd.dev/the-c-c++-rust-string-text-encoding-api-l...

The author is also the lead on an open source C++ Unicode library called ztd.txt: https://github.com/soasis/text

How does this compare with https://github.com/tzlaine/text and https://github.com/soasis/text ?

You might consider https://github.com/soasis/text (https://ztdtext.readthedocs.io/en/latest/index.html) which is a proof of concept of this proposal that we may get in C++26

from this link for the tested option that was the only one to check all the boxes green in the article... it makes me ask myself if the article was written biased with the purpose of promoting ztd.text and that these boxes/criteria were to an extent cherry-picked with that purpose in mind.

Github: https://github.com/soasis/text

That's a huge misrepresentation of the reality. Of course it has its own string class, because there has not been a proper type in the standard library for Unicode text, and for many, we are not there yet (otherwise we would not be having other libraries filling the empty space).

You can checkout ztd.text, which implements presented ideas. Few years passed, so they were more polished too.

The library you talk about is https://github.com/soasis/text and he has an account here.

Project Link: https://github.com/soasis/text Announcement/Blog Link: https://thephd.dev/any-encoding-ever-ztd-text-unicode-cpp

PS: found some example code in the github project which seems to take care of the special Windows situation:

https://github.com/soasis/text/blob/main/examples/documentat...

Unfortunately this doesn't look so simple anymore.

Was confused until I realised I'd confused Zed, with Xi[1] which is also rust based, and which incidentally has a frontend called "Xim"..

Also there's a wiki-editor (like Tomboy[2]) called "Zim"[3].

[1] https://github.com/xi-editor/xi-editor

Project site linked from the GitHub[0] is https://xi-editor.io. Linked doc is a mirror of this[1], which was afaik originally written by Raph Linus.

[0]: https://github.com/xi-editor/xi-editor

[1]: https://xi-editor.io/docs/rope_science_01.html

> thing that gets deleted when you hit backspace

Is there a canonical source for this part, by the way? Xi copied the logic from Android[1] (as per the issue you linked downthread), and I vaguely remember that CLDR had something to say about this too, but I don’t know if there’s any sort of consensus here that’s actually written down anywhere.

[1] https://github.com/xi-editor/xi-editor/pull/837

This is pretty much how copy-on-write ropes work. Check out xi-rope, Ropey or crop, they're all built using B-trees and implement the behavior you described.

Helix is awesome, though once Lapce (spiritual successor to Xi editor) gets the Helix/Kakoune editing model, I may have to jump ship

Home (xi-editor.io)

Maybe take a look at the Xi editor (https://xi-editor.io/) (written in rust I think) that uses a client server architecture.

Have a look at what Lapce uses. The editor is coming along nicely, and iirc, they use the Xi editor as a plug-in.

Raph Levien posted a retrospective about using CRDT’s for collaborative editing in xi-editor here [1]. His conclusion is

“I come to the conclusion that the CRDT is not pulling its (considerable) weight. When I think about a future evolution of xi-editor, I see a much brighter future with a simpler, largely synchronous model, that still of course has enough revision tracking to get good results with asynchronous peers like the language server.”

[1]https://github.com/xi-editor/xi-editor/issues/1187#issuecomm...