[notmuch] [PATCH] Decode headers in reply

[Carl Worth]

On Wed,  3 Mar 2010 08:50:56 +0100, Michal Sojka  wrote:
> When headers contain non-ASCII characters, they are encoded according
> to rfc2047. Nomtuch reply command emits the headers in the encoded
> form, which makes them hard to read by humans who compose the reply.

This feature is obviously extremely handy. So thank you, Michal! I've
now pushed this out.

I think the implementation is over-complicated, but that's almost
entirely the fault of GMime and GObject, not yours. We are creating a
GMime object to represent the message and then asking GMime to print
it. GMime then does what it should (assuming the message is going to be
sent over SMTP) and encodes the headers.

We don't happen to want this encoding, since the client wants to allow
the user to edit the message and only encode the final result. There is
a single function that GMime provides for the decoding
(g_mime_utils_header_decode_text) but arranging for GMime to call this
function on each header requires over 200 lines of code with the hideous
GObject boilerplate and a bunch of replicated parsing code.

Meanwhile, what's GMime actually doing for us here? We have the original
decoded strings in the first place. And we know how to print "Subject:",
"To:", and "From:". So what do we need GMime for the headers?

The only thing I can think of is that GMime is also inserting
RFC-compliant wrapping of long lines. But since we want to let the user
edit the subject, etc. anyway, don't we have to rely on the client to do
that *anyway*?

