From: Carl Worth <cworth@cworth.org>
To: Michal Sojka <sojkam1@fel.cvut.cz>, notmuch@notmuchmail.org
Subject: Re: [notmuch] [PATCH] Decode headers in reply
In-Reply-To: <1267602656-24940-1-git-send-email-sojkam1@fel.cvut.cz>
References: <87r5o1etjb.fsf@steelpick.localdomain>
	<1267602656-24940-1-git-send-email-sojkam1@fel.cvut.cz>
Date: Tue, 13 Apr 2010 10:14:22 -0700
Message-ID: <87hbnfl1g1.fsf@yoom.home.cworth.org>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-=";
	micalg=pgp-sha1; protocol="application/pgp-signature"
Precedence: list

--=-=-=

On Wed,  3 Mar 2010 08:50:56 +0100, Michal Sojka <sojkam1@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

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iD8DBQFLxKZu6JDdNq8qSWgRApiaAJsG+N+0E7L//JWZCRgm6KohIIX3bgCghJpZ
GwSPBPUW3nb4BogjszC0S9Y=
=sA6V
-----END PGP SIGNATURE-----
--=-=-=--