1. 02 Aug, 2019 5 commits
    • rswindell's avatar
      Use the \1FLAGS KFS (parsed crudely from netmail .msg body text) to trigger · 73a97840
      rswindell authored
      file-attachment deletion in write_flofile() - not the KILLSENT attribute flag.
      Export the SMB MSG_KILLSENT auxattr from SMB mail to FTN netmail \1FLAGS KFS.
    • rswindell's avatar
      If SBBSecho imports a message with a "CHRS" control line with a value of · 5617b0f2
      rswindell authored
      "UTF-8", set the msg's auxattr MSG_HFIELDS_UTF8 flag because FTS-5003 states:
        "The character set identifier applies to all parts of the message,
         including the header information and the control lines like origin
         and tear line."
    • rswindell's avatar
      Use the RFC822* header fields, only when the actual header fields are · 1da741bb
      rswindell authored
      If any RFC822* header field is a MIME-encoded UTF-8 string, then set the
      (new) auxattr MSG_HFIELDS_UTF8 flag. This will be used (soon, hopefully) to
      display UTF-8 encoded header fields to users. There's a gotchas here:
      - MIME-encoded header fields with other non-ASCII/8-bit charsets (e.g. CP437,
        ISO-8859) are still stored "as decoded", though the MSG_HFIELDS_UTF8 flag
        may be set *later* (which would be weird), resulting in a mixture of valid
        and invalid UTF-8 header fields. One solution would be to UTF-8-transcode all
        the non-UTF-8 header fields if *any* of them are UTF-8, but we wouldn't
        know which charset to translate *from*. Assuming CP437 isn't going to be
        correct 100% of the time - so punt for now and deal with it at display
        time. e.g. if the MSG_HFIELD_UTF8 auxattr flag is set, but an hfield contains
        invalid UTF-8 data, don't display as UTF-8 (e.g. treat as CP437). We don't
        have translations for other charsets (e.g. ISO-8859) setup yet anyway.
    • rswindell's avatar
      Make the minimum CTerm version for loadable-fonts support rev 1.155 (1155) · 875ec183
      rswindell authored
      - this is the version used in SyncTERM v1.0.
      I happened to try SyncTERM 0.9.5b recently (CTERm 1.151) and it failed
      to either load or activate loaded fonts, so: not-supported.
    • rswindell's avatar
      Add listReverse() - popular interview question, no need for use right now · 110468f7
      rswindell authored
      Add listVerify() - confirm the list is sane
  2. 01 Aug, 2019 4 commits
  3. 31 Jul, 2019 3 commits
  4. 30 Jul, 2019 9 commits
    • rswindell's avatar
      Define some new SMB hfield types: · a8709616
      rswindell authored
      - REPLYTOLIST (a mime-decoded version of RFC822REPLYTO)
      - RECIPIENTLIST (a mime-decoded version of RC822TO)
      - RFC822CC (a mime-encoded version of SMB_CARBONCOPY)
      - RFC822ORG (a mime-encoded version of SMB_ORGANIZATION)
      - RFC822SUBJECT (a mime-encoded version of SUBJECT)
      The RFC822* hfields are only created when necessary: there was a MIME-encoded
      hfield value received (e.g. by the mailsrvr) for the corresponding hfield.
      The to_list and replyto_list convenience pointers now point to the MIME-decoded
      (plain text) version of these header fields, since that's what everyone
      normally wants to see and use.
      The MIME-encoded flavors (RFC822*) are stored for relaying via SMTP or POP3
      and retaining all data (no normalization or decoding).
      A new auxattr bit has been defined: MSG_HFIELDS_UTF8 (happens to be the same
      as P_UTF8 - snicker). This bit will be set in msg.hdr.auxattr when one or more
      hfield values are in UTF-8 format. When this flag is not set, all hfield values
      are assumed to be CP437 for backwards compatibility.
      Since we are using a single flag, all header fields have to use the same
      encoding (either CP437 or UTF-8). When the hfield values are all plain ASCII,
      there's no difference between CP437 and UTF-8 and the MSG_HFIELDS_UTF8 flag
      is not expected to be set, though setting it shouldn't hurt. The RFC822* hfield
      values should also include US-ASCII text (using MIME-encoding for any 8-bit
      smb_get_hfield() function prototype change: the 3rd argument changed from
      an hfield_t* to an hfield_t**, so that the caller can actually change the
      hfield type (in memory) if they wish. Nobody seemed to be passing any non-NULL
      3rd argument value, so this changed appeared safe to make.
    • rswindell's avatar
      Clarify the help text of the AUTO-UTF8 option a bit more (it's detected · 6c8526f0
      rswindell authored
      during *display* in the terminal server, so this option would help, say,
      the web server).
    • rswindell's avatar
      Allow the P_AUTO_UTF8 mode to be set in a sub's pmode setting (for auto-detect · b677fa38
      rswindell authored
      of UTF-8 message text).
      Remember the "bar" position of sub toggle options (now that they scroll).
    • rswindell's avatar
      Define and use Unicode code points 0x2015 through 0x2021 in unicode_to_cp437() · b87338ca
      rswindell authored
      for some obvious (but missing) mappings.
    • rswindell's avatar
    • rswindell's avatar
      For Mark Lewis: · 2e591193
      rswindell authored
      When writing non-bundle file paths/names to BSO/FLO files, don't use the
      delete (^) prefix unless the message has the "Kill Sent" attribute set. This
      seems kind of wrong to me. The KFS "Kill File Sent" flag has been defined in
      FSC-0053 since 1992, that seems more likely the appropriate flag to determine
      if a message attachment should be deleted (or not) after being sent. But
      parsing/using the "Flags" control line flags isn't already in SBBSecho, so
      I'll just punt for now and do what Mark asked for. <shrug>
    • rswindell's avatar
      Remove unused variable. · a62b1982
      rswindell authored
    • rswindell's avatar
      Don't word-wrap ANSI-encoded message text. · 7e93eae2
      rswindell authored
    • rswindell's avatar
      Don't display transfer paths as always lower case. This confuses users who · 7cf08b7d
      rswindell authored
      use mixed or upper-case for their Transfer File Paths.
  5. 29 Jul, 2019 1 commit
  6. 28 Jul, 2019 1 commit
    • nightfox's avatar
      Version 1.23: If a message is in UTF-8 format and the user's terminal doesn't... · d24a672e
      nightfox authored
      Version 1.23: If a message is in UTF-8 format and the user's terminal doesn't support UTF-8, the message text will be converted to CP437.  Also, if there is a color/attribute code in the message before the message text and there are no other color/attribute codes, the color/attribute codes will be removed so  that the entire message isn't colored
  7. 27 Jul, 2019 2 commits
    • echicken's avatar
      Skip deleted msgs. · 512a95da
      echicken authored
    • rswindell's avatar
      Added support to console.print() for an optional P_* mode argument. Must · 2f0381d2
      rswindell authored
      be called as console.print(string, number), the number will be interpretted
      as the P_* mode flags value. Otherwise, all arguments are converted to strings
      and printed (as before).
      If anyone was calling console.print(string, number), they will get different
      behavior now. I couldn't find any evidence of anyone using this syntax for
      console.print(), so I think this should be okay.
      Only a limited set of P_* flags are supported (e.g. P_PETSCII, P_UTF8) - far
      fewer than console.putmsg(), but console.putmsg() is much more heavy weight
      and supports a lot more "features" likely to interfere with the expected user
      output. In general, try to use console.putmsg() only when printing multi-line
      text strings or when @-code expansion is needed. Otherwise, console.print()
      is usually better.
  8. 26 Jul, 2019 15 commits