From: Castor Fu <castor@drizzle.Stanford.EDU>
To: schwartz@galapagos.cse.psu.edu (Scott Schwartz)
Cc: sam-fans@hawkwind.utcs.toronto.edu
Subject: Re: Japanese input and Sam
Date: Mon, 7 Nov 1994 18:18:49 -0500 [thread overview]
Message-ID: <199411072318.PAA02889@drizzle.Stanford.EDU> (raw)
In-Reply-To: <94Nov7.175308est.12686@galapagos.cse.psu.edu> from "Scott Schwartz" at Nov 7, 94 05:53:04 pm
> | Has anyone hacked japanese input methods into 'sam'?
>
> Since libXg already uses libXt, you might as well use the
> X11 style input methods (assuming anyone can figure them out :-))
> instead of inventing yet another thing or messing with tcl.
This might be the right solution. However, it scares me. When looking
through libXg, it seems that libXg tries sufficiently hard to NOT to
look like an Xt widget that anyone wanting to fix this has a lot of
work ahead of themselves.
As for the question of using the X11 i18n mechanisms, I'll quote a few
portions of some relevant docs:
From the X11R5 i18n docs:
Bear in mind that input methods are a technology that has
prviously been used only in {\em ad hoc} ways for specific
languages. . . One frustration is the ambiguity, in places
of the XIM specification. . .. . None of the input methods
that are shipped with X11R5 are part of the core distribution,
and none are fully robust or well documented (not in English,
at least). . .
From the X11R6 release notes:
The IM Protocol is a completely new protocol, based on
experience with R5's sample implementations. The following new
features are added, beyond the mechanisms in the R5 sample
implementations . . .
I agree that one doesn't want to re-invent the wheel; the question is,
which wheel do you want? One of the input mechanisms which is widely used,
(SKK) is apparently NOT tied to X11, was designed under Emacs-lisp,
and has even been ported to the DOS environment. It looks vastly simpler
than any of the XIM based methods. By using TCL appropriate
interface might be able to support either system. Trying to use one of
the X11Rn methods sounds like a sure way to guarantee compatibility problems.
-castor
prev parent reply other threads:[~1994-11-07 23:19 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
1994-11-07 21:44 Castor Fu
1994-11-07 22:53 ` Scott Schwartz
1994-11-07 23:18 ` Castor Fu [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=199411072318.PAA02889@drizzle.Stanford.EDU \
--to=castor@drizzle.stanford.edu \
--cc=sam-fans@hawkwind.utcs.toronto.edu \
--cc=schwartz@galapagos.cse.psu.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).