rxvt-unicode treats some Japanese FULLWIDTH chars as HALFWIDTH

[Marc Lehmann]

On Thu, Mar 22, 2007 at 12:27:31PM +0900, "Dai.H." <dg-f at users.sourceforge.net> wrote:
> > > 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?

Basically, yes. At least that is how it *should* be: urxvt always respects
your locale, as should all other programs do too. If your locale says
something and urxvt doesn't follow that, that is considered a bug in
urxvt.

> > > 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.

Yes, they are all buggy as long as they use that.

> 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.

Yes, I know. But its stupid to add such hacks to each and every program
and force the user to enable them. The right way is to use or modify the
locale, then suddenly all well-written programs with or without such hacks
just magically work.

Ignoring the locale is just wrong. It leads to interoperability
problems between programs that simply wouldn't exist if everybody just
respected the locale instead of relying on their own hacks.

The only justification for adding hacks is for systems that do not support
required locales (such as one providing utf-8), but those systems either
die or get upgraded, so the time is much better spent improving the locale
system on those rare sytems rather than adding hacks to each and every
program.

> Do you mean locale is wrong/broken then programs do not need to

If the locale specifies a character width that you do not want, then the
locale is pretty much broken from your perspective, isn't it? At least its
not the locale you want.

> Do I need to ask not rxvt-unicode but glibc?

I think glibc (or any software distribution either using it or something
else) should provide the means to configure it regarding such details such
as character width, at least for commonly wanted cases such as east asian
widths.

I am open to reasoning against my arguments, but to change my mind one
would have to overcome the arguments above. It just plain makes no
sense to hack eahc and every program on the world to workaround locale
limitations: there are far more editors and terminals around than libcs.

-- 
                The choice of a
      -----==-     _GNU_
      ----==-- _       generation     Marc Lehmann
      ---==---(_)__  __ ____  __      pcg at goof.com
      --==---/ / _ \/ // /\ \/ /      http://schmorp.de/
      -=====/_/_//_/\_,_/ /_/\_\      XX11-RIPE