* Japanese input and Sam
@ 1994-11-07 21:44 Castor Fu
1994-11-07 22:53 ` Scott Schwartz
0 siblings, 1 reply; 3+ messages in thread
From: Castor Fu @ 1994-11-07 21:44 UTC (permalink / raw)
To: sam-fans
Has anyone hacked japanese input methods into 'sam'?
If I were to do this, what I would probably do is mash a tcl interpreter
into libXg and handle the input translations in tcl. Then the code
in 'latin1.c' would be moved into an area which could be edited without
recompiling sam.
I suppose purists would feel this was sacreligious, but when using a large
character set like Unicode, I think having hard coded tables like
sam uses is sort of silly.
-castor
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Japanese input and Sam
1994-11-07 21:44 Japanese input and Sam Castor Fu
@ 1994-11-07 22:53 ` Scott Schwartz
1994-11-07 23:18 ` Castor Fu
0 siblings, 1 reply; 3+ messages in thread
From: Scott Schwartz @ 1994-11-07 22:53 UTC (permalink / raw)
To: Castor Fu; +Cc: sam-fans
| 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.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Japanese input and Sam
1994-11-07 22:53 ` Scott Schwartz
@ 1994-11-07 23:18 ` Castor Fu
0 siblings, 0 replies; 3+ messages in thread
From: Castor Fu @ 1994-11-07 23:18 UTC (permalink / raw)
To: Scott Schwartz; +Cc: sam-fans
> | 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
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~1994-11-07 23:19 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1994-11-07 21:44 Japanese input and Sam Castor Fu
1994-11-07 22:53 ` Scott Schwartz
1994-11-07 23:18 ` Castor Fu
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).