[openi18n-im:01126] Re: iiimcf/iiimgcf/compose keys

Hideki Hiura <[email protected]>
Newsgroups gmane.comp.internationalization.input-methods
Message-ID <[email protected]>
Hi Owen,

> From: Owen Taylor <[email protected]>
> I don't have the full background here, but I think the concern was when
> the selected language engine was something other than UNIT ... a
> Chinese, or Japanese language engine, say. 
> 
> Are (latin) dead keys and compose key handling expected to work when
> conversion for such a language engine is off?

Thanks for the good question! 

This is a good oppotunity to explore my thought behind composition
and language engine on/off issue!

Let me start with my short recommendation, which is no, and open the
discussion on the implication behind this.

There are several aspects we can look at, especially with the history
of input method and the notion of language engine on/off.

Pre-input method days, the compose key and dead key handling was done
in keyboard driver or in its sort, in several layer.

Due to the input method introduced quite late in the game, as mostly
addition additional single language support to what's inputtable by
keyboard(driver) can generates, the notion of language engine on/off
is also invented. 

But I doubt that idea is applicable universally now, especially after
given multilingual input method paradigm. I would say it was just a 
histrical tactical necessity which we can fix by now.

A right paradigm which we can introduce now is 
  1. to get rid of partial key operations the keyboard drivers or any
     pre-input method processings perform, and
  2. to let Input method handles all input event always, and
  3. to let a user to choose input language (and language engines for 
     the language) instead of language engine on/off.
So that the so-called-"language engine off"-state without composition is 
handled by English input method, and so-called-"language engine off"-state 
with composition is handled by, say French input method, German input method
etc.

Having said that, there is certainly the possibility that it is still too 
early for the paradigm shift :-), we can certainly retain the previous
model for now and have a special code in libiiimcf for practicality
reasons, seeking the best timing to purge later :-).

Thanks!
Hideki
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.