what was *not* an iconv-related Heisenbug ...
or: why you should *always* test things with a clean configuration.
I just wasted an hour or two trying to track down what I thought to
be an entirely strange bug in mutt. Or maybe in libc. Or
whereever.
Here's what I was about to send to the list:
>It irks me that I don't get this one figured out... Anyway, here's
>what I've got.
>
>I run mutt in an utf-8 environment (on Fedora Core 5; latest updates
>there) these days, and occasionally see utf-8 characters decomposed
>into garbage in the pager. Example message attached.
>
>The problem seems to occur exclusively when the message is displayed
>from the index (i.e., through the mutt_display_message code path).
>In that case, spying on mutt's temporary files shows that the
>recoding goes wrong already -- so, this is *not* a pager bug.
>
>However, when the body of the message is displayed through the
>recvattach menu (mutt_display_attachment code path), both the
>temporary file and the display in the pager look entirely ok.
>
>To make it all a bit more interesting, this seems to be a data
>dependent problem: Take the sample message, replace the =D6 in the
>quoted-printable material by =D7, try again: The message should
>display properly through both display paths.
For good measure, just before sending that message, I did a quick
test with -n -F /dev/null. And there I was looking pretty darn
stupid: The message always displays properly.
Unless, well, unless you've got an old and forgotten "fix that
windows crap" display_filter in your configuration which assumes
that the surrounding system operates in a iso-8859-15 locale and
windows-something data, and therefore messes up certain utf-8
character sequences...
I've fixed the copy of the problem in contrib/sample.muttrc-tlr.
Happy Thanksgiving,
--
Thomas Roessler <roessler@xxxxxxxxxxxxxxxxxx>