Japanese input and Sam

Japanese input and Sam

[Castor Fu]

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

Re: Japanese input and Sam

[Scott Schwartz]

| 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.

Re: Japanese input and Sam

[Castor Fu]

> | 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