To me, this really needs to be benchmarked. The advantage of the gap buffer architecture is that it is simple; opening and closing the gap should be very fast.

To me, this really needs to be benchmarked. The advantage of the gap buffer architecture is that it is simple; opening and closing the gap should be very fast. I believe that moving a contiguous memory block (to close or relocate the gap) in a source file should take far less than a millisecond. Fast memmove implementations take advantage of a number of hardware optimizations and should run over 2GB per second by my estimation. Multiple cursors don't require more bytes to be moved than working with two cursors, it just divides the distance from the first to the last cursor into smaller blocks. The total number of bytes moved remains the same. 100 cursors in a 10MB file requires 100 blocks averaging less than 100KB in size to be moved, and moving this number of bytes (that will be less than 10MB) will take roughly .005 seconds. That would mean maybe .005 seconds of latency per keystroke while using 100 multiple cursors in a large file would come from the gap buffer. The benefits of the gap buffer are simplicity and the concomitant reliability that can come from a simpler design. Low level operations inside the editor like multi-byte characters, memory-mapped I/O, memory allocation, regular-expression searching, incremental backups, diffs etc. are all easier with the ability to close the gap and just work on a single contiguous block. I've heard the argument before that editors should be using more complex data structures, but the simplicity and additional benefits of cache friendly designs make me hesitant to accept this reasoning without actual benchmarks.