v5.0.0-preview

[jkotlinski]

Added

• An improved SEE which should decode most colon words.
• "durexForth vx.x.x" boot message.
• RDERR: read and print error channel of current device.
• ERASE, PARSE, TRUE, FALSE, SPLIT

Changed

• S" max string length is reduced to 255 characters.
• S" and .( no longer support multiple lines.
• ( now only supports multiple lines when reading from text file.
• Define MML strings using MML"
• Changed REFILL to Forth standard behavior: Fill the input buffer from the input source, returning true if successful.
• #> (the pictured numeric output string buffer) now uses its own buffer, separate from HERE.
• Do not print "ok" while compiling. Makes it easier to re-enter multi-line word definitions in interpreter.
• Moved tests to a separate disk (tests.d64).
• gfx: Renamed ERASE to PEN.

Removed

• GETC, 100/

Fixed

• DOWORDS incorrectly quit for some non-false xt return values.
• POSTPONE error handling.
• Documented DEFCODE, #S
• LOADB/SAVEB/DOS hang on device not present.
• REQUIRE(D) stopped working after 16 INCLUDE(D) files.
• Undefined behaviour after loading base.fs. broke in 1.5.1.
• V: allow entering control characters inside quotes only.
• V: visual bug when saving.
• SAVEB did not restore input stream.
• Various maintenance patches.
• turtle: BACK did not go back.
• QUIT could fail to reinitialize graphics.

---

This discussion was created from the release v5.0.0-preview.

[ekipan]

#> (the pictured numeric output string buffer) now uses its own buffer, separate from HERE.

The tradition is to put it 34 chars after HERE, right behind where PAD usually starts (since #> now grows backward, also traditionally). It would save the buffer space. Is there any reason not to?

[ekipan]

Which also means a buffer overrun only trashes the user's most recent word, making it more likely they can recover with a marker.

[jkotlinski]

That seems like a good idea. Would you like to make that change?

[Whammo]

see is remarkable! You're --> <-- this close to a source-less Forth.
😲

[jkotlinski]

Thank you, let me know if you find any problems with it.

It would be nice if it came in-built and did not need to be include'd. For that, v would need to shrink a lot.

[ekipan]

I just noticed one change in behavior for v that I'd like to confirm was intentional or not before I file an issue: you can no longer cursor past the end of a line.

Try opening a file, pressing A [left] [right]. In v4 the cursor moves back onto the end, in v5 the cursor stops at the character before the newline.

[jkotlinski]

The change was not intentional. Having said that, I am not sure either old or new behavior was intentional, either.

The old behavior is more like vi, I guess that is a good thing.

[jkotlinski]

this seems fixed in v5.0.0