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