I don't know if that would work, as how would the interpreter know if ;COMMENT itself is not part of the comment, since commented words are skipped over and not interpreted.

How about this instead. The same as the parenthesis works, the interpreter searches for the ending parenthesis to signal the end of a comment, one can use the backslash or dbl-forward-slash to signify the end of the comment as well. But there would be no need to use an ending back-slash as that is the same as using the parenthesis.

Some computers have the ability to use the backslash character, so a backslash can signify to ignore all text to the end of the line and a dbl-forward-slash can signify to ignore all comments until another dbl-forward-slash is encountered, even across multiple lines.

One approach used for extensive comments are shadow blocks. A shadow screen is based on a set of blocks for source and an equal number for comments, so that a single offset value allows you to "flip" between the source and the shadow block. In the day, this would often be tied to a function key, where the block display function would have the offset built in and the function key would XOR the value of the offset with the stored value, so toggle between an offset of 0 and the shadow screen offset.

A useful word in that context is \\ which is "end of source in file" when interpreting a file, and and "end of source in block" when interpreting a block. Starting the index line of a shadow block with \\ rather than \ (or in a C64th, /// rather than //) ensures that the comments are never accidentally interpreted.

When I was working on the "no function key text file editor" BMW (Bruce McFarling's Writer), I would put the \\ at the start of a decorative line:

\\ // \\ // \\ // \\ // \\ // \\ // \\ // \\ //

... where everything but the first pair of character is just decoration, since the \\ ends interpretation of the file.

I very much like the 64 character wide block versus a 128 character or (to fit a C64 display) a 40 or 32 character wide block, and adopted 63 character plus a return key as the width of my text files, for easier porting of individual sets of words to blocks if need be. As far as the "problem" of losing useful space when indenting, I would indent by three spaces, which worked for me.

However, my C64 Forth back in the day used 40 wide blocks, and for 64 wide blocks, I would want a bitmapped text display with a 5 bit wide font.

However, I could see using a 32 character wide block in a context where of using a small enough LCD display for a target board that 32x8 is substantially easier to read than anything more ... to avoid left-write scrolling. If you use the bottom line for entering commands, scroll up at the second line except when at the top of the block, and down at the sixth line except when at the bottom of the block, it is reasonably easy to have a feel for where you are in the block, and the command prompt can be X> where "X" is the base 32 of the row number.

In that context, if I was using shadow screens, I would have a load screen that loads the offset into a variable. However, IIRC, shadow screens really became popular when hard drives and their "massive" 10MB or 20MB capacity came into use ... IOW, my guess is they tended to be from a slightly later vintage than the pure floppy disk based systems. I am not sure I would try them with anything smaller than a 1581 (or SD2IEC with 1581 images), so I'd go with an offset of 400.



Yes, that is also an objective of xForth ... indeed, until I got so busy with the new job, I was planning to tackle the INCLUDE system first.

But I do now intend to have // as a synonym of \ and /// as a synonym of \\

I've have been reading some of these posts and found some of the comments interesting as I had written a screen editor a couple of years ago that used the ANSI terminal. More recently however I enhanced it greatly to allow full ANSI key operation, highlighting, and multiple file tabs etc. At present this version operates with my Tachyon extensions including the filesystem running on top of Mecrisp on the RP2040 chip. I am using this editor to develop a full suite of dev tools to run on any Forth system that has maybe about 8k of RAM or more (the RP2040 has 264kB internally). Power to the Forth!

The editor has become more of an IDE since I can compile and run code and invoke the logic analyzer module etc. I still need to finish a multipass macroassembler which will produce a clean and flat listing and output file. While this is geared for the RP2040 I see no reason why I can't backport it to some of my older 65xx systems including the M37702 etc where I had lots of RAM.

BTW, rather than raw blocks, I handle a standard FAT32 file in pages of 32 lines of 128 characters and terminate each line with a CR. This makes the file compatible with PC text editors but makes it possible to edit the file in 4k pages although the page length can be adjusted up to 64 lines. The clipboard is in RAM but I may make it hybrid with a file to allow for systems to use less RAM. ^F10 will compile code from the clipboard or if empty then from the current page rather than F10 which compiles the whole file. A null terminator(s) marks the logical end of a file.

Normally I use VScode but I am loving the ease of use of this editor with intuitive controls. Plug my board in, type ED and it restores the last multi-tab session complete with cursor position and theme etc.