From: utzoo!decvax!ucbvax!ARPAVAX:C70:editor-people Newsgroups: fa.editor-p Title: Buffer representations Article-I.D.: ucb.1899 Posted: Sat Sep 4 03:54:28 1982 Received: Sat Sep 11 01:58:56 1982 >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...