New LINEDELAY and LINEDELAY:n @-codes
Another way to pace the terminal output of long display (e.g. ANSI) files. LINEDELAY enables a 1/10th of a second delay before the sending of all LF chars. LINEDELAY:n sets the line_delay duration explicitly to a value in 1/100ths of a second units. So LINEDELAY and LINEDELAY:10 are equivalent. LINEDELAY:0 turns line-pacing off. The original line pacing value is always restored after a printfile/putmsg operation.

New JS console.line_delay property (milliseconds) to control via JS. Setting this to a really high value would be bad. Some range enforcement should be added to this and many other console control values (TODO).

Fix the fix to issue #380.

Thanks for letting me know Keyop.

I'm so tired of this 30 year old frequently asked question.

If a sysop really wants their Synchronet BBS to only work correctly for ANSI users, I suppose that should be their prerogative.

I always felt that by not detecting/displaying menu files when the minimum set of files was not present, I was helping sysops to identify an issue with their system (which would not work correctly for non-ANSI users). *And* I always felt that having a single menu/display file that correctly supported both ANSI and non-ANSI users was a nice convenience (who really wants to maintain multiple versions of their menu files?). But I'm so tired of answering this question, I just give up.

Hopefully this doesn't break anything for anyone. <shrug>

That previous commit made all *.40col.msg files display for 80 column users. Not my intention.

So revert to the previous behavior of *.XXcol.* display files. I didn't want to go renaming a bunch of menu files as a result of the previous commit and I didn't want a bunch of sysops with *.XXcol.* files to be suddenly surprised at their new BBS behavior.

And introduce a new file naming convention, *.cXX.* (where XX is a MINIMUM column width). This is the same naming convention used by Mystic, which also treats it is as a minimum terminal width, not a required exact width.

e.g. display basename.132col.msg even if the terminal is 133+ columns wide.

Fixes issue #380.

Fix for one of the problems described in issue #380.

bbs.menu("random*"); would display column-width-specific files (e.g.
random.132col.msg) even when they weren't appropriate for the current
user terminal width.

This is fixed by truncating the filenames matching the requested pattern at
their first-dot rather than the last.

The downside is, you can't have a set of random.#.* files, where # is the
unique part of the filename and * is the file-type extension. Just use
the naming pattern "random-#.*" instead (or something similar) instead.

Reverted the SAFECOPY() NULL source-pointer magic "(null)" string thing as that caused a different Coverity issue. Explicitly check for NULL at the call-sites instead.

Reverted the SAFECOPY() NULL source-pointer magic "(null)" string thing as that caused a different Coverity issue. Explicitly check for NULL at the call-sites instead.

Hopefully not introducing any bugs in the process.

Hopefully not introducing any bugs in the process.

printfile() assumes you want the file displayed starting in column 0, so will send a CRLF to insure that it does (unless the P_NOCRLF mode flag is specified). But this CRLF printing was happening before the file was opened and when the P_NOERROR mode flag is specified, this should be a silent failure with no print output. So move the CRLF printing to *after* the file is opened.

This expose an issue in the latest xtrn_sec.js where it makes several calls to bbs.menu() with the P_NOERROR mode flag set, expecting nothing to happen if/when the optional display files (e.g. xtrn*_tail.*) don't exist.

Reported by JC via IRC.

If text/menu is a symlink (on *nix), then the path above would actually
point to a filename in the parent of the symlink target, which is not
what we want (we want the filename in the text dir). Fixed by using
FULLPATH.

Fix problem introduced in
b1ecd9b6 (August 8, 2019)

When sbbs_t::printfile() is used to display a file that is < 2MB in size
and the P_OPENCLOSE mode flag was not specified, the file is read and
displayed one line at a time. This allows for the quick display of very
large files. This was accomlished by calling sbbs_t::putmsg() for each
line. Unfortunately, putmsg() would save and restore console mode flags
like the auto-screen pause control flags stored in sbbs_t::sys_misc
so this would render some features like the POFF @-code, inoperable.
This problem was reported by WitNik with files displayed from
Bulleeye! Bulletins.

Other issues were discovered with the WORDWRAP/WRAPOFF @-codes.

Fixed with the addition of sbbs_t::putmsgfrag() which is used by
printfile() to display a message fragment (one line) without
saving/restoring console state flags.

If sbbs_t::menu() is called with a menu file/code that includes wildcard characters (? or *), do the random menu thing.
This is true for Baja MENU function and JS bbs.menu() as well as MENU/CONDMENU @-codes, so no longer need a bbs.random_menu() function (removed).

Create sbbs_t::random_menu() (JS bbs.random_menu()) - to make the display of a randomly-chosen menu file from text/menu, very easy.

- hot spots are clickable screen areas (e.g. in menus and prompts) that   generate key-strokes
- commands may be from 1 to 127 ASCII-characters in length
- currently using the X10 mouse reporting mode, may change
- all mnemonics strings (~Example) are automatically hot-spots
- The new ~ @-code defines a hot spot
- Any screen-clear operation clears all hot spots
- sbbs now tracks the current screen (cursor position) row
- eliminated the old "tos" (top-of-screen) boolean (row == 0 indicates "tos")
- created an sbbs_t::ungetstr() method
- keep track if in pause (hit a key) prompt, for special mouse behavior

