Re: [Mutt] #3040: charset difference between index browser and pager
#3040: charset difference between index browser and pager
Comment (by Kyle Wheeler):
{{{
On Tuesday, March 18 at 09:21 PM, quoth Mutt:
>> It's possible that your name is being mis-encoded in email, and so
>> it is taking various paths through mutt on the way to being
>> displayed based on whether mutt notices the problem or not.
>
> The content type of the email showing this problem is set to us-ascii,
The content-type is irrelevant; all headers are required to be in
us-ascii. The detail that matters is how they are encoded. I don't
know how your firstname is supposed to be encoded (if you'd sent an
email to the mailing list, I could see what mutt is doing with your
email), but generally these things are encoded according to RFC 2047.
They end up looking like this:
=?iso-8859-1?q?this=20is=20some=20text?=
> so this might indeed be a problem. But for a user I would expect
> that mutt would either _always_ fail to correctly display this name,
> or would do it correctly in the index_browser and in the pager.
>
> So I would still consider this a bug in mutt...
There is no reason to expect that badly encoded things will always be
displayed the exact same way. For example, in the index_browser, there
are often character limits to what is displayed---such as in your
case, you have limited the display of the From header to 18
characters. If a header is poorly encoded, mutt may not realize that
the header is actually encoded with multi-byte characters, and so will
simply use the first 18 *bytes*. If byte 18 is the beginning of a
multibyte character, this can potentially be sent to your terminal
unmodified. Thus, what you see will reflect your terminal's
error-recovery mode rather than anything mutt intended to display.
However, in the pager, mutt still doesn't realize that there's
something wrong with the header, but displays the whole thing---and
now your terminal may not go into error recovery, but may recognize
that it is simply a correctly encoded multibyte character, and it will
look correct in the pager despite being incorrectly encoded from the
beginning.
That's one example, but there are infinitely many more. My point is
that expecting invalidly-encoded email to be displayed consistently is
not giving sufficient credit to the size of the problem (or how much
of it is outside mutt's control). You are dealing with the confluence
of mutt's own ability to recognize improper encoding, mutt's settings
(which may be incorrect), your environment variables (which may be
incorrect and inconsistent with each other and with mutt's settings),
the ability of the libraries that mutt relies on to detect problems
(they have access to the environment variables but not mutt's internal
settings), and finally your terminal, which has its own settings
(which may be incorrect or inconsistent) and its own error-recovery
methods.
~Kyle
}}}
--
Ticket URL: <http://dev.mutt.org/trac/ticket/3040#comment:>