I was a little frustrated with sublime text folding code using indentation instead of syntax (there's an issue but they don't want to fix it). I have large C++ files, and it seems visual studio does a better jobs at folding.
I was a little frustrated with sublime text folding code using indentation instead of syntax (there's an issue but they don't want to fix it). I have large C++ files, and it seems visual studio does a better jobs at folding.
On modern computers, you can get away with a flat buffer of text (not even a gap buffer) for documents up to a few megabytes. I don't really recommend a gap, because it adds complexity and doesn't help with the worst case, though of course it cuts your average case down.
If you're going for simpler than a rope, my recommendation is array of lines. You have to do logic to split and fuse lines (for example, when backspacing over a newline), but it's not too bad. The only thing they don't do really well is single long lines.
I don't recommend piece tables. They have superb performance on first load, but then fragment. The reason I'm such a huge fan of ropes is that they perform excellently in the worst case - long edit sessions, long lines.
Best of luck!
I like the simplicity of the doubly linked list of lines. I'm not sure what advantage the rope data structure would bring.
Lots of problems that have an optimal complex solution can be solved with way simpler constructs in the prototyping phaze.
I'd go further than that. I'd say in production too. If the simple thing is fast enough even when you test on a slow machine, then implementing the faster but more complicated data structure is a form of premature optimization.
For scaling large docs, you can do a linked list of gap buffers and avoid re-allocs of large buffers.
Super simple, efficient enough for most “i wrote my own text editor”, can always plug in a more complex structure later.
Author’s implementation will drag down if you have very long lines (e.g., transpiled JS).