Path: utzoo!attcan!uunet!wuarchive!usc!ucsd!ucbvax!SCFVM.GSFC.NASA.GOV!ZMLEB
From: ZMLEB@SCFVM.GSFC.NASA.GOV (Lee Brotzman)
Newsgroups: comp.lang.forth
Subject: Re: Blocks VS Text a compromise
Message-ID: <9010151631.AA11190@ucbvax.Berkeley.EDU>
Date: 15 Oct 90 16:29:01 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 51



Rick VanNorman writes:
>I propose using a virtual program page model for files -- each page
>being roughly equivalent to an almost free-format block.  The limits on
>page size are arbitrary, but a size equal to one printed page seems
>reasonable, say 80 columns by 60 lines (4800 bytes).  Writing a page
>editor such as this is relatively trivial; although not quite as easy as
>a block editor, it is still within the range of a 4K byte extension in
>most Forth systems.  Text could be imported into the editor from normal
>Ascii files -- the import procedure would take tabs, crlf, etc., and
>put them into the fixed size buffer, with all white space occupying a
>character position just like in blocks.  Editing would be simplified by
>this model, with the only major extension over block editing being the
>requirement to scroll the visible portion of the page up and down.

   I actually proposed something of this sort to the ANS TC a couple years
back (the proposal was shot down in flames, not unexpectedly).  My proposal
called for two User Variables:  BLKSIZE and RECL for block size and record
length, where the condition BLKSIZE RECL MOD 0= had to be true (i.e., the
record length had to be an integral divisor of the blocksize).
   Then, the amount of storage retrieved by BLOCK was determined by BLKSIZE,
and RECL could be used to determine record boundaries in an editor.  In support
of this concept, I rewrote my editor so that it correctly displayed and edited
files of any blocksize.  It was trivial to do, and I now had the best of
both worlds: unlimited file size and superior edit-compile-debug loops from
blocks, and reasonable layouts by setting RECL=80 and BLKSIZE=2000 (80*25).
   My reasoning came from recognizing that blocks for source code were simply
64-byte fixed-length records in a 1024-byte blocksize, and there wasn't any
really good reason to restrict it this way in this day and age.  Like I said
the TC never even really gave this one serious thought and they were probably
right.
   Anyway, it was real easy.  I don't think you need any set of conventions
like you describe to make a reasonably-sized block system compatible with a
text-file system.  Our block editor had block split, block join, block insert
block delete, block swap, and block copy.  With all that stuff, shuffling code
was *easier* than with any text editor I've used since (and I've used a lot
of them under six different operating systems).  You can just load a text file
into the block editor like you described, write it as a block file during
code development, and convert it back to text when the program is finished.
   One advantage not mentioned in the block-vs-text battle that I really
appreciated on small systems was a file size limited by the available mass
storage, rather than memory.  An Apple // only had 20-30K of free space at
any one time, and with block files I could just as easily edit a 5-block file
as a 100-block file.  Of course, on larger systems -- even PCs -- this is
less of a consideration.

-- Lee Brotzman (FIGI-L Moderator)
-- BITNET:   ZMLEB@SCFVM          Internet: zmleb@scfvm.gsfc.nasa.gov
-- "Between an idea and implementation, is software." -- Curse from Hubble
-- Space Telescope engineer.