himalaya --output json template reply/forward shows the raw buffer data (it should be discarded).

[EDIT]: in fact it should not be discarded, but it should show the raw message as string (not buffer). This way we align with the existing behaviour (it is useful for UIs).

@soywod When I started to rewatch the code I found the following:

• A robust type-safety change like here wouldn't be bad: Changing the parameter type of flags to our struct Flags
  Do you agree to this?

• I also found an issue when I tried to add a flag. In general I'd like to write some tests for the subcommands and so on first.

I'll wait for your respond first before I keep implementing (I've already started to adjust the Flags struct).

• The sender is always fully displayed (the long form Sender Name <[email protected]>. Only the name should be displayed, and if no name exists then the email address.
• The right part of a sender can be encoded. You forgot to decode it (with the rfc2047_decoder lib)

For example, let's take =?UTF-8?Q?Userame?= <[email protected]>. Himalaya's master branch shows Username, but your branch shows =?UTF-8?Q?Userame?= <[email protected]>

• The body does not contain the previous message.

Trying to find a solution for this case for example. Also thinking about a test trait... or not...

[] The raw should be excluded from the JSON export (#[serde(skip_serializing)])
[] The JSON export should be in camelCase, not in snake_case (#[serde(rename_all = "camelCase")])

himalaya --output plain template new/reply/forward does not show any template (blank line).

IMPORTANT

It looks like that error_chain is deprecated now! So I think that we should switch to another error handling-crate. I'd suggest thiserror. We could also combine it with anyhow. What do you think? @soywod

• The From header contains only the email address (it should contains the name if available My Name <[email protected]>
• The signature is missing
• The Subject header is missing

• The JSON output does not have the same shape (it misses hasAttachment)
• The JSOn output should show the text/html version of the mail if no text/plain is found.

Envelope

I'm a bit suspicious about the name "Envelope". Theoretically, the envelope is the container of the message. The struct looks more like headers for me. I checked what you put in the doc (about the Envelope of the crate imap_proto), and it matches well indeed. But imap_proto and himalaya are not on the same level: imap_proto is really low level, whereas himalaya is at the top level. The meaning of Envelope is not really the same. The 2 options I see so far is:

• Rename Envelope (sth like Headers for example)
• Use the imap_proto struct directly instead of creating our own one

Feel free to argue of course, maybe I miss some information.

Signature in envelope

I do not think the signature should be there. Also (it's not fully related to what you propose, it was already the case before), I'm half satisfied with how the signature is processed. It's a bit overwhelming. We never know when to append \n, how many of them etc. I thought about introducing a function like append_signature that takes in parameter a mutable body and appends the signature if exists. Feel free to propose btw.

Signature position in a forward message

I see that you put the signature before the quote in a forward message, what are your motivations? I think it should be after the quote instead. The default (and recommanded) option in Thunderbird is below the quote:

I may add more points in the future.

PS: don't think I'm bashing your work, in fact you did quite well (like the tests based on RFC examples, the try_from etc). I just list here all points that I partially agree with 😉

We already discussed this (#9), and I really think the signature should be below the forwarded message (not above). Later we could add an option for this, but for now I would prefer to stay "standard".