On 07/23/2013 07:39 AM, David Bremner wrote:
> Franz Fellner <alpine.art.de@gmail.com> writes:
> 
>>
>> OK, thx. So every app needs to get patched to display those strings
>> properly? Any chance this could be done directly in libnotmuch?  I
>> grepped for "2047" inside te "emacs" subtree, but found nothing (had
>> the hope for a comment for the workaround). Would be interesting to
>> see how this is done, so I can at least try to create a patch (though
>> my ruby is quite basic).
> 
> In general notmuch relies on libgmime for rfc2047 parsing.  I'm not sure
> of all the details now, but some of the filtering does happen in the
> CLI, not the lib.  You could start by looking at
> gmime-filter-headers.[ch] in the top directory.

I agree this should be handled properly by gmime.  If it turns out that
the library is misbehaving (i.e. that notmuch is using it sensibly and
we're still getting bad data out of well-formed strings), it should be
reported and fixed there.

Just a note that other MUAs are struggling with this sort of thing too:

http://blog.steve.org.uk/international_character_sets_and_encodings_are_hard_.html

Steve Kemp (author of lumail) has good engineering skills and instincts;
anyone actively working on trying to get this fixed "right" within
notmuch (or underlying libraries) could probably drop him an e-mail and
collaborate.  With a decent diagnostic of the specific problems and use
cases, plus a recommendation for where the fix should be and how it
should be done, the two projects together could probably exert
sufficient influence on underlying libraries and toolchains to get them
to address any issues.

sorry to just provide links and not any actual analysis and code.

	--dkg