1. 01 Aug, 2019 3 commits
  2. 31 Jul, 2019 3 commits
  3. 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.
  4. 29 Jul, 2019 1 commit
  5. 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
  6. 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.
  7. 26 Jul, 2019 19 commits
  8. 25 Jul, 2019 2 commits