Hacker News Reader

Comment by filcuk | Hacker News Reader

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?

A rope is only concerned with manipulating a string with very low cpu overhead while maintaining the illusion of a sequence of characters or bytes. It doesn't really care or maintain any other text decoration you might be maintaining. That is the concern of the consumer of the rope and I'm not sure there is a good common interface for that.

Thanks.

I was a little confused, because the lede sentence was "Ropey is a utf8 text rope for Rust, designed to be the backing text-buffer for applications such as text editors."

Pretty much all text editors are expected to implement decorations and references, somehow, and some popular text buffer APIs support those.

If you'd like an example of how this can be done, Swift's AttributedString type is exactly that. It manages the association of runs of attributes (font, kerning, color, etc.) with Unicode text, and its backing storage uses a rope type provided by the swift-collections package. (The rope module itself isn't stabilized yet, so it's really only used for AttributedString at this point, AFAIK.)

https://github.com/swiftlang/swift-foundation/tree/main/Sour...

https://github.com/apple/swift-collections/tree/main/Sources...

I thought the defining feature of a text editor (as opposed to a word processor) is that it didn’t have rich text decorations. Are we talking about the same thing?

Most text editors will support things like syntax highlighting, which are text-decorations even if they're nor user-managed.

Not rich text, but decorations like decorations on a data structure. (I was trying to match the terminology that I thought a previous commenter was using.)

For data that isn't part of the document, you could use a write-through wrapper around the rope, with a secondary data structure mapping ranges of the document to this extra data.

From the wrapper's point of view, there's no difference between character and non-character data, and the whole buffer can be modeled as a collection of indices mapping ranges of the document to different kinds of data.

One of those indices could be a rope (mapping document ranges to character data, for the document text). Other kinds of indices could also be used. The important thing is that all edits go through the wrapper so that all the relevant indices get updated.

Reply on news.ycombinator.com