I finally got around to figuring out how to edit and saving a screen block. It was such a simple line I don't why I couldn't figure it out sooner. It works well and the screen LIST's and displays correctly, but then I ran into problems when trying to LOAD the screen.

After doing a hex dump of the screen buffer, I noticed that zeroes were being stored at the end of some of the lines. I isolated it to EXPECT, which stores zeroes at the end of the input line. I see the need for the zero when TIB is being INTERPRET'd, but there are some instances when the zero is not wanted or needed.

When I use EXPECT to transfer input to a screen buffer, the zero at the end of a line terminates the interpreter and the rest of the screen does not get INTERPRET'd.

One obvious solution is to use an intermediary, like PAD, then move the line over to the screen buffer, skipping the zero. But I like to use the KISS method and use as few word descriptions as possible to get a result. For me this is one too many unnecessary moves.

My ultimate solution was to modify EXPECT slightly so that a zero only got stored at the end of a line in TIB and not any other memory area. So far, this works perfectly and allows me to use EXPECT for other inputs, such as string input as well as a screen buffer input.

These 3 lines are all I need for editing any line and saving any screen.

: editline ( scrn# line# --- addr count ) swap (line) over >R type ." ]" cr 1f emit R> 40 expect ; ( Note that TYPE always prints 64 chars so the right bracket is just a screen marker for the 64 character limit)
: save update flush ;
: refresh prev @ dup 0 swap ! ;

Are there any other methods of doing the same thing?

[MORE on the subject of line editing]

I am just discovering the power of (LINE), not only for editing, but for INTERPRET'ing as well. With a simple DO LOOP, I scan the screen buffer and turn all semi-colons into ;S, without saving the screen. Which then allows me to INTERPRET any single word definition on a screen, but still allows one to interpret the screen as a whole if needed for another program.

This really opens up a lot of new possibilities for writing programs. Instead of duplicating lines for each program, one just has one set of lines in a Virtual file and the programs are now mostly just a bunch of 2-BYTE numbers and a line interpreter word AL, with the ability to still add colon words, constants, variables and strings if needed. This reduces every word description down to just 2x 16-bit values and 1x 16-bit address to produce any word description from the Virtual file.

( program word processor)
: AL ( scrn# line# ) OVER SCAN (LINE) INTERPRET ; ( AL = Add Line)
1 1 AL 8 7 AL 15 3 AL : NEWWORD ; ...etc

The version of Forth I am using was originally programmed to use floppy disks. But I also discovered it can use a much larger Virtual file on a hard drive. I created a 256kb Virtual file and my new one-line screen editor is making this a hoot. The maximum size of a file under Prodos is 16 Mb and the Virtual file can be expanded as needed up to that limit. This might eventually get filled up and makes the line interpreter way more useful.

The possibilities have suddenly become endless when creating programs, where before I felt Forth was so restricted and bloated with the system being contained in each program and words being duplicated for each program. Now only one Forth system is required, and programs are much smaller when created and can be loaded and forgotten as needed.

Now for the biggest problem of them all. How does one remember where each word description is stored to make a program from such a large Virtual file?

Answer: Easy! With a Virtual file search engine.

The other idiosyncrasy of EXPECT is that it doesn't return the actual character count as well. In TIB it is not needed, but it is needed when creating strings and I found another reason to have a character count when copying to the screen buffer using the method above. I found that when editing some lines, and pressing return in the middle of the line, the text after the return is not getting cleared. With an actual count being returned, I can now use it to calculate how many spaces need to be stored after return is pressed.

I decided it is best for me if EXPECT enters with a requested character count and returns with an actual character count on the stack. The count can just be dropped if not needed. The only word that uses EXPECT in the original Forth system is QUERY, which just sends the input to TIB. I just added a DROP after EXPECT.

: EXPECT ( maxcount --- actualcount )

Someone mentioned having a variable SPAN? But that would also mean that EXPECT was modified to store the character count in that variable. I think I like having the actual count returned on the stack, though.