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. ? I wonder if this would be better in the documentation for --part. > Best wishes > > Mark