Re: [I18n]xterm and XIM

[hiura@xxxxxxxxxxx]

> From: hiura@xxxxxxxxxxx
> > From: Tomohiro KUBOTA <tkubota@xxxxxxxxxxx>
> > You mean, Kinput2 works well for you with XIM clients under UTF-8
> > locales?  Then, Kinput2 is not responsible for this behavior...
> 
> I have not tried kinput2 recentry, but at least X11R5 days, it worked
> if I remember correctly.

I am getting anxious that this may be my fault of not clearly specifying
what LOCALES means in the default pre-connection convention section,
after roughly looked at the specs of the R5 XIM protocol and the R6
XIM protocol. 

In the R5 XIM protocol the locale name being exchanged is defined
as not including encoding part (.CODESET part) but in the R6 XIM
protocol spec, such paragraph was not spelled out even though it
is assumed to inherit from the R5 convention.

I have not verified but when Kinput2 operates in R6 protocol mode,
Kinput2 may be storing the locales with .CODESET and the variations
of locale names Kinput2 stores may not be covering enough wider
range.(not confirmed yet) I guess why htt works is that it is
UTF-8/16 oriented since R6 early stage, the variations of locale 
names are just there.

....while writing this reply up to here, I started wondering what
about the Xlib side parses the locales XIM server listed.......... and
found it just compares them with strcmp....... (also found again it
was in my old code ;-;)

I may have to seriously look into it to confirm what it was supposed
to be.

--
hiura@{sun.com,li18nux.org,kondara.org,unicode.org} http://www.li18nux.org
Chair, Li18nux/Linux Internationalization Initiative, Free Standards Group
Architect/Sr. Staff Engineer, Sun Microsystems, Inc, USA  FAX 650-786-9553
-
Linux-UTF8:   i18n of Linux on all levels
Archive:      http://mail.nl.linux.org/linux-utf8/