Re: Japanese input (was RE: tlug: Japanese)

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

>>>>> "Matthew" == Matthew J Francis <asbel@example.com> writes:

    Matt> On 08-Jun-98 Jonathan Byrne wrote:

    >> From: Stephen J. Turnbull <turnbull@example.com>
    >> 
    >> > The obvious name is "Japanese Input on Linux Terminals,"
    >> > because JILT is exactly what I would do to it, with quite high
    >> > probablility.

    Matt> And if done right, you'd be able to do exactly that if you
    Matt> so wished.

Not denying that.  Nor am I denying that Jonathan also agrees.  But
that is not where what Jonathan wants is going at this stage of the
state of the art.  IMHO, of course.

    Matt> Rather, I'd seek to do something about the current situation
    Matt> whereby it is *difficult* to write and support true
    Matt> globalisation in software, both in terms of
    Matt> multiple-language support and display, and of input. With
    Matt> only a little glue in the right places, it could be made
    Matt> easier _to_ support such things than not to.

King Canute told the tide to go back to the sea.  I'm afraid you guys
are doing the same thing.

Manuel Chakravarti got it right in his discussion of the
"ease-of-networking" issue.  MS makes the easy things slick.  However, 
in the MS world, you can't scale a network (Manny's point) and you
can't communicate with people whose systems don't work in your locale
_except by ignoring the MIME information_.  And that's exactly what MS 
programs do.

And Manny and I are being perverse about it, not because we don't want
it too, but because we're afraid (well, I am, and I think Manny is
too) that what will happen is that people will rush in with a fix.
For text input, it will quite possibly be tuned to Japanese, and make
most people happy, but fail to be truly multilingual (if it is
multilingual) or be monolingual in Unicode.

There is such a thing as UCS-4, of course, but as far as I know it is
100% empty except for the BMP and private space and the reserved
non-characters at FFFF and FFFE in every plane.  This means that the
system you are putting in place now must be completely flexible with
respect to the standards that will undoubtedly evolve for the use of
UCS-4.

    Matt> This seems so right to me on so many levels; from an
    Matt> aesthetic point of view. From a code-reuse point of view; if
    Matt> one thing must do it, it should be a program. If everything
    Matt> should do it, it should be abstracted to a library. Even, in
    Matt> a certain way, from a viral point of view - anything that
    Matt> helps to spread The Source must be good, and making things
    Matt> work better around the world definitely falls in this
    Matt> category in my book.

Sure.  Dreams are nice.

Only question is, can it work in practice?  I can and do dream
dreams.  However, I respect that fact that some people who are smarter 
than I in combination with some people with much more experience than
I and some people with both, with the help (and admittedly, sometimes
the obstruction) of hundreds of others have brought us to the current
sorry state of affairs.

Microsoft applications work because they don't care if it
interoperates.  The seriously multilingual people I know (ie, people
who use multiple non-ISO8859 locales) are not happy with Windows at
all; changing from one locale to another requires rebooting.  They're
not much happier with the Mac.  They're all lyrical poet-types, so
they're even less happy with Un*x.

The answer is 42.  I don't know what it means, though ;-)

    >> Why don't you join the campaign to world domination of Japanese
    >> input instead? :-) That way you could do loads to make sure it
    >> worked exactly the way you wanted it to while you dominated the
    >> world :-)

I have.  But my preferred OS for this development is not Linux; it's
Emacs.  XEmacs at the moment, as you know.

This choice was made deliberately.  Emacs already has a well-devleoped 
set of concepts and tools, called Mule, for handling multi-lingual
texts.  Emacs has an extremely powerful, flexible programming language 
for this purpose.  XEmacs has Ben Wing, who single-handedly (so I
gather, nobody's said that explicitly) reimplemented the low-level
functions of Mule for XEmacs.  XEmacs can borrow, when appropriate,
from the FSF's Emacs, where Kenichi Handa and Tomohiko Morioka are
brewing magical potions and spells even now.  I prefer XEmacs to Emacs 
because the API is more clearly defined in XEmacs.

But even in Emacs, either flavor, the API is poorly defined.  However, 
there is a strong tradition of multi-lingualism to balance that.

Against that, Linux, GNOME, Gtk etc all suffer from the fatal flaw
that it needs to be implemented in C, with no well-defined API and no
multi-lingual tradition built up.  Better to hack in Emacs LISP, then
(a year or so from now) mirror in C.  IMHO, of course.

    Matt> I vote with my code. As the Mozilla banner exhorts: "Work,
    Matt> and there will be flour. Sit there with crossed arms, and
    Matt> there will not be flour". When and only when there is flour
    Matt> will we know if ours bakes better bread...

    Matt> Baking party. All welcome.

Definitely.  Write to "xemacs-mule-request@example.com".  :-)

--------------------------------------------------------------
Next TLUG Meeting: 13 June Sat, Tokyo Station Yaesu gate 12:30
Featuring Stone and Turnbull on .rpm and .deb packages
Next Nomikai: 17 July, 19:30 Tengu TokyoEkiMae 03-3275-3691
After June 13, the next meeting is 8 August at Tokyo Station
--------------------------------------------------------------
Sponsor: PHT, makers of TurboLinux http://www.pht.co.jp