Re: index_format and <bar> vs <space>, segment fault
Hi Derek!
On Saturday, June 17, 2006 at 22:34:50 -0400, Derek D. Martin wrote:
> On Sat, Jun 17, 2006 at 01:23:01PM +0200, Alain Bench wrote:
>> On Friday, June 16, 2006 at 12:21:56 +0200, Ye Fei wrote:
>>> chinese characters can also be displayed correctly in [LANG=en_US]
>> That should *not* work.
> It shouldn't work, but it could, under certain circumstances...
Yes, by happy accidents. Ye Fei case:
· Chinese mail
· GBK $charset
· GBK terminal
· Latin-1 locale
Mutt converts the mail from its MIME label to $charset, and displays
the result on the terminal. From label to GBK on GBK: Happens to work.
Only the Latin-1 locale may interfere by declaring certain rare bytes
unprintable, and Mutt would then /octalise them. This setup can well
mostly work, but it is of course not a correct setup.
> the mail was incorrectly labeled as us-ascii (or possibly iso-8859-1),
> and mutt dumped the characters to the terminal as-is, and it just so
> happened that my terminal (at the time, hanterm) recognized certain
> "ascii" character sequences as Korean characters (in EUC-KR encoding,
> which was how the mail *should* have been labeled).
Possibly your mail was lacking the "Content-Type:" header, hence
considered as non-compliant to MIME: Mutt then sends the text directly
unconverted to the terminal, in pass-thru mode. EUC-KR pass-thru on
EUC-KR: Works.
> I have long since switched to a UTF-8 setup
Note that such EUC-KR non-MIME mail will *not* be displayed
correctly in an UTF-8 setup. Straight Mutt has no way around that. But
here the $assumed_charset feature patch comes to the rescue: Set
$assumed_charset=euc-kr, the pass-thru mode is disabled, and Mutt will
convert the non-MIME mail from EUC-KR to UTF-8 for display.
I would really like Mutt to adopt the assumed_charset patch.
Bye! Alain.
--
NTP 4.2.2 stable is released.