Gap Buffers

A lot of people criticize Emacs's use of the gap buffer, and suggest that it go with a more complex data structure at the core like ropes. While I think there can certainly be room for improvement with this core data structure, I don't think ropes are a good solution, and I think this is far from a crippling issue. Let me start with the second point first.

One of the biggest arguments against gap buffers is that they're simply not optimized for multiple cursors. I'm not a big fan of multiple cursors (as opposed to kmacros and occur-mode), but more importantly, gap buffer multiple cursors performance doesn't seem noticeably worse than ropes for most reasonable editing situations on a human scale. Just look at this graph:

I'm eyeballing it here, but it looks like the scaling factor is around 200µs per 6000 bytes. If we say that the threshold of human delay perception for something that isn't extremely reaction-time intensive like gaming is around 50ms, then cursors can be 150,000 bytes, or about 12,500 lines (assuming 120 character lines of code) apart before the delay even becomes noticeable to human perception. With the less naive multiple cursor editing system suggested in that same article, that delay can be cut down by 30%, as well, meaning a 16,250-line separation before the difference even becomes noticeable to the human brain. And you're not going to be using multiple cursors all the time, so a barely-perceptible amount of lag, say 100ms, as you type when using multiple cursors is hardly an issue – which raises that ceiling to 32,500 lines of code apart.

Which raises the question. Who in the hell is using multiple cursors that far apart? The big benefit of multiple cursors is that you can see the edits you're making being made live in all the places you're performing an edit, so that if something goes wrong you can respond to it immediately instead of having to re-record your keyboard macro or what have you, but what font size/monitor combination could possibly show that many lines at once? And if you're skipping around a file viewing only a few cursors at once as you make an edit, wouldn't a keyboard macro be essentially equivalent anyway? More than that, if you've got a file that big and you really want to use multiple cursors for some reason, why not create an *occur* buffer with all the lines you'll be changing, edit that with multiple cursors (likely to be extremely fast) and then write all the edits out at once, which will take less time in total for the gap buffer to do? And that's not just a performance optimization, that's actively better than the alternative, since with an occur-mode buffer there's actually a snowball's chance in hell you'll be able to actually see what you're doing with all those cursors (and so not negate most of the point of multiple cursors)!

Moreover, in my personal opinion, multiple cursors are overrated:

1. Having to pay attention to every place where I want to make a rote macro-like change at once as I'm making the changes, cycling my eyes between all the lines and trying to keep track of all of them, is a lot more stressful for me than just recording what I want to do, creating an occur mode buffer of all the places I want to do it (or just using isearch to jump between them), and doing the changes one at a time, responding to any accidents or special cases in each line one at a time as they show up, instead of having a big mess appear all at once in several lines. It's not even more work, since to create multiple cursors in widely separated places you'd need to use search anyway.
2. Additionally, with keyboard macros, there's an easy and natural on-ramp to making whatever you did useful later, through naming the macro, saving it to a register, or even converting it to Elisp code, instead of the operation you did being temporary and ephemeral, limited to the specific instances that you wanted to deal with in one moment.
3. Speaking of that, keyboard macros have much greater versatility, at least in Emacs, where they can run any keyboard shortcut or Emacs command, not just edit text in a specific place in a buffer. Thus you can use the same facility you use to automate editing text to automate your editor.
4. Moreover, with Emacs macros at least, it's trivial to structurally edit macros, instead of needing to record them, if something goes wrong, so it's easier to respond to mistakes – not quite as easy as multiple cursors, but I think the other benefits outweigh that.

In addition, it is my opinion that using gap buffers is actually a really savvy development choice. The reason is that they're dirt simple, and more than good enough at human scale, in comparison to other popular data structures which are much, much more complicated to implement and, while they do have benefits at the very high end, tend not to show those benefits most of the time. Moreover, gap buffers have extremely low constant costs, versus other more complex data structures which have a high constant factor, and require a ton of upkeep and maintenance and can get into "bad states": <https://coredumped.dev/2023/08/09/text-showdown-gap-buffers-vs-ropes/>.

There are some data structures that keep many of the benefits of gap buffers but can alleviate a lot of the problems Emacs has with long lines and non-local editing, however. For instance, there's the Cluffer.