Subj : src/sbbs3/atcodes.cpp chat.cpp putmsg.cpp qwk.cpp readmail.cpp readmsg
To   : Git commit to main/sbbs/master
From : Rob Swindell (on Windows 11)
Date : Fri Sep 04 2026 18:22:55

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>
--- SBBSecho 3.37-Linux
 * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

.