BBS:      TELESC.NET.BR
Assunto:  src/syncterm/scripts/auto/connected/console.wren src/syncterm/wren_bin
De:       Deuc¨
Data:     Wed, 29 Apr 2026 14:39:54 -0700
-----------------------------------------------------------
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) 
n
---
  mSynchronetn  hgVertrauen n hHome of Synchronet n gh[vert/cvs/bbs].synchro.net

-----------------------------------------------------------
[Voltar]