[Uim] Determine the semantic of reset

[TOKUNAGA Hiroyuki]

Park Jae-hyeon reported as follows:

  If I click at a location within the text area of gedit, different from
  the location of the preedit area, when a syllable (or character) is
  under composition, then this preedit area jumps to the point at which
  I clicked.  I found that the hangul2 input method included in uim also
  shows this behavior.

That is a known problem of uim, but I've left this problem in the past.
In this mail, I want to clear up our requirement and look for the
solution.

In this mail, I'll explain in case of GTK+, but it would be applicable
in case of Qt (and good old XIM) too.


The Problem
===========

When a location within the text area was clicked, preedit strings moves
to the clicked point.


What's happening?
=================

When a location within the text area was clicked, GTK+ calls 'reset'
function of focused IMContext. In the reset function, input method can
do anything. So, in this function, uim can commit preedit string and
erase preedit string. But, carrent implementation is calling reset-
handler of each input module, so the behavior depends on each input
module implementation.


In general, what we imagine with the word 'reset'
=================================================

So, what we should do in reset function would be described as follows,

 1. commit current preedit string (if exist)
 2. then erase preedit
 3. return to initial input state

But, I feel odd with the 1st item. Why we should commit in reset
function? For example, if we push the reset button of our family
computer (in proper English, Nintendo?), game will start from the
beginning.

I'm uncomfortable with the side effect. Reset function should change
only status in the InputContext, ourside of InputContext (such as text
widget) should not be changed with the reset function.

I want to leave the name 'reset' for 'real' reset feature. (i.e. erase
preedit and return to initial input state only.)

So, if we want to commit before erase the preedit string, we should
provide appropriate name for the feature. But now I don't have good
idea.

If you have a good name, or if you have an objection to my opinion,
please reply to this mail.


Regards,

-- 
TOKUNAGA Hiroyuki
tkng at xem.jp