Date: Wed, 14 Aug 2013 13:20:36 -0400
From: Austin Clements <amdragon@MIT.EDU>
To: Tomi Ollila <tomi.ollila@iki.fi>
Subject: Re: [PATCH 0/6] Clean up reply's encoding story
Message-ID: <20130814172036.GF13257@mit.edu>
References: <1376332839-22825-1-git-send-email-amdragon@mit.edu>
	<m2zjskjjat.fsf@guru.guru-group.fi>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <m2zjskjjat.fsf@guru.guru-group.fi>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: notmuch@notmuchmail.org
Precedence: list

Quoth Tomi Ollila on Aug 14 at  8:04 pm:
> On Mon, Aug 12 2013, Austin Clements <amdragon@MIT.EDU> wrote:
> 
> > Jeff Stedfast's email about gmime-filter-headers.c possibly being
> > unnecessary with GMime 2.6 (quoted in id:87bo56viyo.fsf@nikula.org)
> > sent me on a wild goose chase that led to this patch series.  It
> > turned out that we *did* need gmime-filter-headers for what we were
> > doing in the reply text format, but what we were doing made no sense.
> > Patches 1 through 4 are simply the documentation and tests that I left
> > in my wake and are harmless to push.  Patch 6 is my conclusion that
> > how we were handling header encoding in the text reply format made no
> > sense.  Patch 5 is a step toward patch 6, but makes sense on its own
> > even if we decide against patch 6.
> 
> The whole series Looks Good To Me (sans known hiccups). I tested the patch 6
> affecting 'default' output of notmuch reply bot not json or sexp output
> (which I found surprising as so much code was removed). All the explations
> in id:1376332839-22825-7-git-send-email-amdragon@mit.edu makes good sense
> (but fix also 'tmeplate').
> 
> A slighly related note: ^M:s ^J:s (among other chars) don't get encoded
> into =?utf-8?b?...?= ...

Do you mean when sending mail, or when replying to a message with
encoded ^Ms and ^Js?

> ... also interestingly if U+202E (LEFT-TO-RIGHT OVERRIDE) is in (at least
> From) header it disappears from `notmuch reply` default format. In json
> and sexp format it disappears in 'reply-headers' but exists in 'headers'.
> emacs client seems to use reply-headers as none of the header text lines
> in buffer is  rendered RTL.

Cool.  My guess would be that one of these it coming from notmuch's
internal header parser (via notmuch_message_get_header) and the other
is coming from GMime's header parser (used in notmuch-show.c)