Re: XIM, kinput2 & Tk

[Mike Fabian <mfabian@example.com>]

"Stephen J. Turnbull" <turnbull@example.com> writes:

> >>>>> "Mike" == Mike Fabian <mfabian@example.com> writes:
> 
>     Mike> kterm doesn't use [LC_CTYPE] for conversion purposes, it
>     Mike> just uses it to decide whether to use XIM:
> 
> I understand that; the point is that LC_CTYPE is about the internal
> structure (classification into alpha, num, hex; collation order, etc)
> of the character set, something quite different from the question of
> I/O protocols.

rxvt does the same:

    mfabian@example.com:/sugi/mfabian/cvs/rxvt-cvs/src$ grep setlocale *
    grep: CVS: ディレクトリです
    grep: graphics: ディレクトリです
    init.c:    locale = setlocale(LC_CTYPE, "");
    Binary file init.o matches
    Binary file rxvt matches
    grep: test: ディレクトリです
    mfabian@example.com:/sugi/mfabian/cvs/rxvt-cvs/src$ 

i.e.

    ~$ LC_CTYPE=de_DE rxvt

will not switch on XIM, even if the rest of the locale related
variables are set to Japanese:

    mfabian@example.com:~$ LC_CTYPE=de_DE locale
    LANG=ja_JP
    LC_CTYPE=de_DE
    LC_NUMERIC="ja_JP"
    LC_TIME="ja_JP"
    LC_COLLATE=POSIX
    LC_MONETARY="ja_JP"
    LC_MESSAGES="ja_JP"
    LC_PAPER="ja_JP"
    LC_NAME="ja_JP"
    LC_ADDRESS="ja_JP"
    LC_TELEPHONE="ja_JP"
    LC_MEASUREMENT="ja_JP"
    LC_IDENTIFICATION="ja_JP"
    LC_ALL=
    mfabian@example.com:~$ 

Same for XEmacs,

    mfabian@example.com:~$ LC_CTYPE=de_DE xemacs

won't switch on XIM either. And gives me German in the menubar, which
is certainly wrong!

Many programs seem to do this, not only kterm and rxvt, therefore
I thought it is probably OK to decide whether to use XIM or not
by using LC_CTYPE.

> XEmacs, for example, will internally reset LC_CTYPE in certain cases
> to guarantee that programs that parse natural language text will see
> the expected ordering after sorting.
> 
>     Mike> There are no setlocale() calls in kterm using LANG. I this
>     Mike> wrong?
> 
> I think so.

Hmm, I'm not yet convinced. I don't understand why kterm and rxvt use
setlocale(LC_CTYPE, "") instead of setlocale(LC_ALL, "") though.

>     Mike> I patched it with the following patch to make it work with
>     Mike> glibc 2.2:
> 
> Kterm evidently goes to some effort to flexibly work with the
> locales.  Why do you short-circuit kterm's facilities this way?

No, I don't think that what Kterm did here was an effort to work
flexibly with the locales. It had a build-in list of locales:

    ptyx.h, line 264:

    #ifdef KTERM_XIM
    # define EUCJPLOCALE	"ja_JP.eucJP,ja_JP.ujis,ja_JP.EUC,japanese.euc,Japanese-EUC,ja,japan"
    #endif /* KTERM_XIM */

Then it tried in a loop to call "setlocale(LC_CTYPE, *locales)" for
all the locales in this list and stop at the first successfull
setlocale call. On Linux, with glibc 2.2 or glibc 2.1.x + japanese
locale extensions, the first call setlocale(LC_CTYPE,"ja_JP.eucJP")
will already be successful therefore the other ones won't be tried.

I.e. the parameter used in the successful setlocale call is not
necessarily the same as the one set in the environment of the user.
The user may have set LANG=ja_JP, which is perfectly legal, ja_JP
is an alias to ja_JP.eucJP.

With glibc 2.1.x, this didn't matter, kterm worked OK even if the user
did set LANG=ja_JP or LANG=ja_JP.ujis. With glibc 2.2 this didn't work
anymore, the user had to set LANG=ja_JP.eucJP, otherwise kterm would
not work correctly.

When  I changed the above internal locale list in kterm to have
ja_JP.ujis as the first entry, then again the first call
setlocale(LC_CTYPE,"ja_JP.ujis") was successful, but then kterm
would work correctly only if the user did set LANG=ja_JP.ujis
as well. 

But when I just replace this loop over the list to a single call to
setlocale(LC_CTYPE,""), then the locale value which the user did set
in the environment is used, i.e. after my patch the user can set *any*
Japanese locale supported by glibc and it will work.

I don't think it makes sense to make kterm work only for the first
locale in this internal list. How should the user know that kterm
has an internal list of locales and that he *must* set lang
to the first value of this internal list to make it work. I think
this is nonsense and therefore my patch makes sense.

>     Mike> RedHat (6.2 and 7.0) checks in /etc/X11/xinit/xinitrc.d/xinput
>     Mike> for the value of LC_CTYPE to decide whether to start kinput2.
> 
>     Mike> Is this wrong?
> 
> You ask a Debian user if Red Hat does wrong?  :-)

When does Debian start an input method for X11 like kinput2?  Does
Debian check for LANG to decide whether to start an XIM server?

>     Mike> Is it that bad? Aren't the keybindings to start XIM a user
>     Mike> specific setup? So why not put in into $HOME? if $HOME is
>     Mike> nfs mounted,
> 
> Yes.  They're user-specific.  _Not_ host-specific.  _Not_ filesystem
> specific.

Yes I see.

> X11 has a standard way to ensure that your Xserver is set up
> correctly, no matter where your home is or where the X server is:
> xrdb -display $DISPLAY < ~/.Xresources.  If you use that, you never
> have to say:
> 
>     Mike> I only thought that it was very confusing that nicolatter
>     Mike> did put the keybindings to start XIM in case of Wnn into the
>     Mike> file ~/.nicolatter/global, but in case of Canna reads them
>     Mike> from ~/.canna. I couldn't find that in nicolatters
>     Mike> documentation, so I was surprised why changes to
>     Mike> ~/.nicolatter/global didn't work in case of Canna.

:-)

Considering that, it is probably not very nice that KDE and GNOME
don't use the X11 resources mechanism but have their setup in
~/.kde2/, ~/.gnome/, ~/.gtkrc and files like that.

-- 
Mike Fabian   <mfabian@example.com>   http://www.suse.de/~mfabian
睡眠不足はいい仕事の敵だ。