Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!bloom-beacon!apple!well!hoptoad!tim
From: tim@hoptoad.uucp (Tim Maroney)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Tabs in TextEdit
Message-ID: <5553@hoptoad.uucp>
Date: 7 Oct 88 05:06:42 GMT
References: <6210@pasteur.Berkeley.EDU>
Reply-To: tim@hoptoad.UUCP (Tim Maroney)
Organization: Eclectic Software, San Francisco
Lines: 24

As David Oster pointed out, tabs can be handled by intercepting the TextEdit
bottleneck TEWidthHook using the new TECustomHook procedure documented in
Technical Note #207.  This only works on System 6.0+.  However, Tech Note
#203 ("Don't Abuse The Managers") indicates that there is little point in
doing so.  Past 2K or 3K, the performance becomes unmanageable, because
of a combination of handle resizing and line offset adjustment.  To do a
text editor in TextEdit, you'd have to keep everything in 2K chunks, which
could be done (after all, you handle your own scroll bar) but my guess is
the memory overhead from all those TEHandles would get mighty noticeable.

Yes, I had a reason for posting this.  What does Apple have against linked
lists?  If TextEdit did everything with a linked list of lines rather than
a relocatable contiguous array, both these sources of overhead would drop
out.  The same goes for their cautions about abusing the List Manager.  I'm
sure the original code was that way because no one expected to be handling
lots of data; but wouldn't it be great if Apple upgraded to linked lists?
You could, for example, put a real text editor in a terminal program with
only a few days work, build a simple spreadsheet on the List Manager, and
so on.  Since Apple is crawling with programmers, I hope they do this, unless
there's something I've overlooked.  There's still some memory manager overhead,
12 bytes per line, but this seems sustainable.
-- 
Tim Maroney, Consultant, Eclectic Software, sun!hoptoad!tim
This message does represent the views of Eclectic Software.