🚀 go-pugleaf

Question for editor wizards:

I've been pondering a sort of cross between a linked list of blocks and the
buffer/gap mechanism; call it "multi-gap", just for consideration.  This would
use a number of medium-to-large blocks (say, 8K); each block would initially
be half full, with an optional empty block would be at the beginning of the
"file" to handle inserts at the start of the buffer.  This would seem to have
many of the advantages of the gap system while avoiding some disadvantages
(i.e. you can easily arrange for each window in a multi-window editor to have
its window-point at or near a gap; oving the gap is less expensive because it
only moves a maximum distance of the block size; inserting a file can be done
by allocating one or more new blocks for its contents; cut and paste can be
done by arranging for the cut text to be in its own block).  It *does* have
some (seemingly?) minor disadvantages over a straight buffer gap mechanism;
for example, you want to split blocks that become too full, and coalesce
neighboring blocks that are getting too small (with the exception of the first
block).  On the other hand, the resulting blocks can easily be combined with a
VM mechanism.

Am I missing anything, or is this a reasonable way to go about constructing an
editor?  I would think that something would use it if it were as good as it
seems to be....

(P.S.  Thanks for the editor tutorial(s).)

++Brandon
-- 
Brandon S. Allbery    allbery@NCoast.ORG, BALLBERY (MCI Mail), ALLBERY (Delphi)
      uunet!cwjcc.cwru.edu!ncoast!allbery ncoast!allbery@cwjcc.cwru.edu