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
--
...wherever the people are well-informed, they can be trusted with their own government.
                                                   -- Thomas Jefferson

Attachment: pgpnhU7oBiPgu.pgp
Description: PGP signature

Reply via email to