On Sat, 19 Nov 2011 03:45:05 +0400, Dmitry Kurochkin <dmitry.kurochkin@gmail.com> wrote:
> Before the change, notmuch used g_mime_content_type_to_string(3)
> function to output Content-Type header value.  Turns out it outputs
> only "type/subtype" part and ignores all parameters.  Also, if there
> is no Content-Type header, default "text/plain" value is used.

Hi, Dmitry.  Can you explain under what circumstances you would need the
extra content-type parameters?  It just seems like a lot of extra noise
in the output to me, but that's partially because I can't think of any
reason why something that is receiving pre-parsed mime content would
need it.  Maybe there's a better way to handle what you're trying to get
to.

I think it would help a lot if you could submit some sort of test
modification that demonstrates the issue.  This is one of the reasons we
keep emphasizing that it's good to first have tests in hand that
demonstrate issues before patches that address them.

>   "content": [{"id": 2,
> - "content-type": "text/plain",
>   "content": "This is a test signed message.\n"},

Without figuring out what's going on, I notice that some of the tests
have been modified to remove the content-type fields on a bunch of
parts.  I think that is probably not right.

jamie.