Re: howto get mutt to display "circled numbers"
On Wed, Jul 19, 2006 at 01:42:00PM +0200, Alain Bench wrote:
> On Tuesday, July 18, 2006 at 14:56:44 +0900, Henry Nelson wrote:
> Arggl... So you keep ja_JP.eucJP locale, and force $charset=eucJP-ms
> in muttrc. Such contradiction is not clean, and generally is not
> recommended. But here, what to do else? Hopefully possible drawbacks
> will be minimal or none, thanks to charsets similarities... and thanks
NetBSD's ja_JP.eucJP locale may in reality use the eucJP-ms charset. I
am trying to confirm that now.
> >| charset-hook ^euc-jp$ euc-jp-ms
>
> Having this line in muttrc may seem to make sense also for everybody
> else, *if* iconv knows EUC-JP-MS. No drawbacks, and possible (small)
> benefit even to non-Japanese. I adopted it in production.
I don't understand why there would be any benefit to someone not using
Japanese.
I did write to Bruno Haible about EUC-JP-MS. He gave a very complete
argument against including it in iconv, and I mostly agree with him.
Putting EUC-JP-MS in iconv is the same as letting Microsoft lead Unix
users around by a nose ring.
However, for users of Japanese, the Moriyama patch to iconv is an absolute
necessity. I think it should remain an optional patch, and not incorporated
into the mainstream code (at least not without a configure option), but
others (many?) might disagree.
> But if iconv ignores EUC-JP-MS, this charset-hook is catastrophic in
> any other non-EUC-JP locales. That had to be said clearly.
That's for sure!
> [$send_charset]
> But ISO-2022-JP-MS is neither allowed. So might perhaps be good
> "...:iso-2022-jp:utf-8", though leading more mails than you would want
You're right. I've adopted "...:iso-2022-jp:utf-8".
> to be sent in UTF-8. Like your 2 last ones. That's not a problem for
> powerfull mailers, but hurts mailx to death...
Well, as you know mailx is the reason I was forced to use procmail
to filter all mails through nkf (http://sourceforge.jp/projects/nkf/),
mimekit (bundled with Delegate, http://www.delegate.org/delegate/),
and/or iconv. Until you educated me about the Moriyama patch to iconv,
I was still being forced to use nkf and mimekit even with mutt, but I
think now those days are over!
> To be complete: I saw some Japanese people advocating sending
> EUC-JP-MS content with a voluntarily liar EUC-JP label. I don't know
> Japanese mail habits enough to comment about the balance of expected
> benefits vs drawbacks. But to my external eyes, this looks much like
> total heresy.
It's a terrible idea. Adding yet another (already close to 20! See
"http://www.haible.de/bruno/charsets/conversion-tables/EUC-JP.html";)
encoding is complete insanity. Japanese mails should either be strict
iso-2022-jp or utf-8. Any documents employing OS/Vendor-specific charsets
should be sent as binary attachments, IMNSHO.
> >> both a (one) and a (TM). Let's see: .
[lots snipped]
> > In nvi, the (TM) is some illegible superscript character. In mutt, it
> > is a double-width, centered dot.
[and in cat also a double-width, centered dot]
>
> This discrepency is unexpected. I see the same widened glyph in
> Mutt, editor, and cat.
nvi-m17n has its own internal conversion routines. It must be encoding
that character differently from iconv (mutt) or native NetBSD (cat),
which both display the same "double-width, centered dot".
What do you see here between spaced-quotes: " ?? "? This is cut-n-paste
from MSIE rendering of "™" in a web page since I do not know how to
enter a "real" (TM). I am editing with nvi, and see a "double-width,
centered dot", not the same strange glyph I see with the (TM) you entered.
--
henry nelson
WWW_HOME=http://yuba.ne.jp/~home/