Hi Mike.

While the good menu style and the better name for
"commit mode" is about an UI and can be discuss
indefinitely, the more simple question is just why
it breaks arrow keys?
Maybe simply committing the pending input not only
by Space, but also by Arrows, Enter and other "special"
keys? Then the only problem I will see in the "normal"
mode is the underlined letter, which is fine.

Another question: if ibus knows for sure that there
are no candidates for preedit, why does it even underlines
something and waits for the next char? In case of
translit, as you explained, there are candidates
when some letters are typed. But some letters do
not have candidates even in translit table, so why
they cannot be committed directly?

(In reply to Stas Sergeev from comment #0)
> That is completely useless for rusle.  rusle is a fixed conversion
> table, no new shortcuts are ever defined.  Therefore, for rusle, that
> “Normal commit mode” which commits to preedit is useless.
> 
> I must think whether I can automatically determine which tables need
> this “Normal commit” option and which don’t to be able to disable it
> automatically for tables where it makes no sense.
Is it possible to determine that on a per-character
basis, and not per-table?
Like, if in rusle there are no candidates for any
typed char, they should just be committed immediately.
For the mixed table, like translit, only wait in
preedit for those chars for which the candidates
do really exist.
Is it possible?

Of course it may still be nice to also disable that
mode entirely for the tables where preedit is not
needed for any input. But the problem will not happen
if it is resolved on a per-char level.

(In reply to Stas Sergeev from comment #1)
> Hi Mike.
> 
> While the good menu style and the better name for
> "commit mode" is about an UI and can be discuss
> indefinitely, the more simple question is just why
> it breaks arrow keys?

It doesn’t “break” the arrow keys, it changes the function
of the arrow keys to edit the preedit.

> Maybe simply committing the pending input not only
> by Space, but also by Arrows, Enter and other "special"
> keys? Then the only problem I will see in the "normal"
> mode is the underlined letter, which is fine.

No, if stuff is committed using “Normal commit mode”, it is
committed to preedit, which you can distinguish because it is
underlined. Using the arrow keys then moves *inside* the preedit,
not inside the text which is already committed to the application.

Committing the preedit by typing a space automatically defines a new
shortcut for the string in the preedit (when using an input method
like Wubi which has rules to automatically define such shortcuts).
But before committing the preedit by using space, you can still review
and edit *the preedit*. I.e. move around with the arrow keys between
the left and the right border of the preedit, insert more characters
somewhere inside the preedit, delete some characters and review the
shortcut which will be defined when the preedit is committed.

That is quite complicated, but it is meant to be like this.

It is of course completely useless for rusle, so rusle
should just never use this "Normal commit mode".

> Another question: if ibus knows for sure that there
> are no candidates for preedit, why does it even underlines
> something and waits for the next char? In case of
> translit, as you explained, there are candidates
> when some letters are typed. But some letters do
> not have candidates even in translit table, so why
> they cannot be committed directly?

They *are* committed directly in this case!

translit,  just like rusle, should *never* use “Normal commit mode”,
always "Direct commit mode".

When typing Cheburashka with translit using “Direct commit mode”,
the following happens:


C                 _Ц_
Ch                Ч
Che               Ч_е_
Cheb              Чеб
Chebu             Чебу
Chebur            Чебур
Chebura           Чебура
Cheburas          Чебура_с_
Cheburash         Чебура_ш_
Cheburashk        Чебураш
Cheburashka       Чебурашка

Here I have marked the parts where the underlined preedit is seen with
underscores:

    _contents of preedit_

So it works just like you suggest, when there are no candidates it
commits directly, you see the preedit only when there is more than
one candidate.

I.e. we do not have a bug here, rusle is broken with “Normal commit
mode”, but “Normal commit mode” is just something which should
never be used with rusle or translit.

Instead of “fixing” it for rusle, I should disable it for input methods
which have no use for this “Normal commit mode”.

“Normal commit mode” is only only useful, if one wants to move
around in the preedit and edit the preedit itself. 

In translit one would never want to do that. In translit, the
preedit is never longer than one character. Moving around, inserting,
deleting in a preedit of length 1 makes no sense. If one types 
Che and sees Ч_е_, and the last character was a mistake, just delete it
with Backspace. No need to do fancy editing in the preedit.

In Wubi however, the preedit can have any length, many characters.
Before committing such a long preedit with space to define a new shortcut
for the contents of that preedit, one may want to review the preedit and
see the shortcut which will be defined.

(In reply to Mike FABIAN from comment #3)
> No, if stuff is committed using “Normal commit mode”, it is
> committed to preedit, which you can distinguish because it is
> underlined. Using the arrow keys then moves *inside* the preedit,
Well, maybe that's true for Left arrow.
But why also Up and Down and Right arrows do not work?
They are not supposed to get me inside preedit.
As you explain further, I am only allowed to be
moved inside preedit boundaries, and that's why
the other arrows do not work.
Would it be possible to allow moving freely, including
outside of the preedit? IMHO, underlining the preedit
boundaries is enough to allow the user to edit it.
Not allowing it to escape the preedit is way too heavy-handed.

> They *are* committed directly in this case!
> 
> translit,  just like rusle, should *never* use “Normal commit mode”,
> always "Direct commit mode".
> 
> When typing Cheburashka with translit using “Direct commit mode”,
> the following happens:
OK, this means, even after all the explanations
I still don't understand the difference between the
2 modes. :(
Initially I thought in Direct mode every typed
char is committed immediately to the application,
so the candidates are not being awaited.
Now you explain that even in Direct mode you can
type ch and get ч. I though in Direct mode you would
type ch and always get цх.
According to your latest explanations, is it correct
that Normal and Direct modes are identical, both using
some pre-commit buffer. Normal mode allows you to edit
inside that buffer, while direct mode does not allow
this.
Is this understanding correct?

> “Normal commit mode” is only only useful, if one wants to move
> around in the preedit and edit the preedit itself. 
>
> In translit one would never want to do that. In translit, the
> preedit is never longer than one character. Moving around, inserting,
> deleting in a preedit of length 1 makes no sense.
I am confused.
In your example with cheburashka there were chars with
the length of 2, like ch->ч.
Arrrh... I guess I am starting to understand...
When we type "ch" we only have c in preedit, and h
makes a commit. So while the char consists of 2 letters,
you say the preedit length is 1...
In case of rusle, the preedit length is then 0.
Is this understanding correct?

(In reply to Stas Sergeev from comment #5)

> I am confused.
> In your example with cheburashka there were chars with
> the length of 2, like ch->ч.
> Arrrh... I guess I am starting to understand...
> When we type "ch" we only have c in preedit, and h
> makes a commit.

Yes!

> So while the char consists of 2 letters,
> you say the preedit length is 1...
> In case of rusle, the preedit length is then 0.
> Is this understanding correct?

Yes.

When using “Direct commit mode” with rusle, you will
never ever see any preedit. As you say, the preedit length
in rusle with “Direct commit mode” is always 0.
Every character is committed immediately. What else could one want?
“Normal commit mode” is never useful for rusle. So I should just
disable it for rusle (*and* for all the other input methods
where it is completely useless, this includes translit and possibly
all non-CJK input methods, I’ll check carefully ...).

The tne problem is solved for rusle, no preedit, no problems with any
of the arrow keys. Arrow left, right, up, down all work normally.

For translit it is “almost” solved when “Normal commit mode” is
disabled.

Remaining small problem for translit:

When typing “C” you see _Ц_, i.e. you see a preedit because the
input method has to wait whether a "h" follows or something else.
Arrow up and down now walk through the possible candidates. In this
case there are two possible candidates, “Ц” and “Ч”. So arrow up
and down cycle between these two. In Chinese input methods, there are
often many candidates and arrow up/down cycle through a long list
(Usually one switches the display of the candidate list on then in the
setup, this is the default for the Chinese input methods, a sort of
combobox opens and the arrow up/down keys cycle through the candidates
in that combobox). For translit, I think it is OK if arrow up/down
cycle between “Ц” and “Ч” when “C” has been typed.

*But*, arrow left and arrow right still commit to preedit! Even when
“Direct commit mode” is active. You can see that by typing “C” with
translit and then “arrow right”. The Ц changes colour to red which indicates
that it has been committed to preedit but not to the application yet and
the arrow keys now move around in that preedit. Also, when typing “C”
with translit and then the left shift key, the Ц is committed to preedit.
Again you can see that because the colour becomes red. That makes no sense
for translit where the preedit length is never longer than 1.

I am not yet sure what to to about this in translit.
Maybe leave it as it is, it is really a minor problem.
I thought about disableing committing to predit with the left shift
key and the arrow left/right keys when using “Direct commit mode”,
But when using a Chinese input method like Wubi with direct commit mode,
it can still be useful to be able to manually commit to preedit to
define new shortcuts.

Example with wubi-jidian86:

Type “a”, select the character “工” with arrow up/down in the candidate list,
commit it to preedit with the left shift key. Type “b” and select the
the character “了” in the candidate list and commit it to preedit as well
with the left shift key. Now you have the string “工了” committed to preedit,
shown by the red colour. You can move around in that preedit with arrow left
and right. When the cursor is on “工”, the auxiliary text shows:

    a aaa aaaa #: aabn
    
which means that the possible key sequences to type “工” are
“a”, “aaa”, or “aaaa” and the new key sequence which will be defined
to type the whole string “工了”  will be “aabn”.

When you move the cursor over the “了” you see:

    b bnh  #: aabn

which means that the possible key sequences to type “了” are
“b” or “bnh” and again “aabn” is the key sequence which will
be defined for the string “工了” if the user commits this by typing
space to the application now.

I think you probably have to try this to understand it.

So disabling committing manually to preedit with arrow left/right
and the left shift key always might not be a good idea, it would
loose some useful feature for wubi.

But this committing to preedit never seems to make sense for non-CJK
input methods. I cannot think of any reason why this should be useful
for a non-CJK input method. So I guess for non-CJK input methods I
will do:

- disable “Normal commit mode“
- disable manually committing to preedit using arrow left/right and left shift

And, as you say, I should think of better names for “Direct commit
mode” and “Normal commit mode”. Currently in the setup tool one sees

    Commit mode:  [Direct/Normal] <- combobox

I should probably change this to:

    Auto commit:  [To application/To preedit]

“Auto commit” because this is the name of the option in the table
source, True means to application, False means to preedit.  “Auto
commit” also fits better than “Commit mode” because this option is
about automatic commits which happen when a candidate has been matched
uniquely (Like when typing “Ch” or “Cx” in translit, an automatic
commit happens in both cases, when typing “h“ or “x”). This option
has nothing to do with manually committing to preedit by
using the left shift key or the arrow left/right keys.

Created attachment 933160 [details]
what-is-commit-to-preedit-shown-using-wubi-jidian86-as-an-example.png

screenshot trying to explain what commit to preedit is using
wubi-jidian86 as an example.

The black text in gedit at the left and the right has already
been committed to the application. There is no underline, it is just black.

The red text has been committed to preedit, but not to the application.
Same for the green text, it also has been committed to preedit but not
to the application. When moving around the cursor with the arrow keys
in the string committed to preedit, the part to the left of the cursor
is red, the part to the right of the cursor is green.

The black *and* underlined text in the middle is the preedit for the
current input sequence. The current input sequence is “i”, visible a
the top of the of the candidate list (Before the “(1/6)”. The
currently selected match is 不, using arrow up or down one can select
other matches. Or one continue typing, for example by typing the
additional keys “ht” one would get 小 (the blue Latin characters
following the candidates indicate the missing part of the key sequence
to complete that character).

With arrow left/right or with the left shift key one can now commit
the selected candidate, for example 不 to preedit as well.  Then the
key sequence which will be defined for the whole string is
displayed. It is “abgd” in this case. So if one commits this whole
string now by typing space, one can in future type “abgd“ to get
“工了不以在” as a candidate.

This whole exercise of “committing to preedit is to define
new shortcuts for longer strings.

Ah, better idea! Instead of disabling “Normal commit” for non-CJK
table, I should disable it if a table does not have an
entry for RULES:

### Rules for user define phrase construct:
RULES = ce2:p11+p12+p21+p22;ce3:p11+p21+p31+p32;ca4:p11+p21+p31+p-11

If there are no such RULES, no new shortcuts can be defined
automatically (I plan to add a feature to define new shortcuts
manually, but that is a different story and it will not be for rusle).
In that case, without such RULES, committing to preedit makes no
sense, how could a new shortcut be defined for the stuff committed to
preedit without such rules? So checking for the existance of RULES in
the table source seems to be a better way to decide whether committing
to preedit should be allowed or not. Better than checking CJK vs
non-CJK.

Explaining this makes me understand it better ☺.

Thanks for the detailed explanations!
I think I am now getting the picture.
The most important thing is that there
seem to be 2 separate preedit phases:
1 allows you to select candidates for
a single char
2 allows you to select a short-cut for
some previous typing.

So while Normal mode has both, Direct
mode has just the first one.
Is this understanding correct?
If I know there are 2 different preedit
stages and Direct mode disables just one,
I would probably get that all with much
fewer efforts. :)
When you said preedit is not needed for
translit, I was entirely confused. But
it appears only stage 2 is not needed,
but you still need stage 1 to select
candidates for c.

Now as rusle does not have stage 1, I
was stuck at stage 2 in Normal mode when
trying to move with an arrows.
You seem to explain what the arrows do
for stage 1: they select a candidate.
But this probably does not apply to my
question, because in Normal mode I stuck
at stage 2 where the binding could be
defined. What do the arrows do for stage 2?
I tried to experiment with SKK but I don't
see where is there a switch between
Direct/Normal modes...

OK, I hope my understanding is now closer
to the reality. Of course it could be in
fact further away...

For example, you suggest to use the names:
Auto commit:  [To application/To preedit]
which makes me think that I do not understand
anything even now.
As you explained, preedit is used in Direct
mode too - for selecting the candidates in
translit, for example. If this is true, how
would I justify the "Auto commit to preedit"?
It is already in preedit when I am selecting
the candidates! So how can I commit from
preedit to preedit?
Oh well, I guess that's hopeless... I probably
can't understand ibus. :)

(In reply to Stas Sergeev from comment #8)

> The most important thing is that there
> seem to be 2 separate preedit phases:
> 1 allows you to select candidates for
> a single char
> 2 allows you to select a short-cut for
> some previous typing.

Yes.

> So while Normal mode has both, Direct
> mode has just the first one.
> Is this understanding correct?

Yes.

2 still exists in direct mode, one can still commit manually to
preedit phase 2 by pressing the left shift key or the arrow left/right
keys.  But in direct mode, all automatic commits bypass phase 2 and go
directly to the application.

> If I know there are 2 different preedit
> stages and Direct mode disables just one,

Yes, that is about correct. It disables automatic
commits to phase 2.

> I would probably get that all with much
> fewer efforts. :)
> When you said preedit is not needed for
> translit, I was entirely confused. But
> it appears only stage 2 is not needed,

Yes.

> but you still need stage 1 to select
> candidates for c.

Yes.

> Now as rusle does not have stage 1, I
> was stuck at stage 2 in Normal mode when
> trying to move with an arrows.

When using rusle with "Normal commit mode", you can actually see
both stages.

Type “a” and you see _ф_ (underlined, black). This ist in stage
1. Then type arrow right or the left shift key and you see _ф_
(underlined, red).  This is in stage 2. Type some other character or a
space and the ф gets committed to the application and becomes black
without underline.

In “Direct commit mode”, typing “a” commits ф immediately to the
application bypassing both stage 1 and stage 2. Both stages are
useless for rusle. For translit, stage 1 has some uses (Like when
typing “C” and waiting for the next character to decide what to do)
but stage 2 is useless for translit as well.

> You seem to explain what the arrows do
> for stage 1: they select a candidate.

Yes.

> But this probably does not apply to my
> question, because in Normal mode I stuck
> at stage 2 where the binding could be
> defined. What do the arrows do for stage 2?

Move around in the text which is in stage 2.

> I tried to experiment with SKK but I don't
> see where is there a switch between
> Direct/Normal modes...

Are you really using ibus-skk not ibus-kkc? Both are Japanese input
methods, skk is a very old one, kkc a very modern one.

*None* of the Japanese input methods have something like stage 2
in ibus-table.

This committing of stuff to preedit, i.e. committing not to the
application but to something like stage 2 which can then again be
edited and finally committed seems to be a unique feature of
ibus-table.  I have never seen this in any other ibus input method.

I am not sure how useful this really is, it is a very complicated and
confusing thing. But it makes it possible to define new shortcuts fast
with Wubi. I did not want to destroy any features while I cleaned up
the code in ibus-table, so I kept that feature and just fixed the bugs
in this feature. I wonder about the usefulness of this quite exotic
feature myself though.

I want to add a different feature to define new shortcuts in a less
automatic way, like typing some shortcut, e.g. Ctrl+= (that was the
shortcut in SCIM for this feature), then pop up a dialog where one can
enter a key sequence and what the result for this key sequence should
be and then close that dialog. That makes defining shortcuts possible
for tables which do not have such automatic shortcut creation rules
like Wubi has:

### Rules for user define phrase construct: RULES =
ce2:p11+p12+p21+p22;ce3:p11+p21+p31+p32;ca4:p11+p21+p31+p-11

This defines shortcuts automatically from the string using these rules.

But for rusle, this feature cannot be enabled because any new
shortcut would cause problems.

So this feature on my todo list is not for rusle but more for other
tables.  Like adding a new user defined emoticon for emoji-table or
adding some mathematical symbol which is lacking in the latex table as
a user defined symbol.

> OK, I hope my understanding is now closer
> to the reality. Of course it could be in
> fact further away...

No, it is quite correct.

> For example, you suggest to use the names:
> Auto commit:  [To application/To preedit]
> which makes me think that I do not understand
> anything even now.
> As you explained, preedit is used in Direct
> mode too - for selecting the candidates in
> translit, for example. If this is true, how
> would I justify the "Auto commit to preedit"?

“Auto commit to preedit” means auto commit from stage 1 to stage 2.
“Auto commit to application” means auto commit from stage 2 to the
application, bypassing stage 2.

> It is already in preedit when I am selecting
> the candidates! So how can I commit from
> preedit to preedit?

The preedit when selecting candidates is what you call stage 1.
“Committing to preedit” means committing to stage 2, a special
stage of the preedit which no other ibus input method has,
only ibus-table has this.

> Oh well, I guess that's hopeless... I probably
> can't understand ibus. :)

That is only ibus-table. A really unusual feature of ibus-table.  This
is useful only for a handful input methods which have RULES=something
*and* USER_CAN_DEFINE_PHRASE=TRUE.  “git grep RULES” and “git grep
USER_CAN_DEFINE_PHRASE” in the repos shows me that these are only:

erbi-qs
wubi-haifeng86
wubi-jidian86

So only 3 of the tables currently available for ibus-table use this.
All 3 are for Chinese.

All others do not need stage 2.

(In reply to Mike FABIAN from comment #9)
> When using rusle with "Normal commit mode", you can actually see
> both stages.
> Type “a” and you see _ф_ (underlined, black). This ist in stage
> 1.
Why do I see it if there are no candidates to select?
I guess its not needed much?

> Then type arrow right or the left shift key and you see _ф_
> (underlined, red).
Instead, I see it non-underlined, selected.
Some setting mismatch I guess.

> > But this probably does not apply to my
> > question, because in Normal mode I stuck
> > at stage 2 where the binding could be
> > defined. What do the arrows do for stage 2?
> Move around in the text which is in stage 2.
Up and Down seem to do nothing.
I wonder if it is possible to allow free movement,
but I guess it is not easy to implement.

> Are you really using ibus-skk not ibus-kkc? Both are Japanese input
> methods, skk is a very old one, kkc a very modern one.
In GUI I have only Japanese SKK. There is also some
Kana Kanji - is this kkc?

> I am not sure how useful this really is, it is a very complicated and
> confusing thing.
That's why I thought it may not be in the main
GUI. :) It could be in some advanced GUI.
But I understand your proposal about the different
short-cut mechanism.

> “Auto commit to preedit” means auto commit from stage 1 to stage 2.
> “Auto commit to application” means auto commit from stage 2 to the
> application, bypassing stage 2.
Well, this means “Auto commit to preedit” is likely
still not the best name. Much better than "Normal mode"
of course. :) But if you are about to remove that entirely
and replace the functionality, then what's the deal at all.

(In reply to Stas Sergeev from comment #10)
> (In reply to Mike FABIAN from comment #9)
> > When using rusle with "Normal commit mode", you can actually see
> > both stages.
> > Type “a” and you see _ф_ (underlined, black). This ist in stage
> > 1.
> Why do I see it if there are no candidates to select?
> I guess its not needed much?

You see it *only* in “Normal commit mode” in rusle. You do not need
to worry about this, because, as I wrote, I will disable normal commit
mode for rusle.

> > Then type arrow right or the left shift key and you see _ф_
> > (underlined, red).
> Instead, I see it non-underlined, selected.
> Some setting mismatch I guess.

I guess  you tried arrow *left*, not arrow *right*.
When you use arrow left, of course you put the cursor
*on* the character, not directly after the character.

> > > But this probably does not apply to my
> > > question, because in Normal mode I stuck
> > > at stage 2 where the binding could be
> > > defined. What do the arrows do for stage 2?
> > Move around in the text which is in stage 2.
> Up and Down seem to do nothing.
> I wonder if it is possible to allow free movement,
> but I guess it is not easy to implement.

What should up and down do if you are in stage 2?  There is nothing
meaningful they could do. If you are in stage 2 you can edit tne
contents of stage 2. As soon as you start typing again somewhere
inside the text in stage 2, of course up and down work again to select
the candidates.  Maybe you have to try wubi if you want to understand
how this works.

> > Are you really using ibus-skk not ibus-kkc? Both are Japanese input
> > methods, skk is a very old one, kkc a very modern one.
> In GUI I have only Japanese SKK. There is also some
> Kana Kanji - is this kkc?

Yes, Kana Kanji is kkc.

> > I am not sure how useful this really is, it is a very complicated and
> > confusing thing.
> That's why I thought it may not be in the main
> GUI. :) It could be in some advanced GUI.
> But I understand your proposal about the different
> short-cut mechanism.

> > “Auto commit to preedit” means auto commit from stage 1 to stage 2.
> > “Auto commit to application” means auto commit from stage 2 to the
> > application, bypassing stage 2.
> Well, this means “Auto commit to preedit” is likely
> still not the best name. Much better than "Normal mode"
> of course. :) But if you are about to remove that entirely
> and replace the functionality, then what's the deal at all.

I will disable it for *rusle*. But *not* for Wubi.
So nothing is replaced, that functionality is just disabled
for input methods which don’t need it like rusle.

Created attachment 933266 [details]
right arrow pressed

Created attachment 933267 [details]
left arrow pressed

(In reply to Mike FABIAN from comment #11)
> > Instead, I see it non-underlined, selected.
> > Some setting mismatch I guess.
> I guess  you tried arrow *left*, not arrow *right*.
Attached 2 screen shots.
One with right arrow, one with left.
The difference is very minor: after Left,
cursor disappears.
When I was doing a screen shot with Alt-PrtSc,
the preedit buffer was erased. Fortunately, on
the screens shot it is still there, but it immediately
removes the last char.

> > Up and Down seem to do nothing.
> > I wonder if it is possible to allow free movement,
> > but I guess it is not easy to implement.
> What should up and down do if you are in stage 2?
Navigate you through the previously typed text, up
and down. :)

>  There is nothing
> meaningful they could do.
The problem I want to point is that user gets locked
inside some text region with no obvious way to escape
it. When I see a menu with candidates, I know that the
arrows will navigate me through that menu. Or I can
just close that menu.
When I see a cursor, I know that arrays will navigate
me through the whole text. When this doesn't happen I
report bug. :)
Please note that any attempt to escape the preedit region
either does not work or cause it to disappear. IMHO
this is a bad usability decision. I am not pretending
to be a usability expert, but I think it would be much
better to let user navigate the whole text as he used
to, and if he leaves the preedit region, perhaps it
should be committed as is, rather than to disappear.

> I will disable it for *rusle*. But *not* for Wubi.
> So nothing is replaced, that functionality is just disabled
> for input methods which don’t need it like rusle.
I was referring to this:
---
I want to add a different feature to define new shortcuts in a less
automatic way, like typing some shortcut, e.g. Ctrl+= (that was the
shortcut in SCIM for this feature)
---
IMHO this is much better than what we have now.
So I thought you are going to remove the "Normal" thing.
If it will stay (even just for some layouts), at least
I hope it will not be as easily switchable by mistake
as it currently is (either by occasionally hitting a
short-cut key, or clicking it in the lang applet menu).

As for the user-friendly names.
Just a proposal.
How about "Short-cut assignment mode: [On/Off]"?
Firstly, user does not know what preedit is and
how many stages it has.
Secondly, "Short-cut assignment mode" hints the
user about the fact that it is not a normal typing
mode, so he will unlikely enable it if he wants
just to type text.

(In reply to Stas Sergeev from comment #14)
> (In reply to Mike FABIAN from comment #11)
> > > Instead, I see it non-underlined, selected.
> > > Some setting mismatch I guess.
> > I guess  you tried arrow *left*, not arrow *right*.
> Attached 2 screen shots.
> One with right arrow, one with left.
> The difference is very minor: after Left,
> cursor disappears.
> When I was doing a screen shot with Alt-PrtSc,
> the preedit buffer was erased. Fortunately, on
> the screens shot it is still there, but it immediately
> removes the last char.

Oh, firefox seems to do something special there to override the
appearance of the preëdit.  Try the same in gedit or gnome-terminal,
then you see the preëdit colouring done by ibus-table.

> > > Up and Down seem to do nothing.
> > > I wonder if it is possible to allow free movement,
> > > but I guess it is not easy to implement.
> > What should up and down do if you are in stage 2?
> Navigate you through the previously typed text, up
> and down. :)

That makes no sense in stage 2.

> >  There is nothing
> > meaningful they could do.

> The problem I want to point is that user gets locked
> inside some text region with no obvious way to escape
> it. When I see a menu with candidates, I know that the
> arrows will navigate me through that menu. Or I can
> just close that menu.
> When I see a cursor, I know that arrays will navigate
> me through the whole text. When this doesn't happen I
> report bug. :)

But for any Chinese user, it is obvious that this preëdit
can be committed by typing space.

> Please note that any attempt to escape the preedit region
> either does not work or cause it to disappear.

Space commits it and ESC kills it. That is normal and obvious.

> IMHO
> this is a bad usability decision. I am not pretending
> to be a usability expert, but I think it would be much
> better to let user navigate the whole text as he used
> to, and if he leaves the preedit region, perhaps it
> should be committed as is, rather than to disappear.
> 
> > I will disable it for *rusle*. But *not* for Wubi.
> > So nothing is replaced, that functionality is just disabled
> > for input methods which don’t need it like rusle.
> I was referring to this:
> ---
> I want to add a different feature to define new shortcuts in a less
> automatic way, like typing some shortcut, e.g. Ctrl+= (that was the
> shortcut in SCIM for this feature)
> ---
> IMHO this is much better than what we have now.

It is not “better” but “different”.

The current method to define new shortcuts in Wubi is very automatic,
it needs very little extra typing and clicking.  A Wubi user can just
stay in “Normal commit mode” and type away, committing from time to
time to the applicationi using space.  Everything between one space
and the next then gets a new shortcut defined.  Probably useful to
define lots of shortcuts for many longer strings just during normal
typing with little extra effort.

The idea to open a new dialog has advantages and disadvantages:

+ more obvious to use
+ shortcuts definable even for tables which do not have RULES
+ even for tables which do have RULES, special shortcuts differing
  from these RULES can be defined if desired
+ shortcuts can be defined even for stuff which cannot be typed
  with the current input method (Because in the dialog one can switch
  to a different input method. For example one could define a shortcut
  for something like ☺ in an input method which cannot enter such a
  character, after defining such a shortcut it can)

- More typing and clicking required compared to the current method
  to define shortcuts in Wubi automatically.
- as shortcuts are completely user define they don’t need to follow
  any rules and thus the user may need to remember them.

> So I thought you are going to remove the "Normal" thing.
> If it will stay (even just for some layouts), at least
> I hope it will not be as easily switchable by mistake
> as it currently is (either by occasionally hitting a
> short-cut key, or clicking it in the lang applet menu).

It will stay only for the 3 Chinese input methods I mentioned.  For
these 3, I think it is OK, it is much more obvious what happens there
compared to what you experienced with rusle.

(In reply to Stas Sergeev from comment #15)
> As for the user-friendly names.
> Just a proposal.
> How about "Short-cut assignment mode: [On/Off]"?
> Firstly, user does not know what preedit is and
> how many stages it has.
> Secondly, "Short-cut assignment mode" hints the
> user about the fact that it is not a normal typing
> mode, so he will unlikely enable it if he wants
> just to type text.

It can be used as a normal typing mode in Wubi.
I guess the current  naming “Normal commit” was chosen
by the original developer of ibus-table because he
considered what you call “Short cut defining mode”
as the “normal mode of operation”, not some weird
feature which is rarely used. Defining lots 
of new shortcuts all the time may be quite helpful
for  Wubi.

Created attachment 933617 [details]
0001-Disable-auto_commit-option-for-tables-which-do-not-h.patch

Patch to fix the problem.

Seems to work, thanks! :)

ibus-table-1.8.10-1.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/ibus-table-1.8.10-1.fc19

ibus-table-1.8.10-1.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/ibus-table-1.8.10-1.fc20

Hello Mike, any treatment to the "Phrase mode"?
IIRC you wanted to disable it for rusle too?

(In reply to Stas Sergeev from comment #22)
> Hello Mike, any treatment to the "Phrase mode"?
> IIRC you wanted to disable it for rusle too?

I did. 

See:

https://admin.fedoraproject.org/updates/ibus-table-1.8.10-1.fc20

https://github.com/kaio/ibus-table/releases/tag/1.8.10

> Disable auto_commit option for tables which do not have RULES
> Resolves: rhbz#1135759 https://bugzilla.redhat.com/show_bug.cgi?id=1135759
> Disable hotkey to switch Chinese mode if database is not Chinese
> Disable “onechar” (Phrase mode/Single char mode) option for non-CJK databases

Ah, thanks!
You just haven't posted the patch here, so
I thought you didn't.

Package ibus-table-1.8.10-1.fc20:
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing ibus-table-1.8.10-1.fc20'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-10317/ibus-table-1.8.10-1.fc20
then log in and leave karma (feedback).

ibus-table-1.8.11-1.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/ibus-table-1.8.11-1.fc19

ibus-table-1.8.11-1.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/ibus-table-1.8.11-1.fc20

ibus-table-1.9.0-1.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/ibus-table-1.9.0-1.fc19

ibus-table-1.9.0-1.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/ibus-table-1.9.0-1.fc20

ibus-table-1.9.0-1.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.

ibus-table-1.9.0-1.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.