26/fba8c190983974e482e7024b2235578951edfe

   1 Return-Path: <cworth@cworth.org>\r
   2 X-Original-To: notmuch@notmuchmail.org\r
   3 Delivered-To: notmuch@notmuchmail.org\r
   4 Received: from localhost (localhost [127.0.0.1])\r
   5         by olra.theworths.org (Postfix) with ESMTP id C1EAD4196F2\r
   6         for <notmuch@notmuchmail.org>; Tue, 13 Apr 2010 10:14:23 -0700 (PDT)\r
   7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
   8 X-Spam-Flag: NO\r
   9 X-Spam-Score: -2.89\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=-2.89 tagged_above=-999 required=5\r
  12         tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, T_MIME_NO_TEXT=0.01]\r
  13         autolearn=ham\r
  14 Received: from olra.theworths.org ([127.0.0.1])\r
  15         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
  16         with ESMTP id smj3gvDJz9ZT; Tue, 13 Apr 2010 10:14:22 -0700 (PDT)\r
  17 Received: from yoom.home.cworth.org (localhost [127.0.0.1])\r
  18         by olra.theworths.org (Postfix) with ESMTP id A3622431FC1;\r
  19         Tue, 13 Apr 2010 10:14:22 -0700 (PDT)\r
  20 Received: by yoom.home.cworth.org (Postfix, from userid 1000)\r
  21         id 41F765883A6; Tue, 13 Apr 2010 10:14:22 -0700 (PDT)\r
  22 From: Carl Worth <cworth@cworth.org>\r
  23 To: Michal Sojka <sojkam1@fel.cvut.cz>, notmuch@notmuchmail.org\r
  24 Subject: Re: [notmuch] [PATCH] Decode headers in reply\r
  25 In-Reply-To: <1267602656-24940-1-git-send-email-sojkam1@fel.cvut.cz>\r
  26 References: <87r5o1etjb.fsf@steelpick.localdomain>\r
  27         <1267602656-24940-1-git-send-email-sojkam1@fel.cvut.cz>\r
  28 Date: Tue, 13 Apr 2010 10:14:22 -0700\r
  29 Message-ID: <87hbnfl1g1.fsf@yoom.home.cworth.org>\r
  30 MIME-Version: 1.0\r
  31 Content-Type: multipart/signed; boundary="=-=-=";\r
  32         micalg=pgp-sha1; protocol="application/pgp-signature"\r
  33 X-BeenThere: notmuch@notmuchmail.org\r
  34 X-Mailman-Version: 2.1.13\r
  35 Precedence: list\r
  36 List-Id: "Use and development of the notmuch mail system."\r
  37         <notmuch.notmuchmail.org>\r
  38 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  39         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  40 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  41 List-Post: <mailto:notmuch@notmuchmail.org>\r
  42 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  43 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  44         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  45 X-List-Received-Date: Tue, 13 Apr 2010 17:14:23 -0000\r
  46 \r
  47 --=-=-=\r
  48 \r
  49 On Wed,  3 Mar 2010 08:50:56 +0100, Michal Sojka <sojkam1@fel.cvut.cz> wrote:\r
  50 > When headers contain non-ASCII characters, they are encoded according\r
  51 > to rfc2047. Nomtuch reply command emits the headers in the encoded\r
  52 > form, which makes them hard to read by humans who compose the reply.\r
  53 \r
  54 This feature is obviously extremely handy. So thank you, Michal! I've\r
  55 now pushed this out.\r
  56 \r
  57 I think the implementation is over-complicated, but that's almost\r
  58 entirely the fault of GMime and GObject, not yours. We are creating a\r
  59 GMime object to represent the message and then asking GMime to print\r
  60 it. GMime then does what it should (assuming the message is going to be\r
  61 sent over SMTP) and encodes the headers.\r
  62 \r
  63 We don't happen to want this encoding, since the client wants to allow\r
  64 the user to edit the message and only encode the final result. There is\r
  65 a single function that GMime provides for the decoding\r
  66 (g_mime_utils_header_decode_text) but arranging for GMime to call this\r
  67 function on each header requires over 200 lines of code with the hideous\r
  68 GObject boilerplate and a bunch of replicated parsing code.\r
  69 \r
  70 Meanwhile, what's GMime actually doing for us here? We have the original\r
  71 decoded strings in the first place. And we know how to print "Subject:",\r
  72 "To:", and "From:". So what do we need GMime for the headers?\r
  73 \r
  74 The only thing I can think of is that GMime is also inserting\r
  75 RFC-compliant wrapping of long lines. But since we want to let the user\r
  76 edit the subject, etc. anyway, don't we have to rely on the client to do\r
  77 that *anyway*?\r
  78 \r
  79 Incidentally, it looks like message-mode does have support to do\r
  80 RCF-compliant line wrapping if I hit M-q (`fill-paragraph') on a long\r
  81 Subject: line but it doesn't appear to do that automatically. Instead,\r
  82 it will just send a non-RFC-compliant message if I just type a long\r
  83 Subject line. That looks like yet another reason to have a\r
  84 notmuch-message-mode that extends message-mode and fixes several issues\r
  85 we've been identifying.\r
  86 \r
  87 Back to the patch though, I have pushed this out, but I've also added a\r
  88 TODO item for simplifying this stuff. I think a handful of calls to\r
  89 printf would be much better than this big pile of GObject boilerplate\r
  90 and ad-hoc parsing.\r
  91 \r
  92 -Carl\r
  93 \r
  94 --=-=-=\r
  95 Content-Type: application/pgp-signature\r
  96 \r
  97 -----BEGIN PGP SIGNATURE-----\r
  98 Version: GnuPG v1.4.10 (GNU/Linux)\r
  99 \r
 100 iD8DBQFLxKZu6JDdNq8qSWgRApiaAJsG+N+0E7L//JWZCRgm6KohIIX3bgCghJpZ\r
 101 GwSPBPUW3nb4BogjszC0S9Y=\r
 102 =sA6V\r
 103 -----END PGP SIGNATURE-----\r
 104 --=-=-=--\r