Honestly an array isn’t really the worst… for smallish files on modern processors. Sequential memcpy is pretty dang fast and pointer indirection can be slow.
Worked on a homegrown Mac wsywyg editor back in the 90s. Arrays worked perfectly. If you are assuming that files fit in memory, using BlockMove() was very, very fast indeed.
I can see if you need to edit multi-gig log files and things will not fit in memory, but for small files, array is totally fine.
There were other tricks that were done back then to keep the number of single char inserts down to a minimum while typing. Like reading chars into a small buffer during fast typing and then inserting all the keystrokes at once as soon as you had the time.
Yes. When typing normally there is no slowness because you’re swapping one string for another.
But when pressing enter, pasting a bigger snippet, or deleting lines the slowdown is less noticeable. When you type a word, the deltas are tiny and it is easy to process for your brain. While the changes in multiple lines happen less often, so waiting a couple of frames doesn’t bother you much.
This is at millions of lines. With small files it is indeed too fast.
I was amused that this approach was dismissed without analysis as impractical. Sure it was impractical in living memory when CPUs and memory were many many orders of magnitude slower.
An array and nothing else? It very quickly stops making sense to copy the entire tail section of the file every time the user inserts text in the middle.
A conservative estimate for memmove() speed on a computer from even a decade ago would be 1GB/s. That's 1ms to move 1MB. All humans won't notice a latency below 10ms.
this is true, and a good point; the machine i'm typing this on is closer to 20 gigabytes a second. but, for example, if i refill a longish paragraph in emacs, it might easily do dozens of insertions; if i indent or outdent a block of code, it might do hundreds. it's easy to imagine a situation where i have a 13-megabyte mail.log open in emacs and want to do a search-and-replace to reduce the noise level in it, maybe making 12895 edits. this currently takes less than a second (emacs uses a gap buffer), but if each of those edits took 6 milliseconds it would have been a minute or two
If it was an issue, and a simple gap buffer isn't fast enough, you could do a linked list of gap buffers. Would still be pretty simple, and probably very fast.
and if an array doesn't work, a gap buffer isn't much additional complexity.
all of my C homebrew editors have been gap buffer based, and I told myself I'd reimplement if I ever wanted to edit something large enough for that to be a problem — but it never was.
I can see if you need to edit multi-gig log files and things will not fit in memory, but for small files, array is totally fine.
There were other tricks that were done back then to keep the number of single char inserts down to a minimum while typing. Like reading chars into a small buffer during fast typing and then inserting all the keystrokes at once as soon as you had the time.