Re: tlug: emacs 20.2

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

>>>>> "Craig" == Craig Toshio Oda <craigoda@example.com> writes:

    andy> The only thing that I can think of is LANG. Is it set
    andy> different between them? I had a problem like this on Solaris
    andy> 2.5.1 with CDE. If LANG was not set to some legal values, I
    andy> was getting core dumps...

    Craig> You were absolutely right.  When I was trying to isolate
    Craig> the problem, I commented out the LANG setting in my
    Craig> .bash_profile in my craigoda account.  I'm now using mew
    Craig> with GNU Emacs20.2 under my craigoda account.  This is
    Craig> pretty wild that it core dumps when the LANG env variable
    Craig> is unset.

I haven't looked at Emacs 20.2 yet, although I'm going to have to for
edict.el.  So I don't know for sure.  But, my guess is that this is
buried in Xlib---past experience showed there are lots of problems
there, different ones on every platform.  BTW that's why I don't think
Lesstif and gtk are likely to have reliable _cross-platform_ I18N
support anytime soon.

Linux will probably get it soon on gtk, but XEmacs is not going to
support that for a while, if at all (there are both licensing---I
know, I know, but the X/Open fiasco has people gun-shy---and stability 
objections, plus the fact that some of the gtk people were quite rude
about the idea of coordinating development so that features that
XEmacs needs could be integrated with the toolkit).

So it's a good thing mozilla/open is going to support gtk; that may
(or may not---people at XEmacs are not particularly trusting of the
NPL, either; Netscape clearly is reserving the right to go proprietary
again in the future if it suits them, and that would be just too bad
for Tague and the others at Netscape who believe in the open source
strategy) rekindle interest at XEmacs.  There are people pushing the
Qt widget set, too, though (although that is not likely to be portable 
to Win32 as I recall, which would be a killer flaw).

    andy> craigoda> craigoda_@example.com:~$ kterm Couldn't set locale:
    andy> craigoda>
    andy> ja_JP.eucJP,ja_JP.ujis,ja_JP.EUC,japanese.euc,Japanese-EUC,ja,japan

That's because it doesn't exist, I would imagine.  A Japanese locale
would be a _huge_ data set.  Patches for wchars and mbchars are only
the start of this.  I know no such thing existed 4 months ago.

    andy> I get the same message. I recompiled X to use X's locale
    andy> support. kterm still does not work. I tried to recompile it,
    andy> but I'm getting loads of errors...

Like what?  Cut'n'paste, kudasai.

    andy> I thought that X locales and glibc's where separate. Thats

Yup.

    andy> why I went to the trouble of recompiling X, because from

??  As far as I know, recent releases of XFree86 support the
<X11/Xlocale.h> interface without recompiling.  That's what WileyC
says, YMMV, bupbupbupbleep.[1]

    andy> what I understand, glibc does not yet support Japanese. More
    andy> to the point, there aren't any locales for Japanese under
    andy> /usr/share/locale. Are these available with the jrpm
    andy> release? If so, can your point me at 'em?

Buwhahahahaha.  Write it yerself, ol' bean.  Nobody else is gonna.

Seriuosly, it's a big problem.  This _has_ been done: by people with
big resources behind them, Sun, DEC, IBM, et el.  Proprietary, desu
ne.  The Europeans who are doing most of the work on POSIX style
locales are often intestinally averse to 2-byte character encodings
(for a related viewpoint, read Naggum's ravings on the subject; Erik
is a smart guy and I'm glad he's working for an Emacs, but his notion
of internationalization excludes the majority of human beings).

Japanese by and large are not interested in I18N, only L10N-JP
(localization to Japan).  So rather than f**k with general interfaces, 
most of the work goes into
<EDITORIAL_LICENSE degree="FREELY_TAKEN">
making Japanized software ever more incompatible with POSIX locales
and UCS.
</EDICTORIAL_LICENSE>
See Ohta's _Ima Nihongo ga Abunai_ for a mirror image to Naggum.

Calling Jon Babcock and Tague Griffith, calling Jon Babcock and Tague
Griffith (the good guys in this battle)...

    Craig>   -- begin readme from libc6 doc

    Craig>   This add-on package contains the data needed to build the
    Craig> locale data files to use the internationalization features
    Craig> of the GNU libc.

One of the worst pieces of documentation I've read recently.

    Craig> Also, I still can't input Japanese into Emacs20.2 with
    Craig> XIM....  I have made some progress.  I really want to give

What makes you think it's possible?  XIM was a stub in Emacs 19.34
(not even pretending to work), that's why I switched to XEmacs in the
first place.  As far as I know the only supported method on (FSF)
Emacs 20.x is Quail, but somebody with the NEWS file read it and give
us the straight poop, OK?

    Craig> GTk a try with Japanese input....  When I get some free
    Craig> time.  ;-) Think I'll go sleep early tonight.


Footnotes: 
[1]  Damn, that roadrunner is fast!  Scared the daylights out of me.


---------------------------------------------------------------
Next TLUG Meeting: 11 April Sat, Tokyo Station Yaesu gate 12:30
Featuring Tague Griffith of Netscape i18n talking on source code
---------------------------------------------------------------
a word from the sponsor:
TWICS - Japan's First Public-Access Internet System
www.twics.com  info@example.com  Tel:03-3351-5977  Fax:03-3353-6096