std::atomic's need to be brace-initialized, or else we fail with
"use of deleted function" errors

Odd that MSVC built it just fine.

Include function names. Include host:port in "Unable to connect" error.

And other safety improvements in getsub()

getkeys() could return -1 if user disconnects (and SS_ABORT not set), so this
appears to be a valid bug.

Add comment/question about the use of JS_SetReservedSlot(), for Deuce

getkeys() is actually never (currently) called with a NULL arg, so this
could not actually occur, but better to prepare for that eventuality.

This looks like a case of not following the YAGNI principle.

Unlikely, but valid thread-safety concerns by Coverity

In response to Nelgin's inquiry:
DigitalMan would it be difficult to add login/logoff date/time to these
messages?
Node  2: xxuserxx logged on Telnet
Node  2: xxuserxx  logged off

Now, you can just use @-codes to add that kind of thing to these text.dat
strings.

Ideally, this would use startup.tls_error_level, but which one? And how?

Also, make a TODO comment to fix the fact that all JS Socket log messages
are logged to the terminal server log output. :-(

Saves some opening, reading, and logging, but otherwise was harmeless.

Fix issue #422

ddmr_cfg.js: Fixed the version number to match the current version of DDMsgReader (1.87)

See merge request !366

ddmr_cfg.js: Added a type check that should fix an 'undefined' error when formatting option values

See merge request !365

Fixed typo in ddmr_cfg causing an error on startup

See merge request !364

DDMsgReader: Speed improvements and updates for newscans, and updates for the indexed newscan menu mode.

See merge request !363

Eric Oulashin authored 1 year ago and Rob Swindell committed 1 year ago

DDMsgReader: Speed improvements and updates for newscans, and updates for the indexed newscan menu mode.

Performance improvement

Similar to GNU gettext(), by loading gettext.js and enclosing all user-visible
strings in gettext(), a script can get easy/easier support for non-default
(i.e. US-English) locales by loading translated strings from the [JS] section
of ctrl/text.<locale>.ini (if it exists), or customized strings from the [JS]
section of ctrl/text.ini (if it exists).

Results are cached for fast subsequent uses of the same string.

What's *not* supported is different translations (e.g. colorization or
whatever) for the same string used in a different scripts. That could be
added (e.g. use a different section name for script-specific translations),
pretty easily, if desired.