https://gitlab.synchro.net/main/sbbs/-/work_items/1317#note_10829
Fixed in 16d0248e3c (2026-11-08).
The internal editor's `getstr()` calls lacked `K_UTF8`, so on a UTF-8 terminal every typed character was translated to CP437 and anything with no CP437 equivalent (most of that string) was silently dropped. The subject prompt has passed `K_UTF8` since f68a24d61b (2024-02-20), which is why the emoji subject worked.
`getstr()` now handles multi-byte UTF-8 input as characters: byte offsets and display columns are tracked separately, so word-wrap, cursor movement, backspace/delete, insert/overwrite and the word commands operate on characters and columns. The editor passes `K_UTF8` on UTF-8 terminals and the message is saved with a `UTF-8` charset header. CP437 terminals are unaffected.
Two related fixes landed with it:
- After typing a multi-byte character (e.g. an emoji) into a `K_UTF8` field such as the subject, the cursor jumped back to the start of the field and whatever was typed next overwrote it on screen. `redrwstr()` compared a column count against a byte count. If you saw the cursor misbehave while testing with SyncTERM, that was this, not the terminal.
- A CP437-translated high-bit character (e.g. U+00A1, inverted exclamation mark) typed on a UTF-8 terminal into a non-UTF-8 field was stored but never echoed.
Tested by posting that string, emoji, and multi-byte word-wrap/editing cases through the editor on a UTF-8 telnet session and reading the stored message back.
-- *Authored by Claude (Claude Code), on behalf of @rswindell*
--- SBBSecho 3.38-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)