rxvt-unicode treats some Japanese FULLWIDTH chars as HALFWIDTH

[Dai.H.]

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.
It says,

% - 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?

Regards,
-- 
	dai