[PATCH 0/6] Clean up reply's encoding story

[Tomi Ollila]

On Mon, Aug 12 2013, Austin Clements <amdragon at MIT.EDU> wrote:

> Jeff Stedfast's email about gmime-filter-headers.c possibly being
> unnecessary with GMime 2.6 (quoted in id:87bo56viyo.fsf at 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 at 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?...?= ...

... 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.


Tomi

>
>
> _______________________________________________
> notmuch mailing list
> notmuch at notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch