Reply to note from wbass@xxxxxxxxxxxx Sun, 21 Jul 2024 15:48:21 +0000 (UTC) > Let me define some symbol markers that I can insert in the text, > to show various things. Wally, thanks, this is very helpful. Your explanation is borne out by my tests. I'm using the test program "<SV01,BF xx><PV01><EX>", saved to disk first with the EOF and then without EOF. The test program is run against itself. The results are: With EOF: <SV01,BF xx><PV01><EX>xx Without EOF: <SV01,BF xx><PV01><EX>xx<EX> With EOF, the program runs as expected, puts "xx" at the bottom of the file. Without EOF, XyWrite treats "<EX>" as an inert string and writes it at the bottom of the file, after "xx", as your model predicts. By the way, this is just semantics, but ... I don't view the screen as a "junk pile"; rather, it's XPL's "stdout". The bare string "This is some text" is a valid (if trivial) XPL program; running it puts the string, one char at a time, at the cursor position. Likewise, when XPL misinterprets a guillemet-enclosed expression as inert text rather than executable code (due to the counting error you've identified), it does what it would do with any other text string: it writes it to the screen. Padding the miscounted expression with a func NO (instead of, say, a blank space) avoids extraneous text being written to the screen. And now I think you've explained cogently why this is so. Very interesting! Needless to say, the counting bug, along with numerous others, was fixed in XyWrite 4. The bug fixes and, especially, the many enhancements to XPL and general editing are what made Xy4 immediately compelling for me. Out of curiosity, what's your environment of choice for running XyWrite? Mine is vDosPlus running in 64-bit Windows. -- Carl Distefano cld@xxxxxxxxxx