rxvt-unicode treats some Japanese FULLWIDTH chars as HALFWIDTH
dg-f at users.sourceforge.net
Thu Mar 22 04:27:31 CET 2007
Sorry, I would misunderstand what you mean,
please allow me to ask you.
On Wed, Mar 21, 2007 at 02:10:25PM +0100, Marc Lehmann wrote:
> > > mlterm has col_size_of_width_a=value. Number of columns of Unicode characters
> > > with EastAsianAmbiguousproperty. (see mlterm(1).)
> > >
> > > Would you please support this feature?
> > ja_JP.eucJP locale is fixed by src/rxvt.h r1.265.
> > But ja_JP.UTF-8 locale is still weird.
> No, its correct, thats what the locale specified.
Do you mean that ja_JP.UTF-8 locale specifies
"0xd7" (EastAsianAmbiguous) is HALFWIDTH and
rxvt-unicode simply respects it?
> > Do you plan to merge doc/solaris9.patch?
> No, thats an ugly hack around solaris being broken.
Uh, I mean mk_wcwidth() that is a part of doc/solaris9.patch.
mk_wcwidth() variant with configurable option is imported into vim,
xterm and so on.
> > It works well for ja_JP.UTF-8 locale.
> If it disagrees with the locale, its broken. If the locale disagrees with
> your expectation, its the wrong locale.
My Debian unstable glibc locale, ja_JP.UTF-8 is generated by
locale-gen (localedef) from /usr/share/i18n/charmaps/UTF-8.gz.
% - Default width is 1.
% - Double-width characters have width 2; generated from
% "grep '^[^;]*;[WF]' EastAsianWidth.txt"
% and "grep '^[^;]*;[^WF]' EastAsianWidth.txt"
Characters that EastAsianWidth is ambiguous (A), its width is 1.
Yes, rxvt-unicode respects that locale tells.
But vim, xterm, etc have option that gives EastAsianAmbiguous
special treatment that EastAsiwnAmbiguous char width is 2.
vim has ambiwidth=double option, xterm has -cjk_width option.
Do you mean locale is wrong/broken then programs do not need to
support EastAsiwnAmbiguous-char-width-is-2 feature?
Do I need to ask not rxvt-unicode but glibc?
More information about the rxvt-unicode