Path: utzoo!attcan!uunet!lll-winken!lll-tis!mordor!lll-lcc!unisoft!mtxinu!rtech!llama!daveb From: daveb@llama.rtech.UUCP (Dave Brower) Newsgroups: comp.emacs Subject: Re: Buffer data structures Message-ID: <2223@rtech.rtech.com> Date: 27 Jun 88 18:27:16 GMT References: <18612@cornell.UUCP> Sender: news@rtech.rtech.com Organization: Relational Technology, Inc. Alameda, CA Lines: 33 In article <18612@cornell.UUCP> blandy@cs.cornell.edu (Jim Blandy) writes: >My favorite is a combination of the 'gap-in-the-middle' approach >and the linked list approach. In the gap-in-the-middle approach, >the buffer is one contiguous block of memory, where the unused >portion acts as a gap for insertion and deletion; you move the gap >by shifting characters from one side of it to the other. Once you've >got the gap where you want it, insertion is as easy as storing the >characters and shrinking the gap; to delete, enlarge the gap to enclose >the characters you want gone. (I got this approach from an editor >published in some computer magazine WAY BACK. Byte, maybe.) The >problem comes when the gap gets filled in; if you've got the whole address >space to yourself, you just tell the user "tough luck," but if you're >in a multitasking environment, you need to ask for more space; I'd >make a linked list of blocks, each with its own gap. If a block >is empty, you free its space. This is basically what the Mince/Final Word editor uses, with a twist. The linked list and the descriptors for the blocks are kept in separate data structures, and the data blocks are a fixed size. With this scheme, they can be paged out to a "swap file" when memory runs short, or if you decide only to devote a certain amount of space to running your editor. Later Final Words would periodically write out all pages and stash some global data, allowing a complete in-context restart in the event of a machine crash. This is kind of neat. The down side to this scheme is that it makes maintaining the point and marks difficult. You need to adjust marks when the gap(s) move, and deal with multiple gaps when moving between pages. There's a lot of tradeoffs involved, and it's easy to see why multiple page/gaps aren't of much interest on a big-memory/VM machine. -dB {amdahl, cpsc6a, mtxinu, sun, hoptoad}!rtech!daveb daveb@rtech.com <- FINALLY!