new JS console object:
- row property
- tos property is now read-only (and deprecated)
- new methods:
  add_hotspot()
  clear_hotspots()
  scroll_hotspots()

redrwstr() gets some UTF8 touch-ups as part of this commit. <shrug>

part of the file, assuming lines are not >8K (on average).

Don't use P_OPENCLOSE printfile() mode for any files > 2MB in size.

the name of a scalar property in either the current scope (by default) or the
scope of the object passed to:
- bbs.menu()
- console.putmsg()
- console.printfile()
- console.printtail()

The 'name' cannot be an array element (e.g. myprop[0]) or a nested object
reference (e.g. myobj.myprop): just a single property name that can be
converted to a string.

Also, bbs.menu() now accepts an optional print-mode argument (default: P_NONE).

mode flag, an EOF @-code would not stop the output since it calls putmsg()
for *each* line of the file and was not checking the return value of putmsg()
for an abnormal/early-termination indicator.

feof() was returning 0 and fgets() never returned NULL. Weird.

the P_SAVEATR mode flag was specified (behave like the P_OPENCLOSE mode).

maintained between lines, reported by Immortal@IDOMAIN:
Use P_SAVEATR to retain the new attributes after each call to putmsg() in
printfile() line-at-a-time mode. We are no setting the initial attribute to
LIGHTGRAY or restoring the original attribute at the end (like a call to
putmsg() withou the P_SAVEATR would) - so we may need to add that later
for line-at-a-time mode, as well.

(new). Reported by Alterego (ALTERANT)

P_OPENCLOSE mode flag is *not* specified, do not malloc()/read() the entire
file and then display. Instead, print one line at a time (so long as that
line is <= 1MB in length), calling putmsg() for each line.

This should allow the viewing of massive text files in SBBS again without
alloc/swap issues.

I left the calls to utf8_normalize_str() in here, but I'm not so sure about
them now. putmsg() will convert UTF-8 to CP437 through print_utf8_as_cp437(),
and that only lacks a couple of conversions that utf8_normalize_str() does
(e.g. ellipsis to "..."), so that might be a good candidate to remove in
the future.

with ZWNBSP/BOM UTF-8 sequence) and messages (with the "CHRS: UTF-8"
FTN control paragra or MIME "charset=utf-8" parts).
Not all UNICODE codepoints are supported (obviously).
Tested with various files from ftp://columbia.edu/kermit/charsets/
(e.g. test.utf8, utf8-boxes.txt)

- for PETSCII, this is automatic and you don't lose blink, but you do lose
  colored foreground when enabling a bright background ("reverse video")
- for ANSI, this mode is typically referred to as "iCE colors" and disables
  blinking-text support
- Ctrl-AE (^AE) is the new attribute code to enable bright-background
  (will have no effect on ANSI terminals that are not iCE color enabled)
  "E" is now valid in the ctrl/attr.cfg file and string values for JS
  console.attributes assignments, as well
- Ctrl-AI (^AI) - blink - now does nothing for ANSI/ICE color terminals
  (blinking is not supported in combination with bright-background)
- Using a new/non-standard CGA attribute bit-flag to indicate the selection of
  bright-background colors (BG_BRIGHT, bit 10), separate from BLINK.
  This change required all/most char/uchar attribute representations to be
  converted to int/uint.

New text.dat strings:
- PetTerminalDetected (renamed from PetTermDetected)
- PetTerminalQ
- TerminalAutoDetect
- TerminalColumns
- TerminalRows
- TerminalMonochrome
- TerminalColor
- TerminalIceColor
- IceColorTerminalQ
This also moved the MsgCarbonCopyList definition to the end of the file
for now.

PETSCII reverse-video attribute fix:
When a CR is sent to the terminal, the reverse-video attibute is auto-disabled
so update our "current attribute" (curatr) value to match the remote.

Support new printfile/putmsg mode flag: P_WRAP to force an ungraceful
line-wrap (splitting) to the specified column width. If no column width is
specified (0), then this mode will force an ungraceful wrap before the last
terminal column where some terminals *may* auto-wrap.

JS console.printfile() and printtail() methods now support an optional
"orig_columns" argument, similar to console.putmsg(). Must specify P_WORDWRAP
or P_WRAP for this argument to have any effect.

Much improved terminal-type selection/configuration in the user defaults
menu and abort (^C) at any of the yes/no prompts is now detected/handled much
better (to answers to the prompted questions are not saved to the user
settings).

full path (sans file suffix/extension), it would use that path for the menu
file to be displayed.

