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?...?= ... ... 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@notmuchmail.org > http://notmuchmail.org/mailman/listinfo/notmuch