What settings are you using?

Can you please paste your settings here, like this:

$ dconf dump /desktop/ibus/engine/table/rusle/
[/]
onechar=false
inputmode=1
lookuptablepagesize=9
lookuptableorientation=true
autowildcard=true
multiwildcardchar=''
singlewildcardchar=''
alwaysshowlookup=false
autoselect=true
endeffullwidthpunct=false
tabdeffullwidthpunct=false
spacekeybehavior=false
chinesemode=0
tabdeffullwidthletter=false
autocommit=true
endeffullwidthletter=false
mfabian@ari:~
$

(What I pasted in comment#1 are the default settings, one can
return to the default settings by clicking on the “Restore all defaults”
button in the setup tool.

(In reply to Stas Sergeev from comment #0)

> When using rusle table, space doesn't always work right.
> I am attaching the text file where I was typing the random
> letters and space. As you can see, space generated very
> strange code sequences.

What was the input sequence you typed to get this?

The attached file seems to contain:

    ау　ацй　пукнр　р　пуц　вы

But it is not easy to see for me what went wrong here.


> How to reproduce:
> 1. Select rusle
> 2. Type something with spaces immediately following the
> punctuation chars like . ,

So I should type something like for example

   "abc& "

?

When I type "abc& ", I get "фис. ", which seems to be correct.

Is it possible to give exact instructions to reproduce the problem?
Or is there some randomness involved so you cannot reproduce it always?

Hi Mike, I will provide the cunfiguration dump
later when I am home.

Yes, there is indeed the randomness involved, but
most usually the problem happens when I type comma then space.
That is, I press Shift-6 (comma) then press space.
After that, spaces starts to produce strange chars.

The file I attached, only _looks_ good.
Please open it in a hex editor. You'll see that the
spaces are actually not quite the 0x20 chars. This is
some kind of very strange spaces.

(In reply to Stas Sergeev from comment #4)

> The file I attached, only _looks_ good.
> Please open it in a hex editor. You'll see that the
> spaces are actually not quite the 0x20 chars. This is
> some kind of very strange spaces.

Ah, I see. The spaces in

"ау　ацй　пукнр　р　пуц　вы"

are U+3000 IDEOGRAPHIC SPACE

(i.e. the fullwidth space sometimes used in Japanese and Chinese).

mfabian@ari:~/bugs/redhat/1128912
$ cat a.txt 
ау　ацй　пукнр　р　пуц　вы
mfabian@ari:~/bugs/redhat/1128912
$ cat a.txt | iconv -f utf-8 -t utf16be | od -t x1 -t a 
0000000  04  30  04  43  30  00  04  30  04  46  04  39  30  00  04  3f
        eot   0 eot   C   0 nul eot   0 eot   F eot   9   0 nul eot   ?
0000020  04  43  04  3a  04  3d  04  40  30  00  04  40  30  00  04  3f
        eot   C eot   : eot   = eot   @   0 nul eot   @   0 nul eot   ?
0000040  04  43  04  46  30  00  04  32  04  4b  00  0a
        eot   C eot   F   0 nul eot   2 eot   K nul  nl
0000054
mfabian@ari:~/bugs/redhat/1128912
$

It looks like I can reproduce the problem With these settings:

    $ dconf dump /desktop/ibus/engine/table/rusle/
    [/]
    onechar=false
    inputmode=1
    lookuptablepagesize=9
    lookuptableorientation=true
    autowildcard=true
    multiwildcardchar=''
    singlewildcardchar=''
    alwaysshowlookup=false
    autoselect=true
    endeffullwidthpunct=false
    tabdeffullwidthpunct=false
    spacekeybehavior=false
    chinesemode=0
    tabdeffullwidthletter=true   <---------------- !!!
    autocommit=true
    endeffullwidthletter=false
    $

I did set the option “Table input letter width” in
the setup tool to “Full” (I marked the respective
dconf option above).

Now, when I type "abc^ ", the result is "фис,　" where the space
following the "," is the fullwidth space U+3000.

My guess is that you did accidentally set the option mentioned in 
comment#6.

That option does not make any sense for languages which
are neither Japanese, Chinese, nor Korean (CJK).

So maybe for non-CJK languagues, these fullwidth/halfwidth options should
not be offered at all in the setup tool.

SCIM apparently had the options

USE_FULL_WIDTH_PUNCT = FALSE/TRUE
USE_FULL_WIDTH_LETTER = FALSE/TRUE
DEF_FULL_WIDTH_PUNCT = FALSE/TRUE
DEF_FULL_WIDTH_LETTER = FALSE/TRUE

in the sources for the databases. DEF_FULL_WIDTH_PUNCT and
DEF_FULL_WIDTH_LETTER are used by ibus-table as well and
define the default values for the fullwidth/halfwidth options.

USE_FULL_WIDTH_PUNCT and USE_FULL_WIDTH_LETTER are ignored
by ibus-table, support for these was apparently never implemented.

The intention of USE_FULL_WIDTH_PUNCT and USE_FULL_WIDTH_LETTER is to
indicated whether this particular table wants to use
fullwidth/halfwidth at all.

So one way to improve this would be to make
ibus-table read the options USE_FULL_WIDTH_PUNCT and USE_FULL_WIDTH_LETTER
as well from the database, and if they are set to false
then never do any translation to fullwidth, do not show
the related option in the setup tool, and do not show the options in
the menu of panel. If I go for this, some database sources
need to be updated to add the USE_FULL_WIDTH_PUNCT and USE_FULL_WIDTH_LETTER
options.

Another possibility would be to use the option LANGUAGES in the database
sources. For a typical Chinese table, this is set to

   LANGUAGES = zh_CN,zh_SG,zh_TW,zh_HK

and for a Russian table it is set to:

   LANGUAGES = ru_RU

As fullwidth/halfwidth never makes any sense for non-CJK languages,
I could enable the fullwidth/halfwidth options only
when LANGUAGES contains any language starting
with zh, ja, or ko.

That would have the advantage that none of the current table
sources would need to be changed.

Another thing:

There is the option “Chinese mode” in the setup tool, which
makes sense only if the table supports Chinese.

I should also avoid displaying that option in the setup tool
for tables which do not support Chinese anyway
(This option is already suppressed in the panel menu
if the table does not support Chinese but it is still visible
in the setup tool for non-Chinese tables).

But how would you explain the randomness factor?
And please note that to enable the bug, you need
(in most cases) to first type comma-space. If you
don't type that, then space is normal.
Also the bug mode can be disabled the same way.
If you type comma-space again, the bug mode may
disappear.
So I wonder if this really is not a bug.
Even if settings are wrong, the behaviour should
be more consistent than that.

(In reply to Stas Sergeev from comment #8)
> But how would you explain the randomness factor?

I have no explanation for the randomness. Are you sure 
that you are seeing randomness? So far it is deterministic for me.

> And please note that to enable the bug, you need
> (in most cases) to first type comma-space. If you
> don't type that, then space is normal.

With “Table input letter width” set to “Full”, the spaces
between words are *always* fullwidth spaces for me,
I do not have to type comma-space to trigger that.

> Also the bug mode can be disabled the same way.
> If you type comma-space again, the bug mode may
> disappear.
> So I wonder if this really is not a bug.
> Even if settings are wrong, the behaviour should
> be more consistent than that.

It might be that you are seeing something different
which I could not reproduce yet.

Now I have an idea to explain the randomness:

For both “,” and “.” you have to press Shift. “^” (Shift-6) inserts “,”
and “&” (Shift-7) inserts “.”.

But Shift-Space toggles between fullwidth and halfwidth letter mode!

So if you type ^ and don’t get your finger fast enough off
the Shift key before typing the following space, no space is
inserted but the fullwidth/halfwidth letter mode is toggled.

How fast you get your finger of the shift key is a timing issue which
explains the “randomness”.

That you are accidentally toggling the fullwidth/halfwidth letter mode
with Shift-Space seems much more likely than that you toggled
it in the setup tool. Because if you did it in the setup tool you
would surely remember and it would not appear random.

Yes, I never did that in a setup tool.
I'll check if Shift-Space is the problem.
So if it is, how can I get rid of that madness?

The shortcut keys can be seen in the source code:

https://github.com/kaio/ibus-table/blob/master/engine/table.py#L1402

        if self._full_width_letter[self._input_mode]:
            self._set_property(
                self._letter_property,
                'full-letter.svg',
                _('Fullwidth letters'),
                _('Switch to “Halfwidth letters” (Shift-Space)'))
        else:
            self._set_property(
                self._letter_property,
                'half-letter.svg',
                _('Halfwidth letters'),
                _('Switch to “Fullwidth letters” (Shift-Space)'))
        self.update_property(self._letter_property)

and in the wiki:

https://code.google.com/p/ibus/wiki/TableReadme

That is not very nice, it is hard to find.

When not using Gnome3, ibus can also show a floating panel and
this displays the tooltips like

    _('Switch to “Fullwidth letters” (Shift-Space)')

But in Gnome3, these properties are only available in the panel menu
which does not show the tooltips.

Probably I should add the shortcut key descriptions to the menu
entries as well to make them easier to discover for the user.

(In the long run, I should make these shortcut keys configurable ...)

(In reply to Stas Sergeev from comment #12)
> Yes, I never did that in a setup tool.
> I'll check if Shift-Space is the problem.
> So if it is, how can I get rid of that madness?

There is no way to get rid of the Shift-Space behaviour at the moment.

I think I should disable the fullwidth/halfwidth options
for tables which are for other languages than Chinese, Japanese, or
Korean.

And disable the Chinese mode switching as well for tables which
are not Chinese.

That should fix the problem for you because then the Shift-Space
keyboard shortcut would be gone for non-CJK tables.

Sounds good, thank you!

Yes Mike, your diagnostic about me
pressing Shift-Space was correct.
I am really glad to finally see some activity
at supporting Russian users. All these years
long it was not possible to even log into a
system!
https://bugzilla.redhat.com/show_bug.cgi?id=1101006
and no one cared. I have to use fedora-14 on
most PCs these days...
Lets resurrect the Russian support!
I'll report other Russian-related problems into
a separate tickets.

I filled
https://bugzilla.redhat.com/show_bug.cgi?id=1129446
https://bugzilla.redhat.com/show_bug.cgi?id=1129449
https://bugzilla.redhat.com/show_bug.cgi?id=1129452
so far.

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

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

Package ibus-table-1.8.8-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.8-1.fc20'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-9473/ibus-table-1.8.8-1.fc20
then log in and leave karma (feedback).

Hi Mike, I tested the package.
It works better: no switch to bug mode any more.
BUT: Shift-Space still doesn't produce space.
Could you please fix also that?

Checking ...

I noticed another problem.
When I type, the layout ocasionally changes back
to EN, even though I do not press the modifier combo.
The switcher applet still shows RU, but the typing
becomes latinic.
Presumably this happens after Shift-Space, but again,
not always... So we have another puzzle. I wonder if
you can make a sharp guess or reproduce that...

Created attachment 929759 [details]
0001-Ignore-Shift-Space-hotkey-to-switch-fullwidth-halfwi.patch

To fix the problem in comment#21

(In reply to Stas Sergeev from comment #23)
> I noticed another problem.
> When I type, the layout ocasionally changes back
> to EN, even though I do not press the modifier combo.
> The switcher applet still shows RU, but the typing
> becomes latinic.
> Presumably this happens after Shift-Space, but again,
> not always... So we have another puzzle. I wonder if
> you can make a sharp guess or reproduce that...

You are switching between table mode ("rusle") and direct input mode
(using the underlying keyboard layout directly).

The hotkey for this is the left shift key (Without space, just
left shift and release it).

You can see which mode you are in if you open the input method menu in
the gnome panel while rusle is active. Look at the 4 menu entries near
the bottom:

   Direct input (Left Shift)
   Phrase mode (Ctrl-;)                <- quite useless for rusle
   Direct commit mode (Ctrl-/)         <- quite useless for rusle
   Setup 

If you hit the left shift key and look again, you see that the topmost
of these "property" menus toggles between

   Direct input (Left Shift)  <-> Р (Left Shift)

I am not sure what I can do about this now.

For Chinese, this is used often as a quick way to toggle between
Chinese and English mode (faster than switching between two input
sources).  That might be the reason why the original developer of
ibus-table did choose the left shift key as the hot key for that.

The disadvantage is of course that the left shift key can be hit far
too easily.

In the long run, I want to make the keybindings configurable, then
you could set that keybinding to empty. But I have no time for that
soon, that is a bit more work.

Choosing a different shortcut is not nice to existing users.

Disabling that shortcut for non-CJK input methods might also be
not so nice. Maybe one wants to quickly toggle between direct
input and a non-CJK input method as well.

So I am a bit puzzled what to do about this now.

Maybe wait until I have time to make the keybindings configurable?

> Maybe wait until I have time to make the keybindings configurable?
Maybe I have no other option than to agree with this? :)
Anyway, another sharp guess, you are right, left shift
is the culprit. Thank you.

So, should I open a separate report for this or what?

(In reply to Mike FABIAN from comment #24)
> Created attachment 929759 [details]
> 0001-Ignore-Shift-Space-hotkey-to-switch-fullwidth-halfwi.patch
> 
> To fix the problem in comment#21
Patch tested and works.

(In reply to Stas Sergeev from comment #26)
> > Maybe wait until I have time to make the keybindings configurable?
> Maybe I have no other option than to agree with this? :)
> Anyway, another sharp guess, you are right, left shift
> is the culprit. Thank you.
> 
> So, should I open a separate report for this or what?

Yes, I think a separate bug report is helpful so I do not forget this.

Maybe, as a temporary workaround, I disable that hotkey for non-CJK
and enable it again as soon as the hotkeys are configurable.

I really should make the hotkeys configurable ...

Done as Bug #1133127

I noticed another strange problem.
In pidgin, an ICQ client, Enter it a hotkey
that sends the typed message.
The interesting thing is that now with rusle
it seems the Keypad Enter behaves differently
than normal Enter. Namely, it doesn't send
the message, but instead moves to new line.
What do you think is that?
With EN or other layouts the Keypad Enter
sends the msg similar to normal Enter.

(In reply to Stas Sergeev from comment #30)
> I noticed another strange problem.
> In pidgin, an ICQ client, Enter it a hotkey
> that sends the typed message.
> The interesting thing is that now with rusle
> it seems the Keypad Enter behaves differently
> than normal Enter. Namely, it doesn't send
> the message, but instead moves to new line.
> What do you think is that?
> With EN or other layouts the Keypad Enter
> sends the msg similar to normal Enter.

I can confirm that, investigating ...

Created attachment 929865 [details]
0001-Pass-IBus.KEY_KP_Enter-to-the-application-if-the-pre.patch

To fix the problem in comment#30

The patch from comment#32 seems to work but there is some problem with my reasoning why it works, checking again ...

Created attachment 929877 [details]
0001-Pass-IBus.KEY_KP_Enter-to-the-application-if-the-pre.patch

No, my reasoning was correct. I only made a typo in the comment,
it is IBus.KEY_Return, not IBus.KEY_KP_RETURN.

Confirming tha patch.
Thanks!

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

ibus-table-1.8.8-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.8.8 does not yet have the fix from comment#34, 1.8.9 will have it.

Hi Mike, I just opened a separate tickets
for the remaining 2 patches, so we can have
this closed.

Good,thank you!