Re: XIM, kinput2 & Tk

["Stephen J. Turnbull" <turnbull@example.com>]

>>>>> "Mike" == Mike Fabian <mfabian@example.com> writes:

    Mike> Same for XEmacs,

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

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

Well, screw you too X11R6.  (Sorry, Mike, I've had a bad day ... I'm
not yelling at you.)  Here are all the setlocale calls (and some pithy
comments) in XEmacs 21.4.2:

input-method-motif.c:     routine calls setlocale(LC_ALL, lang) which fucks up our lower-level
input-method-motif.c:  if ((locale = setlocale (LC_ALL, "")) == NULL)
input-method-motif.c:      if ((locale = setlocale (LC_ALL, "C")) == NULL)
input-method-motif.c:      if ((locale = setlocale (LC_ALL, "C")) == NULL)
input-method-motif.c:  setlocale(LC_NUMERIC, "C");
input-method-xlib.c:     routine calls setlocale(LC_ALL, lang) which fucks up our lower-level
input-method-xlib.c:  if ((locale = setlocale (LC_ALL, "")) == NULL)
input-method-xlib.c:      if ((locale = setlocale (LC_ALL, "C")) == NULL)
input-method-xlib.c:      if ((locale = setlocale (LC_ALL, "C")) == NULL)
input-method-xlib.c:  setlocale(LC_NUMERIC, "C");
intl.c:  setlocale (LC_ALL, "");
intl.c:  setlocale(LC_NUMERIC, "C");
redisplay-x.c:	    text).  You could maybe call setlocale() frequently

So the setlocale(LC_ALL,"") calls are picking up the LC_CTYPE setting
in the environment.  But setlocale(LC_CTYPE,"") would do the same thing.

Obviously I need to do some research here.  Thank you very much for
finding this.  I haven't a _clue_ why the X implementers decided to do
things this way.

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

I would call it a Basically Undocumented Given in X11.

What's going on is that X11 for whatever reason (I _will_ read the XIM
docs but I doubt it's there) is apparently making its decision about
various things including which XIM and which font from an XFontSet
will be chosen based on LC_CTYPE.  These programs are thus resetting
LC_CTYPE to reflect what the user wants to see and type, and accepting
that sorting and character classes may get bollixed up.

I _think_ that what could be done here for XIM is

  char save_locale[A_BIG_ENOUGH_NUMBER];
  strcpy(save_locale, setlocale(LC_CTYPE,NULL));
  setlocale(LC_CTYPE,getenv("LANG"));
  /* initialize the XIM, and maybe the XIC */
  setlocale(LC_CTYPE, save_locale);

because XIM once initialized has no need to care about the locale, it
saves it in the XIM object.  A similar dodge should work for
XFontSets, as they are "bound to a locale" when they are created.
By doing this, the rest of your program can ignore the need to cater
to BUGs in X.

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

[Jim Breen, are you paying attention here?  This is a typical result of
an attempt to guess what the user wants and force it to happen.

It doesn't _have_ to be this way, but generally it does work out this
way.  This is why I oppose "Do What The User Means" programming in
practice.]

    Mike> I think this is nonsense and therefore my
    Mike> patch makes sense.

Well, I don't know if your patch makes sense, but I'm about ready to
do "dpkg --remove kterm" after reading your post.  What a crock!

My hat's off to you, Mike, if you can get that pile of s--t to work
reliably.

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

It doesn't as far as I know ... that's still up to the user in Debian.
But I'll investigate.

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

I agree in principle.  However, the X resource mechanism is very
hairy.  There is an Emacs xrdb mode of some sort, but I'm sure it's
not very intelligent.

Also, it doesn't matter to GNOME/GTK+ at this stage: they are single-
display systems.  Just like Windows.  Are you surprised?  I don't know
about KDE/Qt.  There's no reason why they couldn't use the same kind
of mechanism (basically, just put the whole file in a GNOME_RESOURCES
property on the root window of the display).


-- 
University of Tsukuba                Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences       Tel/fax: +81 (298) 53-5091
_________________  _________________  _________________  _________________
What are those straight lines for?  "XEmacs rules."