Re: re blackbox and icewm

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

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

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

    >> You absolutely need XMODIFIERS set for any XIM application to
    >> work at all.

    Mike> "absolutely" is not absolutely true.

OK.

    Mike> If you delete the file
    Mike> "/usr/X11R6/lib/X11/locale/ja/Compose", you will be able to
    Mike> use XIM without setting XMODIFIERS in many
    Mike> circumstances. That is surprising

Not given the comment in that file.  All I can say is "I hope Hideki
[Hiura] learned from the first time around."  Even his colleagues at
X.org can't figure it out.  :-(  Heaven help us if IIIMF is similar.

    >> [The XMODIFIERS envvar] is a typical boneheaded X design
    >> decision, by the way.

    Mike> If [XIM preferences were a root window property], how could
    Mike> you use more than one input server at the same time? With
    Mike> the current system, this is possible:

    Mike> You can start X11 and then start several input servers:

    Mike>    ~$ kinput2 -xim -kinput -canna & ~$ ami & ~$ LANG=zh_TW
    Mike> xcin & ~$ LANG=zh_CN xcin &

    Mike> Now you can do

    Mike>    ~$ LANG=ja_JP XMODIFIERS=@example.com=kinput2 rxvt &

    Mike> to get an rxvt and input Japanese,
[snip]

    Mike> How could you do that, if the information stored in
    Mike> XMODIFIERS were a property of the root window?

Like this:

bash-2.05$ xrdb -merge <<ENDSPEC
*XIM.ja_JP: kinput2
*XIM.ko_KR: Ami
*XIM.zh_TW: xcin-zh_TW
*XIM.zh_CN: xcin-zh_CN
ENDSPEC

and then XIM should internally switch on the locale subfield of the
XIM resource.  Note the *: you could do

Emacs*XIM.ja_JP: kinput2
KTerm*XIM.ja_JP: xwnmo

for even more flexibility.  That's a proposed API, but it obviously
would work if implemented.  You could even get down to the instance
level by using the Xt -name switch when invoking the app.  Not to
mention that all the parsing would be done by Xrm routines and macros,
none of the bogosity you see with kinput2.

Furthermore, XIM should provide a built-in interface (ie, through the
events filtered out by the XIM server) for setting the server and even
switching on the fly.  Like I said, the _design_ is bone-headed.
Starting with the decision to accept the POSIX locale model as the
_end_ of the I18N story.  Don't ask me how the sucky implementation[1]
built to the bone-headed design constrained by the brain-dead ISO
standard can work; it probably can't.

None of the above should be construed as advocating that we ignore
POSIX.  Just that we should provide optional extensions (which we hope
will become standard).  Also, actually I have a lot of respect for
Hideki & Co; they did a pretty good job specifying XIM completely
blind.  Unfortunately, nobody in the open source world has bothered to
build on that spec.  And the reference implementation is pretty ugly
in any multilingual context.  But that's not (entirely) the spec's
fault.

    Mike> If you delete the
    Mike> "/usr/X11R6/lib/X11/locale/{ja,ko,zh}*/Compose" files, the
    Mike> first input server started (kinput2 in my above example)

I smell a rat.  Do the others work if they are started first?  Do they
share the obnoxious "kinput2 must serve Japanese even if the user
doesn't ask for it" code that's in kinput2?

* Re: Red Hat has left Japan.

    Mike> Really? Why? Do you have some details about that?

(a) According to Adrian Havill, Ulrich Drepper, and one other who
didn't speak in public so I won't identify, yes, really.  The main
players are being moved to North Carolina.  (b) According to Adrian,
Red Hat's internationalization is now complete, so there's no need for
local research offices.  (c) No.  Just what I've said here.

By the way, it's possible that Red Hat's I18N _is_ complete and
there's nothing left except to translate message catalogs.  We could
blame the kterm segfaults on "the world's best GCC" ;-).  Or (much
less likely) glibc.  8^]


Footnotes: 
[1]  I'm doing XEmacs because I needed to fix XIM, and the workaround
was easier to code for XEmacs than for GNU -- it was _not_ an Emacs bug.

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