Item — HN Reader

Thanks for your thoughtful comments. I'll try to address some.

Using ropes is a tradeoff. A gapped buffer is viable for the reasons you state, but I think ropes come out ahead for what I'm trying to do. It's not so much the cost of filling the gap, as that ropes really facilitate parallel, incremental, and asynchronous computation. For example, I want the "save" operation to write a snapshot of the current buffer to disk, while still being fully editable. The snapshot operation is trivially easy and fast with immutable ropes, but if you tried to hack something like that on top of a gapped buffer, it would increase complexity dramatically.

If you look at the implementation of my Unicode line breaking algorithm, you'll see that the indirection cost of the rope abstraction is minimal. In fact, it _flies_ - in my tests, it's about 3x faster than ICU working on a contiguous string. This is because it's able to work on a leaf at a time. The same can be done for search, etc. Yes, it'll require some reimplementation of string basics, but I personally find that kind of thing fun.

I'm still working out the plugin story. Quick answers to your questions though. A syntax highlighting plugin sees a window of the source buffer (effectively a cache, with invalidation by RPC). I'm thinking a contiguous buffer for the window, not a rope - it'd be bounded by a few megs. For a huge file, computing the syntax highlight of what's off screen can be slow. In no case does it block typing, worst case there's a lag before the colors resolve. The plugin sends the annotations back as rich-text spans, which are stored in the core. Scrolling is instant and doesn't inform the plugin. The autocomplete plugin will almost certainly be separate from the syntax highlighting one (but presumably an author could create a combo plugin if it had advantages).

This doesn't address everything you brought up, but hope it helps illuminate some of my thinking.

As the main developer of an editor (vis) using a similar segmented data structure (a piece chain, similar to a rope, but storing the text junks in a double linked list, thus asymptotically worse) I can attest that the performance is generally very good. Some work will be required to adapt/write a regexp library around some kind of iterator interface, but in general I found that persistent data structures are very well suited for editors.

One problem with the gap buffer is that as soon as you have multiple cursors/selections or in my case structural regular expression support, then you have to move the gap around all the time. Also undo/redo support is simply not as elegant as with a persistent data structure.

For syntax highlighting copying the relevant text region into a contiguous memory block is simple and works well. For now I'm trying a completely stateless approach to syntax highlighting i.e. the text coloring is always completely recalculated. This trades highlighting accuracy for simplicity, but in practice the results aren't too bad. Efficient syntax highlighting for huge files is a hard problem.