🚀 go-pugleaf

>From Hess.Unicorn@MIT-MULTICS Sat Sep  4 03:22:47 1982
Based upon experience designing new things into a multi-page buffer-gap
editor (Mince), I strongly suggest one of the linked-list-of-lines
representationss if you can spare the space and can GC at all.

Mark of the Unicorn discovered that you start paying penalties in compute
time when you try to do video terminal insert/delete line and multi-window
screens (horizontal and vertical) on a continuous blob of characters --
you either have to search for and count newline characters, or add "screen
marks" (buffer pointers akin to The Mark) which are always updated with
each character insertion (expensive).  And adding anything like region
display where the region to be wiped is displayed in inverse video and
grows and shrinks as you move the point around costs a lot with this
scheme, too.  Truly losing.  Even if you have to have some of these screen
marks in a linked-line approach, at least they can be partitioned so that
you know that you don't have to update a certain subset of marks when you
insert text on the current line.

Why then did we choose to use the buffer gap approach?  We were memory
limited and page store was user-visible (floppy-based CP/M); this made GC
ridiculously slow and noisy.  Perhaps on a larger machine, you wouldn't
notice the CPU and disk overhead as much as we did on a Z80 chip...