Incidentally, it looks like message-mode does have support to do
RCF-compliant line wrapping if I hit M-q (`fill-paragraph') on a long
Subject: line but it doesn't appear to do that automatically. Instead,
it will just send a non-RFC-compliant message if I just type a long
Subject line. That looks like yet another reason to have a
notmuch-message-mode that extends message-mode and fixes several issues
we've been identifying.

Back to the patch though, I have pushed this out, but I've also added a
TODO item for simplifying this stuff. I think a handful of calls to
printf would be much better than this big pile of GObject boilerplate
and ad-hoc parsing.

-Carl
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 

Re: [notmuch] [PATCH] Decode headers in reply

[Carl Worth]

On Wed,  3 Mar 2010 08:50:56 +0100, Michal Sojka sojk...@fel.cvut.cz wrote:
 When headers contain non-ASCII characters, they are encoded according
 to rfc2047. Nomtuch reply command emits the headers in the encoded
 form, which makes them hard to read by humans who compose the reply.

This feature is obviously extremely handy. So thank you, Michal! I've
now pushed this out.

I think the implementation is over-complicated, but that's almost
entirely the fault of GMime and GObject, not yours. We are creating a
GMime object to represent the message and then asking GMime to print
it. GMime then does what it should (assuming the message is going to be
sent over SMTP) and encodes the headers.

We don't happen to want this encoding, since the client wants to allow
the user to edit the message and only encode the final result. There is
a single function that GMime provides for the decoding
(g_mime_utils_header_decode_text) but arranging for GMime to call this
function on each header requires over 200 lines of code with the hideous
GObject boilerplate and a bunch of replicated parsing code.

Meanwhile, what's GMime actually doing for us here? We have the original
decoded strings in the first place. And we know how to print Subject:,
To:, and From:. So what do we need GMime for the headers?

The only thing I can think of is that GMime is also inserting
RFC-compliant wrapping of long lines. But since we want to let the user
edit the subject, etc. anyway, don't we have to rely on the client to do
that *anyway*?

Incidentally, it looks like message-mode does have support to do
RCF-compliant line wrapping if I hit M-q (`fill-paragraph') on a long
Subject: line but it doesn't appear to do that automatically. Instead,
it will just send a non-RFC-compliant message if I just type a long
Subject line. That looks like yet another reason to have a
notmuch-message-mode that extends message-mode and fixes several issues
we've been identifying.

Back to the patch though, I have pushed this out, but I've also added a
TODO item for simplifying this stuff. I think a handful of calls to
printf would be much better than this big pile of GObject boilerplate
and ad-hoc parsing.

-Carl


pgpMAf0jrxoy0.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[notmuch] [PATCH] Decode headers in reply

[Michal Sojka]

When headers contain non-ASCII characters, they are encoded according
to rfc2047. Nomtuch reply command emits the headers in the encoded
form, which makes them hard to read by humans who compose the reply.

For example instead of "Subject: Re: Rozlu??ka" one currently sees
"Subject: Re: =?iso-8859-2?q?Rozlu=E8ka?=".

This patch adds a new GMime filter which is used to decode headers to
UTF-8 and uses this filter when notmuch reply outputs headers.

Signed-off-by: Michal Sojka 
---
I tested this patch with valgrind to debug some invalid writes in an
earlier version of the patch. There are no such problems in this
version, but valgrind reports many memory leaks (even on master
branch). I'm not sure whether these are false positives or not.

 Makefile.local |1 +
 gmime-filter-headers.c |  263 
 gmime-filter-headers.h |   69 +
 notmuch-reply.c|   26 -
 4 files changed, 354 insertions(+), 5 deletions(-)

diff --git a/Makefile.local b/Makefile.local
index 04bac83..0cacb5f 100644
--- a/Makefile.local
+++ b/Makefile.local
@@ -4,6 +4,7 @@ notmuch_client_srcs =   \
$(notmuch_compat_srcs)  \
debugger.c  \
gmime-filter-reply.c\
+   gmime-filter-headers.c  \
notmuch.c   \
notmuch-config.c\
notmuch-count.c \
diff --git a/gmime-filter-headers.c b/gmime-filter-headers.c
new file mode 100644
index 000..2f3df80
--- /dev/null
+++ b/gmime-filter-headers.c
@@ -0,0 +1,263 @@
+/*
+ * Copyright ?? 2009 Keith Packard 
+ * Copyright ?? 2010 Michal Sojka 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation, either version 3 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
+ */
+
+#include "gmime-filter-headers.h"
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/**
+ * SECTION: gmime-filter-headers
+ * @title: GMimeFilterHeaders
+ * @short_description: Add/remove headers markers
+ *
+ * A #GMimeFilter for decoding rfc2047 encoded headers to UTF-8
+ **/
+
+
+static void g_mime_filter_headers_class_init (GMimeFilterHeadersClass *klass);
+static void g_mime_filter_headers_init (GMimeFilterHeaders *filter, 
GMimeFilterHeadersClass *klass);
+static void g_mime_filter_headers_finalize (GObject *object);
+
+static GMimeFilter *filter_copy (GMimeFilter *filter);
+static void filter_filter (GMimeFilter *filter, char *in, size_t len, size_t 
prespace,
+  char **out, size_t *outlen, size_t *outprespace);
+static void filter_complete (GMimeFilter *filter, char *in, size_t len, size_t 
prespace,
+char **out, size_t *outlen, size_t *outprespace);
+static void filter_reset (GMimeFilter *filter);
+
+
+static GMimeFilterClass *parent_class = NULL;
+
+GType
+g_mime_filter_headers_get_type (void)
+{
+   static GType type = 0;
+
+   if (!type) {
+   static const GTypeInfo info = {
+   sizeof (GMimeFilterHeadersClass),
+   NULL, /* base_class_init */
+   NULL, /* base_class_finalize */
+   (GClassInitFunc) g_mime_filter_headers_class_init,
+   NULL, /* class_finalize */
+   NULL, /* class_data */
+   sizeof (GMimeFilterHeaders),
+   0,/* n_preallocs */
+   (GInstanceInitFunc) g_mime_filter_headers_init,
+   NULL/* value_table */
+   };
+
+   type = g_type_register_static (GMIME_TYPE_FILTER, 
"GMimeFilterHeaders", , (GTypeFlags) 0);
+   }
+
+   return type;
+}
+
+
+static void
+g_mime_filter_headers_class_init (GMimeFilterHeadersClass *klass)
+{
+   GObjectClass *object_class = G_OBJECT_CLASS (klass);
+   GMimeFilterClass *filter_class = GMIME_FILTER_CLASS (klass);
+
+   parent_class = (GMimeFilterClass *) g_type_class_ref 
(GMIME_TYPE_FILTER);
+
+   object_class->finalize = g_mime_filter_headers_finalize;
+
+   filter_class->copy = filter_copy;
+   filter_class->filter = filter_filter;
+   filter_class->complete = filter_complete;
+   filter_class->reset = filter_reset;
+}
+
+static void
+g_mime_filter_headers_init (GMimeFilterHeaders *filter, 
GMimeFilterHeadersClass *klass)
+{
+   (void) klass;
+