[Uim] Determine the semantic of reset

[Kenichi Handa]

In article <20050601165610.2bfb6b78.tkng at xem.jp>, TOKUNAGA Hiroyuki <tkng at xem.jp> writes:
>>  > 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.)

Yes.  My view is an ideal one.  To realize that, we need an
agreement among the input method module developpers.

In the case of m17n-lib, I can easily modify Korean (and the
other) input methods to attach, say `committable' text
property, on preedit text, then uim can check that property.

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

"Flush" sounds like almost the same as "commit".  I think
"leave[-input]-spot" (including both focus-out and
focus-move), or something like that is good.  Aren't there
any English native on this list?

---
Kenichi Handa
handa at m17n.org