On Fri, 18 Apr 2014, Austin Clements <amdragon@MIT.EDU> wrote: > Quoth Mark Walters on Apr 18 at 8:23 pm: >> >> On Fri, 18 Apr 2014, Austin Clements <amdragon@MIT.EDU> wrote: >> > In addition to being generally more precise, this is explicit that >> > there is no charset conversion. >> > --- >> > doc/man1/notmuch-show.rst | 36 ++++++++++++++++++++---------------- >> > 1 file changed, 20 insertions(+), 16 deletions(-) >> > >> > diff --git a/doc/man1/notmuch-show.rst b/doc/man1/notmuch-show.rst >> > index bad868b..2c0f64c 100644 >> > --- a/doc/man1/notmuch-show.rst >> > +++ b/doc/man1/notmuch-show.rst >> > @@ -76,22 +76,26 @@ Supported options for **show** include >> > >> > http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/mail-mbox-formats.html >> > >> > - **raw** (default for a single part, see --part) >> > - For a message or an attached message part, the original, raw >> > - content of the email message is output. Consumers of this >> > - format should expect to implement MIME decoding and similar >> > - functions. >> > - >> > - For a single part (--part) the raw part content is output >> > - after performing any necessary MIME decoding. Note that >> > - messages with a simple body still have two parts: part 0 is >> > - the whole message and part 1 is the body. >> > - >> > - For a multipart part, the part headers and body (including >> > - all child parts) is output. >> > - >> > - The raw format must only be used with search terms matching >> > - single message. >> > + **raw** (default if --part is given) >> > + Write the raw bytes of the given MIME part of a message to >> > + standard out. For this format, it is an error to specify a >> > + query that matches more than one message. >> > + >> > + If the specified part is a leaf part, this outputs the >> > + body of the part after performing content transfer >> > + decoding (but no charset conversion). This is suitable for >> > + saving attachments, for example. >> > + >> > + For a multipart or message part, the output includes the >> > + part headers as well as the body (including all child >> > + parts). No decoding is performed because multipart and >> > + message parts cannot have non-trivial content transfer >> > + encoding. Consumers of this may need to implement MIME >> > + decoding and similar functions. >> > + >> > + Note that even a message with a simple body has two parts: >> > + part 0 is the whole message and part 1 is the body of the >> > + message. >> >> Generally this looks good. I wonder whether the paragraph above could be >> expanded slightly: my (quite possibly flawed) understanding is that >> simple messages don't need to be MIME encoded (at least some messages >> don't contain any mention of MIME). If this is correct then I think it >> would be worth clarifying that this paragraph applies even to non-MIME >> encoded messages. > > It's true that even "non-MIME" messages have two MIME parts. Are you > thinking something like > > Note that even a message with no MIME structure or a single body part > still has two MIME parts: part 0 is the whole message (headers and > body) and part 1 is just the body. > That sounds great. > ? > > I wonder if this would be better in the documentation for --part. I think that would make sense. Best wishes Mark