[RFC PATCH] cli/show: include content type parameters in formatted output

[RFC PATCH] cli/show: include content type parameters in formatted output

[Jani Nikula]

This is primarily to be able to handle "text/plain; format=flowed",
but I don't see much point in making this specific to
format=flowed. Just include all content type parameters in the
formatted output, like this:

	"content-type" : "text/plain",
	"content-type-params" : [
		{
			"format" : "flowed"
		}
	],

It might make sense to change the content-type key in schemata to
include the parameters in a more structured fashion instead of adding
a separate key like here, but this doesn't require a change in
consumers or schemata version bump.

This was just a quick proof of concept, and obviously lacks tests,
schemata updates, etc.
---
 notmuch-show.c | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/notmuch-show.c b/notmuch-show.c
index 22fa655ad20d..7100b2d0b578 100644
--- a/notmuch-show.c
+++ b/notmuch-show.c
@@ -601,6 +601,19 @@ format_part_sprinter (const void *ctx, sprinter_t *sp, mime_node_t *node,
     sp->map_key (sp, "content-type");
     sp->string (sp, g_mime_content_type_to_string (content_type));
 
+    const GMimeParam *params = g_mime_content_type_get_params (content_type);
+    if (params) {
+	sp->map_key (sp, "content-type-params");
+	sp->begin_list (sp);
+	sp->begin_map (sp);
+	for (; params; params = params->next) {
+	    sp->map_key (sp, params->name);
+	    sp->string (sp, params->value);
+	}
+	sp->end (sp);
+	sp->end (sp);
+    }
+
     if (cid) {
 	sp->map_key (sp, "content-id");
 	sp->string (sp, cid);
-- 
2.11.0

[REBASED RFC PATCH] cli/show: include content type parameters in formatted output

[Jani Nikula]

This is primarily to be able to handle "text/plain; format=flowed",
but I don't see much point in making this specific to
format=flowed. Just include all content type parameters in the
formatted output, like this:

	"content-type" : "text/plain",
	"content-type-params" : [
		{
			"format" : "flowed"
		}
	],

It might make sense to change the content-type key in schemata to
include the parameters in a more structured fashion instead of adding
a separate key like here, but this doesn't require a change in
consumers or schemata version bump.

This was just a quick proof of concept, and obviously lacks tests,
schemata updates, etc.
---
 notmuch-show.c | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/notmuch-show.c b/notmuch-show.c
index 744b62727c26..866b974fcefa 100644
--- a/notmuch-show.c
+++ b/notmuch-show.c
@@ -625,6 +625,19 @@ format_part_sprinter (const void *ctx, sprinter_t *sp, mime_node_t *node,
     sp->map_key (sp, "content-type");
     sp->string (sp, g_mime_content_type_to_string (content_type));
 
+    const GMimeParam *params = g_mime_content_type_get_params (content_type);
+    if (params) {
+	sp->map_key (sp, "content-type-params");
+	sp->begin_list (sp);
+	sp->begin_map (sp);
+	for (; params; params = params->next) {
+	    sp->map_key (sp, params->name);
+	    sp->string (sp, params->value);
+	}
+	sp->end (sp);
+	sp->end (sp);
+    }
+
     if (disposition) {
 	sp->map_key (sp, "content-disposition");
 	sp->string (sp, disposition);
-- 
2.11.0