Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!cbatt!ihnp4!inuxc!pur-ee!uiucdcs!uiucdcsb!liberte From: liberte@uiucdcsb.UUCP Newsgroups: comp.sys.mac Subject: Re: Editing > 32K text blocks Message-ID: <164500008@uiucdcsb> Date: Thu, 11-Dec-86 15:11:00 EST Article-I.D.: uiucdcsb.164500008 Posted: Thu Dec 11 15:11:00 1986 Date-Received: Mon, 15-Dec-86 06:48:45 EST References: <164500006@uiucdcsb> Lines: 68 Nf-ID: #R:uiucdcsb:164500006:uiucdcsb:164500008:000:3101 Nf-From: uiucdcsb.cs.uiuc.edu!liberte Dec 11 14:11:00 1986 I received a few responses regarding how to edit more than 32K bytes of text. There are several alternatives, none of which appear to me to be particularly elegant - that is, make maximal use of the built-in routines. But all ideas are appreciated. Thanks for your replies. One other alternative is to read the whole file into several smaller records each of which may be edited with built-in routines. The hassle is in splitting records which get too big and editing across record boundaries. Dan LaLiberte liberte@b.cs.uiuc.edu liberte@uiuc.csnet ihnp4!uiucdcs!liberte ------------------------- From: spry (Andy Spry) Have you seen the newest version of the Medit editor. It handles the problem of editing >32K records by breaking the file up into pages whose size can be set by the user (up to the majic 32K) at the time the file is read in. --------------- From: woody@tybalt.caltech.edu (William Edward Woody) Organization: Calfornia Institute of Technology There are a couple of ways to edit blocks of text larger than 32K. The first way is to have some way of bringing in only a small fraction of the total file, keep tract of any changes that are made, and effectively "hack" the TEdit stuff. I'm sorry about the vague terms and the poor description; I was told how to do this once, and simply rinkled up my nose in dismay. The second (and my favorite way) to allow editing blocks larger than 32K is to simply implement your own version of the TEdit functions. It's not too difficult; most text tends to be line-oriented, so one way of storing text internally is as an array of fixed-length strings (preferably 150 or 200 char/ line), and "fake" the functionality. I know: fixed length strings take up a lot of memory in the Mac. But it's a lot faster than having to calculate where the end of each line occures! ---------------- From ihnp4!bellcore!sdh@joevax Mon Dec 8 18:52:15 1986 It seems that the way you would have to do the editing is by keeping most of the block on disk. You only keep enough in memory so that immediate scrolling and paging don't get bogged down. The trick is to keep file pointers to the next line after the end of the current block in memory and the insertion point, and using simple pointer finagling, you can handle editing of files well beyond the memory capacity of the machine. In fact you can probably handle simultaneous editing of 4 or 5 such files. The obvious drawback is that you have to do huge amounts of disk access and file copying and the like. And that will slow it down without a doubt. Another alternative is to play with the heap to let you allocate a gigantic (a few hundred K) buffer for text. You read ALL your file into this buffer and then treat it as a file structure, except in RAM. This will give you speed, but a memroy limitation. Your choice. One method of implementation is to determine upon the run of your application, the amount of memory you have to play with. If its limited, use disk files, if its huge, use RAM files. That increases your code size, of course. Retief of the CDT bellcore!sdh