NetNews Usenet Archive 1993 #3/NN_1993_3.iso/spool/comp/lang/forth/3994

Internet Message Format | 1993-01-25 | 2.0 KB

Path: sparky!uunet!gatech!rpi!crdgw1!rdsunx.crd.ge.com!ukulele!eaker
From: [e-mail] (Chuck Eaker)
Newsgroups: comp.lang.forth
Subject: Re: Documenting
Message-ID: <[e-mail]>
Date: 25 Jan 93 20:14:04 GMT
References: <[e-mail]> <[e-mail]>
Sender: eaker@ukulele (Chuck Eaker)
Organization: GE Corporate R&D Center
Lines: 30
Nntp-Posting-Host: ukulele.crd.ge.com

In article <[e-mail]>, penev@venezia (Penio Penev) writes:
|> Mike Haas ([e-mail]) wrote:
|> : BTW, this idea of "inserting" a screen may apply to BigForth, but
|> : not in most of them.  In fact, it's those Forths that use
|> : screens-within-files that provide this capability.  And it's the
|> : fact that there's a FILE SYSTEM underneath that allows you to do this!
|>
|> Well, the file system has nothing to do with it. When You insert a
|> screen You copy a block range one screen further. This You can do on
|> any BLOCK system. And text editors do the same. I've never seen an OS
|> function "isert bytes(blocks) at the file pointer". I know CPM, DOS &
|> UNIX. I may be wrong for the rest OSes.

You're right, the file system has nothing to do with it.
However, the insert commands in typical Forth block editors
usually cause a number of characters (equal to the number of
inserted characters) at the end of the line or the end of the
block to be discarded. This is not true of file based editors.
I don't especially care for this block editor behavior.
It's an implementation quirk that requires attention, and, in
the old days, often distracted me from the real work I was trying
to do. Running out of room on a block almost always required
shuffling the contents of blocks around to free up the next
sequential block to avoid fragmentation that would undoubtedly
proved to be another distraction later. This was time spent
not doing real work.

--
Chuck Eaker / P.O. Box 8, K-1 3C12 / Schenectady, NY 12301 USA
[e-mail]        [e-mail]       [phone]