editor: bound the edit buffer (fix typing/paste overflow and unreloadable max-size saves)

[vinej]

Hi — thanks for durexForth! While using the v editor I hit two related buffer-size bugs and have a small fix for forth/v.fs. Sharing in case it's useful upstream.

1. The edit buffer had no upper bound while editing

ins-char and paste-line grew eof with no check against the end of the text buffer. Only loading a file was size-checked, not typing or pasting. Once eof passed $cbff, it marched into $cc00+ (hi-res color RAM, then $d000 I/O registers), silently corrupting memory — which shows up as forth crashing "after a while," and more readily with larger files.

Fix: a small room? guard so ins-char/paste-line refuse (and show F in the status line) instead of overrunning:

: room? ( n -- f ) eof @ + bufend 1+ u< ;

2. Save and load disagreed on the maximum size

The load path rejects files over 44 blocks (here $20 + @ #44 >). But a buffer filled all the way to $cbff saves as 45 blocks:

• content = $cbff - $a001 = 11262 bytes → file = 11264 bytes (+2 load address) → ceil(11264/254) = 45 blocks.

So you could fill and save a buffer that the editor then refused to re-open with "too big".

Fix: cap bufend to $cba7, so a maximally-full buffer stays within the same 44-block reloadable limit:

• content = $cba7 - $a001 = 11174 bytes → file = 11176 bytes = 44*254 → exactly 44 blocks.

$cba7 is also still below $cc00, so it satisfies both the physical and the reloadable limit (the smaller one wins).

Testing

Verified against stock VICE 3.9:

• With the guard, eof clamps at the limit and nothing is written past the buffer into $cc00.
• A maximally-filled buffer now both saves and re-opens (previously "too big" on re-open).
• Existing 44-block files (e.g. gfx) still load and display correctly.

The change is confined to forth/v.fs (+29/-1, mostly explanatory comments). Happy to adjust naming/comments or split it if you'd prefer.

[Whammo]

Acknowledged.
This is better than a nod to not use big files. ☺️