Path: utzoo!attcan!uunet!cs.utexas.edu!usc!brutus.cs.uiuc.edu!lll-winken!sun-barr!decwrl!shlump.nac.dec.com!mountn.dec.com!minow
From: minow@mountn.dec.com (Martin Minow)
Newsgroups: comp.sys.mac.programmer
Subject: Re: The Eternal Question (Using TextEdit with HyperCard)
Message-ID: <1131@mountn.dec.com>
Date: 3 Dec 89 15:34:17 GMT
References: <11881@phoenix.Princeton.EDU> <36956@apple.Apple.COM> <11887@phoenix.Princeton.EDU>
Reply-To: minow@mountn.dec.com (Martin Minow)
Organization: Digital Equipment Corporation
Lines: 61

In article <11887@phoenix.Princeton.EDU> bskendig@phoenix.Princeton.EDU
(Brian Kendig) writes:
>Good points; let me just clarify a few things I said:
>
>Is there any code out there to show me how to 'simulate' TextEdit,
>then, for a large amount of text?  This doesn't sound like child's
>play...

It's not.  The source for my TextEdit clone (to appear this spring in
MacTutor) fills most of a floppy.  And it doesn't change the underlying
-- inefficient -- organization of the data (this is left as an excercise
for the student :-).

What I'd do is to write a separate program that breaks the text into
paragraph-sized chunks (each paragraph <= 32K bytes) and store each
paragraph in a database of sorts.  I suppose you could use a resource
fork, though there are more efficient (and less general) organizations.

Then you need to build a database of paragraphs with the database designator
(location in the file, text size, and formatting information).  Your "build"
program would do this by reading each paragraph into a TextEdit record
and calling TEGetHeight (IM-V) to get the formatting information.  Now,
to display the text, you read enough paragraphs to fill the screen and
write them in a window (Don't use TextEdit for this.)  Note, by the way,
that you'll have to handle styles and multiple fonts yourself.  This
isn't that difficult to do.

As a previous reply mentioned, you will have to "jacket" the scroll
bars so the range you present to the control manager is within the
short integer range permitted.  Keeping the "true" range in floating-point
would probably be sufficient.  I.e., if the range is 0-1.0, you would
do something like
	SetCtlMin(..., 0);
	SetCtlMax(..., 32767);
	SetCtlValue(..., (short int) (true_value * 32767.0));
Your scroll/display module would read paragraphs from the database
as needed.  You probably want to manage the paragraph storage yourself,
rather than relying on the Macintosh storage routines.

You also mention searching.  If you have a large chunk of text, consider
building a search-hash array for each line (or one per paragraph and
one per line).  Such an array would have, say, 256 bits per line.
Each word in the text would hash to a single bit, which would be set
in the hash array.  Your search word would then be hashed.  To search
the database, you need only look at those paragraphs/lines which have
the search bit set. There is a lot of room for experimentation here:
what is the right number of bits, should you set more than one bit,
and require the pre-search to match both, etc.  There might be something
on this in Knuth V3, or other books on searching.  I remember reading
about this technique in a CACM article in the late 1960's or early 1970's.

>The text involved here is indeed read-only; I had overlooked that!
>This makes life a *little*, if not greatly, easier.

This is the key to a fast system: do the work up front in a "database
compiler" so the user is not delayed.

Good luck.

Martin Minow
minow@thundr.enet.dec.com