Re: For 1.5.9: iconv-hook patch by Moriyama-san
[ 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.