(and their terminal supports) mouse reporting.

Allow set_mouse() to disable mouse-reporting in the terminal (if it was previously enabled), even when mouse support has been turned off by the user.

for the (newly-added) TerminalMouse string.
Also added MouseTerminalQ string.

so made it enabled/disabled per-user-terminal settings. This means that if
you were already enjoying mouse support, you're going to have to turn it on
to keep enjoying it. It also means there's currently no way to enable/use
mouse support pre-logon, but I have ideas about how to support that for
sysops that want that.

I removed the FTP-download of syncterm.lst from Vertrauen as that didn't work in Win10 for whatever reason.

with the changes to "parse messages from server better".
This change caused the channel's nick array to be populated with a single
string that contained all the Nick's in the channel, space-separated, which
broke tab-completion of nicks and the total users in a channel displayed
in the status line, as reported by Hakuchi.

(e.g. Linux-armv6 for rPi).

we're at it.

definition of ARCHITECTURE_DESC in builds targetting ARM processors.

Add support for %^ command-line specifer which expands to the system architecture (e.g. "i686" for Win32 builds, "x64" for Linux-x86_64 builds).
Currently, there underlying XPDEV macro definition does not differentiate
between arm32 and arm64, but it should. Next...

The msgbase 'status' header created with smb_open_sub() had all its fields
0-filled.
This would cause all kinds of msgbase settings (e.g. max msgs, max age, etc.) to not propagate from their SCFG settings (for mail or sub-boards)
to the newly-created msg base(s).
But most importantly, it would cause the mail base to be created without the
"EMail" attribute flag, causing the msgbase to be treated as a sub-board
(public message area) and users could not then read their received mail.

The root-cause was that smb_open() will zero-out the current smb.status
value before trying to read it from the msgbase header, thus losing any
values that were populated in there before calling smb_open(). Rather than
change the behavior of the ancient smb_open() function, just restore the
correct default smb.status values after calling smb_open() and before
calling smb_create().

automatically revert to Raw/TCP mode. This resolves the issue of users that
connect using modem/serial emulators over TCP that do not actually support Telnet and then either try to transfer files, which usually will not work due to escaped (or unescaped) IAC (0xFF) characters, or the user may be sent Telnet Go Ahead (GA) sequences which may display as periodic garbage in their terminal program.

This seemed like a better solution than having (yet another) dedicated terminal server port for "raw" connections over TCP, though a "raw" port still might not be a bad idea for a future enhancement. RLogin is already super close to "raw", so it's probably not really necessary to have another port configured/listening.

The patch I gave you hasnt applied correctly - I probably should have given you
a unified diff. <sorry>

Can you revert it, and put this text in the "case 'N'" stanza:

this.__properties__.curr_attr=((this.__properties__.curr_attr)&0x8f)|LIGHTGRAY;

So that stanza not only reverts HIGH and BLINK, it also sets the background and
foreground colors back to BG_BLACK|LIGHTGRAY.

regular users (non-sysops), as reported by WitNik (thanks!

An experimental external() mode flag that runs JS modules in their own separate runtime and context - currently does not work (appears to corrupt the shared JS context). Not actually used currently.
The reason I wanted to run a JS module (actually JS doorgame) in its own context was to get useful error messages (filenames and line numbers) when the module throws an exception. Currently, the error is just reported as occuring in xtrn_sec.js, which isn't helpful or correct.

I patched funclib.js to support blink, by pressing "B" when the colorPicker is
rendered.

I have a fix for frame.js - I noticed an issue that \1n was not reseting back
to normal (normal being black background).

Eg: I had this:

const frame = new
Frame(1,1,console.screen_columns,console.screen_rows,BG_BLACK|LIGHTGRAY);
frame.gotoxy(1,1);
frame.putmsg(test);

and if test was sending something like \1n\17\1kfoo\1nbar, "bar" would still
have a white background with black text.

Strip leading trailing whitespace from channel/item link text.
Removed some but not all of the ugly crap.

Amended HTTPRequest.follow_redirects to be a number instead of boolean.

var h = new HTTPRequest();
h.follow_redirects = 1; // We'll follow this many redirects

Location given in the response header, if present. Not enabled by
default, so turn it on like so:

var h = new HTTPRequest();
h.follow_redirects = true;

Should probably add "too many redirects" protection, since this could
turn into an eternal game of HTTP ping-pong.

FTN Reply-IDs are not added here (yet).

import_netmail(): Safer string handline and a bit more/consistent log output around attached file handling (especially if mv() fails).

Extra log level message (INFO, WARNING, and DEBUG) when moving netamil file attachments (attached files) - for debugging the issue reported by
alterego (ALTERANT)