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)