golded-plus-1.1.5-20260904 (unicode)

Sixth snapshot of the unicode branch: a review of everything the
branch had changed against master, six things the last snapshot's
users asked for, and two new package targets.

A message written in a UTF-8 session whose area imports another
charset was stored with its From, To and Subject double-encoded. Once
the header editor was done, the new message was parsed the way a
message read from the base is, and the fields - typed a moment ago in
the session's own charset - went through the XLATIMPORT conversion as
if they had come from an old CP866 message. Every Cyrillic name posted
from a UTF-8 session with a CP866 import charset came out as mojibake
in the base. Present in every snapshot so far; found while testing the
header kludges below.

The review. Everything the branch changed was read against master
from eight angles and each finding verified by hand. What that caught:
a CHRS kludge whose first word ran to 64 bytes and ended in QP wrote
past a stack buffer in code run for every header while an area is
listed; a kludge that was exactly RFC sent the scan past its
terminator; inserting a character in an input field moved the tail
twice when the character under the cursor was not the length of the
one typed, so a Cyrillic letter inserted before ab gave Бbab - and
the last byte of any field was unreachable in insert mode; starting
without golded.cfg segfaulted in its own cleanup under curses; the
FTS-0001 cut on a UTF-8 header field split a three-byte character on an
8-bit console or a DOS build; a copied or moved message had its
header cut by bytes; the message list took a header charset kludge
over a charset fixed by hand while the reader honoured the choice; a
SOUP import stored MIME encoded-words as names; a width computed below
zero threw std::length_error on a narrow screen; and a UTF-8 message
read on an 8-bit console went through iconv once per character. All
put right, each in its own commit.

Windows 9x has its console back. WriteConsoleOutputW,
ReadConsoleOutputW, WriteConsoleW and the wide input calls are stubs
there, and the split that chose the ANSI calls had gone from the paths
the Unicode cells introduced. Every console read and write now goes
through one helper: the wide call on NT, the ANSI call with an OEM
conversion on 9x. Compiles with every Win32 toolchain; not run on 9x.

The log says which message, and whose charset. The line about
characters replaced by ? names the area and the ordinal the reader
shows, and says where the charset was decided - a CHRS kludge, a
Content-Type header, the area's XLATIMPORT, or recognised from the
text. The copies echoed to the console at exit were cut at 78 bytes;
they are whole now.

The FSP-1030 header kludges are read everywhere. UCSFROM, UCSTO
and UCSSUBJ carry in UTF-8 what the base's own fields could not hold.
A message that carries them shows their contents in the list, the
header, the thread tree and the reader, and an answer is addressed
with them - the JAM, Squish and *.MSG drivers take them from the
header kludges beside CHRS, so the list has them without reading the
text. WRITEUCSHEADERS <yes/no> (no) writes them when a message goes
out in UTF-8 and a field does not fit, and lets the header editor take
fields of any length in such an area. Per group.

LARGEHEADERTOBASE <yes/no> (no) cuts From, To and Subject to what
the message base can hold instead of FTS-0001's 35, 35 and 71 bytes -
JAM keeps 100 in each, Squish 36, 36 and 72, WildCat 70, AdeptXBBS 59,
59 and 69, PCBoard 120, 120 and 60, Synchronet has no limit. The header
editor limits a field to that, counted in the bytes of the export
charset as it is typed: 100 bytes of JAM are 50 Cyrillic letters. The
packed message a tosser builds is still defined with the FTS-0001
widths, so this is common practice rather than the standard, and the
manual says so. Per group.

XLATUTFAUTODETECT <yes/override/no> (no) recognises a message
written in UTF-8 that does not say so, for the day such mail turns up
in an echo whose XLATIMPORT is something else. A text is taken for
UTF-8 when every byte above 0x7F belongs to a well-formed sequence,
there is at least one, and every character so encoded is one a message
might plausibly contain. That last test came out of measuring the rule
against a base of a hundred thousand messages: three lower-case CP866
letters form a well-formed sequence now and then, and what they decode
to is Tai Le. With yes a charset kludge still wins, with override
the recognised UTF-8 wins over the kludge, a charset fixed by hand wins
over both. The list applies the same test to the header fields, and an
answer written with XLATREPLYORIGINAL goes out in UTF-8. Per group.

NODELISTLASTWINS <yes/no> (no), read by GoldNODE: where several
nodelists carry the same address, the entry from the nodelist named
last in the configuration is kept and the others are dropped from the
index, so a lookup finds one node instead of opening the browser. A
USERLIST entry wins over any nodelist. Unlike -D this compares
addresses alone and keeps the later entry.

Alt+numpad on Windows types the character again, and in Unicode.
The console composes the character from the digits typed while Alt is
held - decimal, or hexadecimal after numpad + where the
EnableHexNumpad registry value allows it - and hands it over on the
release of Alt. GoldED+ took it from a cooked console read instead,
one byte of the console codepage, which cannot carry what a UTF-8
session types; Alt+0133 gave ?. The key-up event is read now, so
Alt+0133 is the ij ligature and Alt++0431 a Cyrillic б.

The screen follows the terminal when its window is resized, in
the curses builds and on Windows alike. The size used to be read once
at startup: the reader, the lists and the editor kept drawing the old
geometry into whatever the window had become. A resize now reaches the
program as a key of its own; the screen is laid out again from the raw
configuration values, the reader reopens its views to the new width
and height and reloads the message to wrap at it, keeping its place, a
list open at the time closes and reopens at the new size, and the
internal editor redraws itself in the new window. The margins a text
was typed with in the editor are not changed by a resize.

Two new packages: Arch Linux, x86_64 and aarch64, built from the
PKGBUILD published at fido.zxalexis.ru and now kept in
contrib/Archlinux/. The aarch64 package is built natively on arm64
with makepkg. The golded wrapper runs gedlnx under ru_RU.UTF-8
whatever LANG is set to.

Also: reading a Synchronet base cut the three header fields through
whatever character stood at byte 36 or 72; the cut is at the buffer
now and falls between characters.

Seventeen archives. Every binary carries the build stamp 20260904.