<<< Date Index >>>     <<< Thread Index >>>

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>