consistency on handling uncommitted pre-edit buffers on input position change ? gtk2/firefox/OOo

[Caolan McNamara]

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.