[ Courtesy Copy to Ilya Konstantinov, ] [ Mutt bug #1269, and Debian Bug #152444 ]
On Saturday, February 19, 2005 at 12:41:10 PM +0900, Tamotsu Takahashi wrote: > The problem is that MS thinks ISO-2022-JP means ISO-2022-JP-MS. And MS > does not think there is a charset called ISO-2022-JP-MS. I don't know well those charsets and their differences, but such scheme sounds familiar! So it's *the* new standard? ;-) > I have to tell mutt to convert my eucJP-ms files to ISO-2022-JP-MS, > labelling it with "charset=iso-2022-jp", to send it to MS-MUA users. Ahaah! I perhaps begin to understand. You want to be able to insert an alias name in $send_charset, already known or not. This reminds me bug #1269 associated with Debian Bug #152444. Reporter Ilya wanted to send ISO-8859-8 mails, but labelled "iso-8859-8-i". Those are identical charsets, out of bidirectional reordering. But 8859-8 is known to Mutt and iconv, while -8-i is not. Impossible to set "iso-8859-8-i" in $send_charset, and to influence that with an iconv-hook. Wouldn't your patch-1.5.8.msyk.iconvhook.1 help? > This cannot be corrected by your charset-hook. No: Clearly charset-hook deals with incoming mails only, and this must not change. > Also, the iconv-hook patch is useful for future changes of charsets > definition. If we have no reason to forbid using of iconv-hook for > already-available charsets, this patch goes the right way, IMHO. Hum... Misused this permits self-foot-shoting. As one or two other Mutt features: Nothing new. If it's usefull in such corner cases, I'd say right way, too. What is the exact intended usage of iconv-hook? Bye! Alain. -- Slrn 0.9.8.1pl1 is released. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]