Version 1.03 - Bug fix: In Linux, when replying to the last message in a sub-board during a newscan or in read mode, it would not immediately refresh the messagebase information, so it would not see the new message posted.  This has been fixed by closing the messagebase while the user is posting a reply message and re-opening the messagebase when the user is done posting the reply.

SlyEdit v1.48 - Bug fix: When replying to certain messages, with quoting with author initials enabled, opening the quote window sometimes resulted in SlyEdit freezing due to what seemed to be an infinite loop when wrapping the quote lines.  That was caused by a calculated maximum line width coming out negative.

Lines made up entirely of whitespace always end with a hard CR.

LFs on write.

the mod state.  This should fix num-lock on Windows.

Other mod states (CTRL, SHIFT, ALT) are likely still messed up though.

any line that was ever damaged was always damaged, and it worked pretty well.

when updating the screen.

This should fix the weird long-delayed update issue.

the screen.  This fixes the phantom cursor issue.

Updated so that if the user is editing an existing message, SlyEdit won't prompt to add a tagline.  Keeping this one at version 1.47.

SlyEdit version 1.47: Updated to read the tagline filename from line 7 of the MSGINF dropfile.  If that line in MSGINF is available (starting with Synchronet 3.16 beta builds on July 5, 2015), then the user's chosen tagline will be written to the tagline file, and Synchronet will read that and append the tagline after the user's signature.  Otherwise, the tagline will appear before the user's signature in the message.

For regular vstatlock things, only hold the lock long enough to copy the
variables that will be used.

For vstat.vmem stuff, create a separate reference-counting vmem structure
and a new vmem_lock so the memcpy() of the vmem won't block basic vstat
accesses.

This appears to fix the recently-added "blockiness" of screen updates in
SyncTERM, without risking deadlocks or unlocked accesses... the major issue
holding up a release.

in scenarios where the tagfile may be used (e.g. not editing extended file
descriptions). This should allow SlyEdit and other extenal message editors
to detect the support for the editor.tag file dynamically rather than by
using the Synchronet version number. If the 7th line is blank or non-existent,
then the external editor tag file is not supported.
Overhauled editor_inf() to use a file stream/fprintf.

Version 1.46 - Fix: If the user is editing their signature file, SlyEdit won't ask the user if they want to add a tagline, even if their tagline setting is enabled.

SlyEdit 1.45: Tag line mechanism update - For Synchronet 3.16 and newer (starting with builds from June 22, 2015), the tag line will be written to editor.tag in the node's temp directory.  If editor.tag exists in the node's temp directory, Synchronet (version 3.16 and newer) will append the tag line(s) from that file after the user's signature.  For Synchronet version 3.15 and earlier, SlyEdit will write the tagline to the message instead of editor.tag - The result will be that if the user has a signature, the tag line will be before the user's signature.

temp directory (system.temp_dir in JS), sbbs will read in this file and append
it to the message body *after* the user's .sig file (if there is one).
Bug-fix: don't append .sig files when editing extended file descriptions.

the "embedded" splash screen instead.

issues.

Version 1.02: Bug fix in DDScanMsgs.js: Switched to bbs.scan_msgs() instead of bbs.scan_subs() for all other scan modes besides SCAN_READ.  Updated the version number to reflect that; no change to the actual reader.  Also fixed an error in the readme that said sbbs/subs when it should say sbbs/mods.

than executing the xtrn_sec module (xtrn_sec.js). Oops, now fixed.

In general, the log in/log out thing needs to be better tested for the case
where there is no "Guest" user account in the user base.

> !Javascript c:\sbbs\exec\newslink.js line 777:
> TypeError: hdr.extra_headers  is undefined
Appears to be caused by revision 1.101 of this file (commited in 2012):
not all messages will have "extra_headers", so the way this header field was
checked for existence could cause this error.

don't default to '/ecwebv3/', just default to a blank string (no appendage).