• src/sbbs3/atcodes.cpp chat.cpp putmsg.cpp qwk.cpp readmail.cpp readmsg

    From Rob Swindell (on Windows 11)@VERT to Git commit to main/sbbs/master on Fri Sep 4 18:22:55 2026
    https://gitlab.synchro.net/main/sbbs/-/commit/86f65840821a1baf78d18694
    Modified Files:
    src/sbbs3/atcodes.cpp chat.cpp putmsg.cpp qwk.cpp readmail.cpp readmsgs.cpp scansubs.cpp
    Log Message:
    Use terminal capabilities, not user-record bits, for RIP/charset tests

    Ten decisions in the terminal server tested raw user-record flags
    (useron.misc & RIP, & COLOR, & UTF8, ...) where what they meant was
    "does this terminal support it?". Under AUTOTERM those record bits are
    not authoritative: logon() re-derives them from the auto-detected
    terminal into useron.misc in memory only, while Terminal::get_flags()
    derives its own flags from sbbs->autoterm. The two disagree as soon as
    the record is re-read over sbbs->useron mid-session - which happens on
    the next user.* property read after any user.* property write, since js_user_set() invalidates the cache and js_user_get() then reloads the
    record into the live user struct - or when another node writes the
    record while you are online.

    Reported symptom: connect with a RIP terminal while a second, non-RIP
    session is online, and the non-RIP session starts auto-displaying the
    "msgscan" menu at the message-reading prompt: a menu meant for RIP
    terminals only.

    Converted to Terminal::supports() / Terminal::charset():

    readmsgs.cpp, readmail.cpp, scansubs.cpp (x3) - menu display
    chat.cpp, qwk.cpp (x2) - menu display
    putmsg.cpp - RIP sequence pause defeat
    atcodes.cpp - @RIP@, @ANSI@, @ASCII@, @COLOR@, @ICE@, @PETSCII@,
    @SWAPDEL@, @UTF8@, @MOUSE@

    The EXPERT halves of the compound conditions still read useron.misc:
    that is a user setting, not a terminal capability. @AUTOTERM@, @UPAUSE@
    and @SPIN@ are likewise left alone.

    Note: the three charset @-codes now use term->charset() == CHARSET_*,
    matching @PETGRFX@, so they are mutually exclusive - @ASCII@ reports Off
    for a UTF-8 terminal even when NO_EXASCII is set in the record, since Terminal::flags_fixup() clears NO_EXASCII in UTF-8 mode.

    The raw-bit idiom is older than the problem: these tests go back as far
    as 7e3e47141a5 (2000), and it was 374282bf81 (Terminal class) that made
    the record's terminal bits non-authoritative.

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

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