in e.g. scim-pinyin (chinese simplified) there's some inconsistency between applications and handling an uncommitted pre-edit buffer when the user attempts to change the input position while there are uncommitted chars in the input buffer.

i.e.

gedit: 1) foo, active im, type w 2) highlighted pre-edit appears 3) click at start foo 4) uncommitted buffer destroyed, no commit, cursor moves to foo 5) type w 2) new pre-edit for 'w' appears at foo location 3) deactivate IM 4) pre-edit closed, no commit 5) activate pre-edit without moving location, previous pre-edit content reappears

i.e. changing the input location destroys the contents of an ambivalent uncommitted pre-edit buffer.

firefox: 1) foo, activate im in main window area, e.g. google input box, type w 2) highlighted pre-edit appears 3) click at start foo 4) pre-edit remains open, cursor pretends to be positioned as foo, but pre-edit remains at original position, new chars still entered as original position 5) deactivate IM 6) move cursor anywhere, activate IM 7) previous pre-edit content reappears 8) click in url toolbar, pre-edit content appears committed to original location. On typing the first new letter in the url toolbar, pre-edit area appears, and is revealed to be the same pre-edit buffer as previously used, i.e. w already entered 9) re-click in google entry, apparently committed character disappears

i.e. attempting to change the cursor input location is ignored within the same context while pre-edit is active, changing entry context commits the buffer, but doesn't clear it. Single buffer used throughout application. An uncommitted buffer follows cursor position, but is only shown on a new key entry. Contents not destroyed in input location change.

openoffice.org: 1) foo, activate IM in main writer window, type w 2) highlighed pre-edit appears 3) click at start foo 4) cursor moves to foo, uncommitted buffer moves with it 5) click in e.g. style name area, still uncommitted pre-edit moves with it 6) deactivate IM, move anywhere, activate IM, uncommitted contents appear at the new location

i.e. single pre-edit for the app, uncommitted contents remain regardless of context change, pre-edit follows cursor. Contents not destroyed in input location change.

Now lets take the korean hangul IM, and in...

gedit: type o, highlight pre-edit, click elsewhere, the o is committed to the doc at the original location, input position moves to new location

i.e. changing the input location commits and clears the contents of an un-ambivalent uncommitted pre-edit buffer.

firefox: type o, highlight pre-edit, click elsewhere in entry area, cursor pretends to move, nothing really happens. click in new entry area. the o is committed to the new entry area

i.e. *sob!*

openoffice.org; type o, highlight pre-edit, click elsewhere in the app, cursor moves to new location, highlight uncommitted pre-edit moves to new location.

i.e. same as i.e. ambivalent uncommitted pre-edit buffer case

So all in all I'm a little confused :-)

So, is this (effectively) the gedit/gtk algorithm, and does it make everyone happy...

1) if there are un-ambivalent uncommitted pre-edit buffer contents then commit on input position move 2) if there are ambivalent uncommitted pre-edit buffer contents then ignore them on input position move 3) moving the cursor position will always clear the input-buffer

C.