Relates to feature request #285.

Since users can (and usually do) display extended descriptions in their normal file listings anyway, it makes sense to go ahead and search them for the text (e.g. with the 'F' command from the default command shell File menu/prompt). So the "search/display extended info" prompt has been changed to just "Display extended file info" since it no longer controls whether or not the extended description is searched for the text (it always is). The FL_EXFIND was renamed to FL_EXT and only controls whether the extended info is display (the FL_FIND mode flag, always renamed, must also be specified for a find with extended info).

This closes feature request #285 by Phil (@plt).

WWIV writes 2 lines of metadata to the beginning of its quotes.txt file created for external message editors. Its not clear yet what these lines should contain, but the first line apparently should contain a '#' character since BREdit checks for this character before deciding to throw-away/ignore these lines (don't use them for quoted text). Thanks mlong for this tip!

So if the external editor is set to "WWIV CHAIN.TXT" in SCFG (even if the door doesn't need/use it), then the quotes.txt file created by Synchronet will contain the extra 2 lines. We're just writing a # to the first line and the second line is blank.

This fixes reported issue #188.

Slight usability improvement.

Expands to a percentage, similar to PCR (not capped at 100).

Remove the failed-attempt to cap the percentage at 100 for the PCR atcode.

Previously, the '*' matching pattern character could only be used as the beginning or ending character of a pattern string; for any other use, it was treated just as any other exact-match character.

Now, you can have exact-match characters on both the left and right sides of the '*', so pattern matching like the following is possible:

<*@gmail.com>
digital*man

Multiple '*'s are still not treated special (only the first/left-most '*" is), so, for example, "*blah*" will not likely produce the desired matching effect (use "blah~" instead for this case).

By setting guest_name, guest_email, guest_location, or guest_referral to any
truthy value, a prompt will be display. By setting it to a string (instead of
true), that string will be displayed. I'm not sure how I feel about this kind
of tri-state setting (true/false/string), but it does reduce the number of
settings/options. The alternative is to have a separate boolean and string
setting for each prompt (which I first considered).

So, as of now:

guest_name = false <- no prompt for Guest's name
guest_name = "" <- no prompt for Guest's name
guest_name = true (the default) <- default prompt text for Guest's name
guest_name = "Enter your name, dude" <- replaces prompt text for Guest's name

For enter trailing white-space and ctrl-a codes, use string literals, e.g.
guest_name: "\x01hEnter your name, dude: "

guest_name = false will disable name prompt
guest_email = false will disable the email address prompt
guest_location = false will disable the location prompt
guest_referral = false will disable the "where'd you hear about this BBS" prompt

Note, at minimum, I do recommend prompting for the guest's email address so that if they send the sysop feedback (e.g. ask a question), they at least have some hope of receiving a reply.

Eliminate some of the infrequent SPAM posts to the SYNCPROG conference. Maybe make this behavior configurable?

If anything, I suppose would be beep if a search fails, but really, I think beeps are kind of annoying these days. Not changing the currently selected/viewed user is likely all that's really needed to indicate a search failure.

Helpful for debugging issues with this forgery detection logic (if there are any).

When setting the value of a message's 'can_read' property, ignore the PRIVATE message attribute (which is sometimes set in FTN netmail messages) since it's assumed all messages in the mail base are private, no special destination (to) name matching is needed here.

This only popped up recently via msglist.js because of the recent addition of checking each messages's 'can_read' property.

As reported by <Diehard> via IRC PM.

Apparently required by some news servers.
As requested via IRC:
<poindexter> Hi all, I've got a weird request. I'd like to post to a newsgroup that relies on automoderation. You need to add an approved: header to any posting to have it be accepted - keeps the non-techie riffraff away. is there a way to do that with newslink.js?

Should fix unvalidated/moderated message readability bug reported by Phil

What took down cvs/sbbs yesterday:
Program terminated with signal SIGSEGV, Segmentation fault.
6203                    session->req.post_data[session->req.post_len]=0;
[Current thread is 1 (Thread 0x7f2b989ff700 (LWP 17031))]
(gdb) print post_len
No symbol "post_len" in current context.
(gdb) print session->req.post_len
$1 = 0
(gdb) print session->req.post_data
$2 = 0x0

Fixes issue #276

822header.js adds an enumerable method to the header object which ends up in the output when using the -hdrs option/command.

This addresses issue #277

Note: this is not actually a supported or documented script.