Re: XIM, kinput2 & Tk

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

>>>>> "Jim" == Jim Breen <jwb@example.com> writes:

    Jim> If so, a fairly stupid thing to do. LC_CTYPE is not supposed
    Jim> to be for that.

Agreed, but that doesn't make POSIX bad, it makes the implementers bad.

    Jim> Yerk. And it still won't work. If I have LANG set to "en_US"
    Jim> or something like that and I want to input Japanese via XIM
    Jim> I'm stuffed.  Ne?

Of course not.  You just do `LANG=ja_JP.eucJP kterm &', which is
enough for most practical pruposes.

OK, so let's be responsive to your real question.  True, you can't
change IMs on the fly with that code.  But that's not what I wrote
that code for.  That code is for protecting the program from X11's
broken usage of locale.

The code I write for _you_ is

  char JimsLocale[A_BIG_ENOUGH_NUMBER];
  char save_locale[A_BIG_ENOUGH_NUMBER];

  printf("Enter desired locale for IM: ");
  scanf("%s",JimsLocale);

  strcpy(save_locale, setlocale(LC_CTYPE,""));
  if (strcmp(JimsLocale,""))
    setlocale(LC_CTYPE,JimsLocale);
  else
    setlocale(LC_CTYPE,getenv("LANG"));
  /* initialize the XIM, and maybe the XIC */
  setlocale(LC_CTYPE, save_locale);

Don't ask me why nobody does this.  I know it works in toy programs,
maybe it doesn't work in production?  Or maybe they're just lazy.  You
can also switch between different Japanese IMs by massaging XMODIFIERS
in the same way.

It's really not all that much code, either.  The only real objection
to it is that it requires lots of system calls (getenv, setenv,
setlocale), and can't be done purely in userland.  But that's not all
that bad, changing IMs is a really rare event.

    Jim> Balls. What the user wants to do is run kterm, i.e. to read
    Jim> and write xterm-like things in Japanese. It's absolutely
    Jim> valid for the kterm code to assume that the user wants to
    Jim> read or write Japanese, because that's the only reason the
    Jim> bloody program exists.

Wrong.  Go read the docs.  kterm is explicitly documented as
multilingual.  True, Japanese is the primary use.  But the buttheads
who wrote the program are trying to cater to the primary use and be
multilingually correct at the same time.

I really rather doubt they would have screwed up this way if they
weren't paying lip service to internationalization issues.

    Jim> I'll accept the desirability of having something like a
    Jim> LANGUAGE variable setting to announce things like which set
    Jim> of languages the user wants to see and input. Having kterm
    Jim> refuse to run unless LANG is set to "jp_*" is plain B A D.

Nobody is denying that.

But that's not POSIX's fault; POSIX does not define a missing locale
as a fatal error, kterm does.

My point is that POSIX locales are better than nothing, but people who
thought they could do better than POSIX have made that a moot point.
The bone I have to pick with you is your claim that POSIX is
responsible for the fucked up state of the world.  It's not.  POSIX
internationalization has never been tried.  Not in free software,
anyway.

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