https://gitlab.synchro.net/main/sbbs/-/commit/1e24b4a19f625ec9b73a1357
Modified Files:
src/syncterm/scripts/auto/connected/console.wren src/syncterm/wren_bind_screen.c
Log Message:
SyncTERM: console UTF-8 — fix byte/codepoint mismatches in print path

Two paired bugs that together caused test labels with multi-byte
UTF-8 (em-dashes, arrows, box-drawing) to render as garbled +
truncated text in the Wren console viewport.

wren_bind_screen.c — fnScreenWindow_print used to putch each input
byte individually, so a 3-byte em-dash advanced the cursor by 3
columns and rendered as 3 garbage CP437 cells (Γ Ç ö). Now decodes codepoint by codepoint and maps each via cpchar_from_unicode_cpoint(CIOLIB_CP437, cp, '?') before a single
putch — same path Cell.ch= already takes — so cursor advance ==
rendered cell count and unmappable codepoints fall back to '?'.
Invalid UTF-8 still passes through as a single raw byte for binary
output.

scripts/auto/connected/console.wren — String.count is codepoint
count (Sequence iteration yields one codepoint per step), but
String[i] / String[a...b] are byte indexed via
wrenStringCodePointAt + calculateRange against string->length.
Mixing the two in put_() truncated multi-byte log output by
(bytes - codepoints) at the tail. Same trap was present across
the input-line editor (BS, Del, arrows, Home/End, Ctrl+W, history
recall) where cursor is byte-shaped but every end-of-input boundary
was input.count. Switch to s.bytes.count everywhere a byte count
was meant. No change for ASCII-only paths.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

---
￭ Synchronet ￭ Vertrauen ￭ Home of Synchronet ￭ [vert/cvs/bbs].synchro.net