Rust is missing an abstraction over non-contiguous chunks of contiguous allocations of data that would make handling ropes seamless and more natural even for smaller sizes.
C# has the concept of “Sequences” which is basically a generalization of a deque with associated classes and apis such as ReadOnlySequence and SequenceReader to encourage reduced allocations, reuse of existing buffers/slices even for composition, etc
Knowing the rust community, I wouldn’t be surprised if there’s already an RFC for something like this.
I think you might be looking for the bytes crate, which is pretty widely used in networking code: https://docs.rs/bytes/latest/bytes/index.html
In general this sort of structure is the sort of thing I'd expect to see in an external crate in rust, not the standard library. So it's unlikely there's any RFCs, and more likely there's a few competing implementations lying around.
Is buf-list[0] what you're describing?
I hadn't heard of rope data structures until I read about the xi editor (also written in Rust) a few years ago, but it looks like that's been discontinued.
The authors of Xi are currently working on Xilem, an experimental reactive UI framework for Rust: https://github.com/linebender/xilem
In the announcement post, they mention that work on Xi is considered "on hold" rather than strictly discontinued: https://raphlinus.github.io/rust/gui/2022/05/07/ui-architect...
Legendary-tier yak shaving.
"I want to build an editor, but first I must solve rendering 2D graphics purely on the GPU, invent a parallelizable path solver, and code a human perception-based color value manipulation library."
You have no idea.
I think we're at five or six levels of yaks by now.
(xi -> xilem -> masonry -> vello -> peniko -> color)
Repo says "discontinued".
Yes, the xi repo is discontinued. They recommend the lapce editor as the spiritual successor:
Zed uses something similar to ropes as well:
Zed's Sum Tree is my favorite datastructure ever and is the future of database indexes.
Zed seems to be a gui-oriented editor here: https://zed.dev/
You still need a backing data structure that holds the contents of your editor, and that's where you'd use a rope.
How would you associate non-character data with ranges of characters, such as for syntax coloring, semantic links, and references to points in the text?
(I couldn't find a mention of this in the README, design.md, or examples.)
In Emacs buffers, the concepts include text properties, overlays, and markers.
That would depend on your editor's implementation.
But, within this API, is there any support for the associations with non-character data?
For example, if you delete some text these Ropey data structure, does Ropey have facilities to update the associated non-character data (such as deleting all or part of one or more chunks of the non-character data, and/or updating positional information)? Or do you have to do that separately outside of Ropey?
Author is perhaps better known for his really great path tracer (and attendant blog), Psychopath: https://github.com/cessen/psychopath
Also, I have to wonder when this fad of loudly announcing when something is written in Rust will finally come to pass. Maybe software written in other languages should loudly announce it in every second sentence? To me at least it's become as self-aggrandizingly cringe as "Sent from my iPhone" at the end of every email...
When it’s a library of code, the language it is written in is pretty pertinent information as that’s the language it has to be consumed from…
Maybe it is already considered an achievement if someone manages to write a program in Rust.
Any editors using this?
It seems like Helix is using it https://github.com/helix-editor/helix/blob/master/docs/archi...
FWIW, I use Helix as my main editor and every time it has crashed (probably a few dozen times over a year or two, I've filed issues), it's related to bad text position stuff, where it effectively goes "out of bounds" on the text data structure.
I think its mostly due to multiple buffers showing the same content, as opposed to this Ropey library directly.
Not that library in particular, but https://zed.dev/blog/zed-decoded-rope-sumtree