long lines in messages for the user's terminal. May be used for viewing other
files with long lines (e.g. G-text files) in the future.

for us (automatically).

to expose via JS: sender_userid, sender_server, and sender_time.

messages.

regardless of security level setting.
When run out of lines when creating/editing a file or msg, print a more
meaningful message, in text.dat update  (with the max lines allowed).

is to periodically call JS_YieldRequest from an operation callback."

sequences to SMB-style (CRLF). This resolves the issue of .sig files created
or edited with a Unix-style text editor and the resulting signature losing line
endings when being exported to FTN (for example).

(disabled)

the libmozjs from firefox et. al.

Maybe should log the fact that it's waiting...

are handled according to FTS-0001 and line feeds are ignored, the space will
still separate words.

This should fix the recent spate of replied messages losing spaces between
re-wrapped lines.

generated config files rather than patching the sources.

(As a side note, there is an Mk/bsd.gecko.mk!)

pthread headers.  Fixes problem linking JS on FreeBSD 9.0-RC1.

Don't pass -o and -u to unzip... just -o (-u contradicts -o)

of lines.

Also add ESC [ ? XXX s and ESC [ ? XXX u to save/restore modes controlled
by h and l.

via __STDC_FORMAT_MACROS

printf() formatting.

of (u)intmax_t by the Deucester.

This is *likely* to break the Win32 build and even when the macros are
specified in xpdev, I doubt Microsoft has added support for the 'z' size
specifier used in smblib/smbadd.c we'll likely need a SIZE_T_SIZE macro
that is "z" on C99 systems and "ll" or "64" or whatever it is on Win32.

Or maybe a whole slew of complete SIZE_T macros since the 32/64 but thing
and the max file size thing may actually need the full format specification
to be in the macro... "zu" on C99 platforms and whatever magic Microsoft
needs there.

resolve callbacks.

thread tell the echo thread to exit.

load()ed file, not argc

Restore background log dance... logging from background thread should work
now as long as the parent is still around... not sure what will happen when
the parent goes away though.

Since this requires a context in the same runtime and we're not sharing one big
runtime (yet), we'll copy it out of magic JS land and into more sane normal
heap land and JS_free() immediately.

This should fix teh Windows crash on queues that digitalman was seeing (and
the leak he added to fix it).