[Uim] Determine the semantic of reset

[TOKUNAGA Hiroyuki]

On Wed, 01 Jun 2005 16:01:47 +0900
Kenichi Handa <handa at m17n.org> wrote:

> In article <20050601145928.423bbec7.tkng at xem.jp>, TOKUNAGA Hiroyuki
> <tkng at xem.jp> writes:
> 
> >>  On Sun, May 08, 2005 at 06:34:51AM +0900, TOKUNAGA Hiroyuki wrote:
> >>  > Park Jae-hyeon reported as follows:
> [...]
> >>  > The Problem
> >>  > ===========
> >>  
> >>  > When a location within the text area was clicked, preedit
> >>  > strings moves to the clicked point.
> [...]
> > As mentioned above, I think some people would prefer preedit-commit-
> > when-focus-out style, other won't. So it should be configurable.
> 
> I have a different view on this problem.  In a Korean input
> method, a character in preedit area is always commitable
> (the reason it's not yet committed is simply because it's
> difficult to modify it once committed), but in a Japanese
> input method, not.  So, each input method module
> (e.g. uim-anthy, m17n-ko-hangul2) should keep information
> about which part of preedit area is ready to commit.  That
> way, an input method engine (e.g. uim, scim) don't have to
> warry about what to do on focus-out/move.  It should commit
> only committable characters.

That's an interesting idea, but this approach need major surgery in the
case of uim. (There's no way to get know comittable strings from the
application side, and sometimes preedit string != commit string.)

I need to consider which approach is better for uim.


> > > I want to leave the name 'reset' for 'real' reset feature. (i.e.
> > > erase preedit and return to initial input state only.)
> 
> As for the name, I agree with you.  The name `reset' doesn't
> imply committing.

How about 'flush' for this behavior?


Regards,

-- 
TOKUNAGA Hiroyuki
tkng at xem.jp