Re: [I18n]xterm and XIM

[Tomohiro KUBOTA <tkubota@xxxxxxxxxxx>]

Hi,

At Fri, 08 Jun 2001 11:38:13 -0700 (PDT),
hiura@xxxxxxxxxxx wrote:

> iconv() with codeset name aliasing, codeset name normalization (all
> can be self contained, thus no external symbol importing is nesessary)
> plus if nessesary an external iconv package would carry enough
> portability as virtually same level as the other combinations for the
> time being.

I see, just Robert's #27 patch used Bruno's libiconv if system has
no or poor iconv().  I admit this is portable enough.
(#27 patch: http://www.debian.or.jp/~kubota/xterm)

However, almost people here seem to dislike iconv(), from some
reason I don't know.

This is why Juliusz developed "luit" even though Robert's #27
works well.  Though I didn't like the idea "core part of XTerm
will work only with UTF-8", I admitted the idea because it worked
well.  (However, later I noticed that XIM doesn't work well.)

Juliusz, do you think it is possible to use "luit" to solve
this problem?  My idea is that, "luit" will be a part of XTerm
and its encoding converter will be used to convert locale-encoded
XmbLookupString() to UTF-8.

Merit:
 1. This way is as portable as "luit" itself.
 2. There will be no #ifdef's.
 3. There will be no Xutf8*(), a seed of flamewar.
 4. There will be no __STDC_ISO_10646__, a seed of flamewar.
 5. iconv()-haters will not object because there will be no iconv().
 6. We will not need to discuss whether "luit" should be invoked
    by default or not, because "luit" will be a part of XTerm.

Demerit:
 1. iconv() will be more standardized way.
 2. I don't know whether "luit" is really portable enough or not.

---
Tomohiro KUBOTA <kubota@xxxxxxxxxx>
http://www.debian.or.jp/~kubota/
"Introduction to I18N"  http://www.debian.org/doc/manuals/intro-i18n/
-
Linux-UTF8:   i18n of Linux on all levels
Archive:      http://mail.nl.linux.org/linux-utf8/