now have their output translated to PETSCII equivalents for PETSCII terminals
(but input is not yet translated).
.seq files are now sent untranslated via printfile() and putmsg() to PETSCII
terminals (using the new P_PETSCII putmsg mode flag).
.seq files (and P_PETSCII mode text printed via putmsg) is now converted
(poorly) from PETSCII to CP437 - this is still a work-in-progress.
Remove the remants of WIP and HTMLterm support from putmsg() and printfile().

means no error message will be displayed/logged if the referenced file does
not exist.

Newly supported files: text/menu/*.msg (higher priority than .asc when the
terminal supports IBM extened ASCII, aka CP437). These are the same format
as .asc files (and supported more readily by PabloDraw).
Newly supported files: text/menu/*.seq - native PETSCII files for PETSCII
terminals only. Support in the underlying putmsg() function is still
pending.
Also, the text/*.msg files now supports alternative file formats for
RIP/ANSI/PETSCII, if the files exist.
WIP menu support removal.
The new menu/display file selection priority will be detailed on
wiki.synchro.net, but rest assured, it's backwards compatible with
the previous/old priority with the exception of the removal of WIP support
and HTML support.

So Omegix recently asked in the Synchronet Discussion group whether or not
a PETSCII (Commodore) terminal could be used to access his Synchronet BBS.
Now, the answer is "Yes". :-)
The major issues addressed:

- detecting a PETSCII terminal, solved by assigning specific (configurable):
  TCP ports to be used for incoming PETSCII connections, by default:
  port 64 is for 40-column PETSCII and port 128 is for 80-column PETSCII,
  but if the terminal sends a Telnet Window Size reply (e.g. SyncTERM), then
  either size terminal should fine on either port.
  The port numbers are configurable in the [BBS] section of your sbbs.ini
  file using the new keys: PET40Port (default value: 64) and PET80Port
  (default value: 128). Having these keys set doesn't make make the terminal
  server listen on that additional port - you'll need to add more
  IP:port combinations to one of Interfaces values, example:
    TelnetInterface=71.95.196.34,71.95.196.34:64,71.95.196.34:128
  And you don't have to use Telnet for the PETSCII connections - you could use
  RLogin or SSH instead (or in addition).

- support for terminal widths < 80 columns:
  This was achieved through a combination of text.dat changes (numerous),
  new Ctrl-A and @-codes and new optional terminal-width-specific menu files
  (e.g. text/menu/main.40col.asc)
  A side effect of these changes is actually better support for terminals
  *wider* than 80 columns as well!

- support for terminals that don't expand tabs to spaces (e.g. PETSCII):
  The terminal server now handles tab expansion with a run-time settable
  tab-size (default size: 8)

- conditional access based on PETSCII (or small) terminal use (or not):
  + New PETSCII ARS keyword (boolean)
  + New COLS and ROWS ARS keywords (for terminal width and height requirements)
  + New TERM (string) ARS keyword

New @-codes:
  - WORDWRAP, when placed at the top of a file, enables auto-wordwrap for
              lines longer than the terminal width
  - CENTER, the text following before an end of line will be displayed centered
            on the terminal (whatever the width, in columns)
  - CLEAR, like CLS, except it ignores (doesn't display) a CRLF that follows
  - COLS, current number of terminal columns (width)
  - ROWS, current number of terminal rows (height)
  - TERM, the auto-detected or reported terminal type (e.g. ANSI, TTY, etc.)
  - SYSONLY, toggles "echo" (display) off/back-on for non-sysops
            similar to the Ctrl-A( and ) codes, but more convenient to use
            (and PabloDraw won't strip the @-code from the file like it does
             with Ctrl-A codes it doesn't support)

New Ctrl-A codes:
  - \ conditional new-line/continuation when the terminal width is < 80 cols
      prints the new text.dat string LongLineContinuationPrefix

yesno() will now return true if passed a blank string.
noyes() will now return false if passed a blank string.
getstr()'s input length limiting based on terminal width is more broadly
           applied now (not just when using the K_LINE mode flag).

New JS bbs object method: menu_exists(<base_filename>) returns Boolean
New JS console object property: tabstop (Number)
New JS console object methods: getbyte() and putbyte() to recv/send raw byte
    value with (very little) interpretation/intervention by the terminal server
New JS console object method: creturn() - performs a carriage return
    (or equivalent)
New JS (and C) printfile() mode flag: P_TRUNCATE, causes long lines to be
    truncated, rather than displaying causing a line-wrap.

New text.dat strings:
  - NoAccessTerminal (for ARS check failures)
  - LongLineContinuationPrefix (for breaking long lines for 40col terminals)
  - Scanning (replaces a previously hard-coded "Scanning" string)
  - Done (replaces a previusly hard-coded "Done")
  - Scanned  (when finished scannning, clears the progress bar)

(stops parsing/displaying upon Ctrl-Z) - this solves the SAUCE record
issue for sysops (e.g. using PabloDraw).

Also, free() temp variables for RSA keys.

of the passed filei, fixing a long-standing issue with a couple of menu
commands (e.g. "MAININFO") in the WWIV (and possibly other) command shells.
Thank Nelgin. Are we keeping count yet?