Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!cwjcc!hal!nic.MR.NET!shamash!com50!jhereg!mark
From: mark@jhereg.Jhereg.MN.ORG (Mark H. Colburn)
Newsgroups: comp.editors
Subject: Re: Programming and international character sets.
Message-ID: <209@jhereg.Jhereg.MN.ORG>
Date: 3 Nov 88 14:45:50 GMT
References: <532@krafla.rhi.hi.is> <8804@smoke.BRL.MIL> <4002@homxc.UUCP> <380@auspex.UUCP>
Reply-To: mark@jhereg.MN.ORG (Mark H. Colburn)
Organization: NAPS International, St. Paul, MN
Lines: 25

In article <380@auspex.UUCP> guy@auspex.UUCP (Guy Harris) writes:
>The ones I've seen convert Romaji to Kana as you type (this is, as I
>understand it, a straightforward translation) and then permit you to
>request that the computer translate the Kana you typed since the last
>checkpoint (switching mode into Kanji mode, or asking for a
>Kana-to-Kanji translation) into Kanji.  It gives you a list of the
>possible translations, and lets you choose which one you want.
>
>Of course, now you'd need an editor that handles *16*-bit characters; I
>think AT&T has a "vi" that will handle them [...]

There was a demonstration of a version of vi which supported Japanese
character sets at the October POSIX meeting in Hawaii.   The implementation
that they demonstratated allowed the user to type in Romaji, then convert
to Kana, and then to convert again to Katakana or Kanji.  In order to
provide the correct translation, they had a dictionary on-line which
provided glyph lookup based on the word being translated.

The interesting part of the whole thing was that the translation was all
done at the TTY device driver level, rather than within the editor itself.
Of course, vi still needs to handle 16-bit characters...
-- 
Mark H. Colburn                  "They didn't understand a different kind of 
NAPS International                smack was needed, than the back of a hand, 
mark@jhereg.mn.org                something else was always needed."