There was some semi-recent interest in the design of a "visual" block (or screen?) editor, and I stumbled across an intact copy of my first block editor and some trace of its evolution since that initial version, and I thought I'd share. Maybe someone will find it helpful, or at least interesting.

Some background: This was for a standalone x86 PC Forth implementation along the Loeliger model, with some influence from cmForth and Pygmy Forth, and is probably very idiosyncratic, but the basic ideas should tend to apply anywhere. Blocks are 1k, so there's no concept of a "screen" of source text separate from a block.

The original block editor appears to have had the ability to copy a line at a time within a block, to erase a line, and to replace a line entirely. There was no editing within a line, it was a pure replacement operation.


From what I recall, editing code with this was a struggle. Especially since INLINE only had backspace for input editing. For that matter, navigating between blocks was more difficult than I particularly wanted. Moving blocks around was painful, moving lines of text between blocks even more so, and for some reason I seem to recall only having one disk in use for Forth at the time, hence part of why the code is so terse and dense within the block.

At some point I realized that I could make a simple loop to watch the keyboard for page-up, page-down, and escape, and use this to navigate through the available blocks without having to constantly re-type "<number> EDIT" all the time. And being able to switch between two arbitrary blocks can be very handy, either because you're using "shadow blocks" for documentation, or because you're trying to figure out some problem that requires looking at two widely-separate parts of the system, or because you have a key that copies the contents of one block to the other. I seem to no longer have the original version of this "block browser", but the remaining part is still interesting:


The dispatch logic in check and checkall is more than a bit sketchy, especially the way that check can force a return from checkall. The toplevel logic that went with this would have been in the same block, and probably looked somewhat like this (written "off the cuff", and not tested):


Note that the browsetable format is 16 bits of SKEY result followed by a 32-bit execution token, followed by a zero in place of the SKEY (EKEY by any other name?) value. From here it doesn't take much to come to the concept of a dedicated "exit" key, maintaining a position within the current block, using GOTOXY to set the cursor to that position, having "printable" keypress events insert text into the block, and so on. It's a bit less than three more blocks of code (spread out over four in my case). A later version of the editor used a linked-list, so that new keys could be defined later on. The same mechanism was then used for a rewrite of INLINE, though it did not progress to the point of any input editing beyond backspace.

If I were to do it all over today, I'd probably start with a toplevel control structure derived from the third version of the editor and basic display of and navigation within and between blocks, then immediately the editing bits. No point to writing a line-oriented editor when I can go straight to one that I find more comfortable to work with... Also, I'd probably take the time to add better input editing to INLINE, and possibly even an input history...

In PETTIL I kept things as simple as possible. The PET is hardwarily incapable of displaying 1024 characters at once, but 1000 is close enough. It's also cassette-based, but I wanted it to feel like Forthy virtual memory, which is why it uses a RAM buffering scheme. There are two bits of metadata associated with each BLOCK. One says whether it is rlencoded (or not) and the other bit says whether it is screen (1000 bytes of screencode + 3 bytes of linewrap info) or data (1024 bytes of anything).

For the screen editor itself, it is just an infinite loop that calls CHRIN. I trap the jiffy IRQ and see if the user pressed the STOP key. This flashes the screen and waits for the next keystroke, which is treated as an editor command. The screen unflashes and the command executes. STOP-Q is "quit", it reverts the IRQ to its normal value. The editor is really just the PET screen editor, thinly wrapped. The whole thing, excluding the commands to delete and insert lines, move to a different screen, display a help/info screen, etc... is about 70 bytes of code!

In Fleet Forth, I kept things simple by making the screen editor an extention of the Starting Forth editor that uses the Commodore 64 screen editor. LIST lists a block with a colon after each line number. XED is a defining word.

The assembly code between >ASSEM and >FORTH stuffs four right shift keys into the C64 keyboard buffer and isn't needed, it just makes it more convenient for me. XED is used to define Fleet Forth's screen editor words.