Bug 1140502 - Commit preedit even if someone press right-left arrow
Summary: Commit preedit even if someone press right-left arrow
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: ibus-typing-booster
Version: 20
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Mike FABIAN
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-09-11 07:09 UTC by Pravin Satpute
Modified: 2014-11-17 06:30 UTC (History)
4 users (show)

Fixed In Version: ibus-typing-booster-1.2.11-1.fc21
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-10-11 07:00:09 UTC
Type: Bug


Attachments (Terms of Use)

Description Pravin Satpute 2014-09-11 07:09:11 UTC
Description of problem:
This has become very problematic.
If i type something and commit i get space at end of word. But if i want to remove that space with backspace key. Typing booster immediately capture previous text and again start showing candidate window. 

Again if i press commit, again i get extra space :( This keeps on going on. 



Version-Release number of selected component (if applicable):
ibus-typing-booster-1.2.10-2.fc20.noarch

How reproducible:
Everytime

Steps to Reproduce:
1. Type some work with ibus-typing-booster selecting marathi-hunspell itrans IME
2. press "pravin" and press space.
3. You will get extra space. Try to remove extra space with backspace
4. Again pravin get selected in candidate

Actual results:
cant get rid of extra space. 

Expected results:
Space should not come again. I think making right-left arrow key commit the candidate without adding space will do the job. Hopefully it will again not select candidate.

Additional info:
This can be problematic when use select horizontal viewing of candidate window since it can affect selecting candidate in horizontal view.

Comment 1 Mike FABIAN 2014-09-22 05:20:18 UTC
Opening the preedit again was requested in:

https://bugzilla.redhat.com/show_bug.cgi?id=1032442

Comment 2 Pravin Satpute 2014-09-22 05:52:59 UTC
Yeah, i do remember :)

Problem scenario is here, if i select word from candidate i get extra space and now if i want to remove that extra space when i space backspace again word get selected in preedit.

I think its happening due to my perception. i.e. typing DOT, COMMA, DOUBLE QOUTE only when word is not in preedit. 

We can definitely type these marks even in preedit and press space. 


Why cant we commit word when one press either  comma, DOT, or quotes?

Comment 3 Mike FABIAN 2014-09-22 07:09:45 UTC
(In reply to Pravin Satpute from comment #2)

> Why cant we commit word when one press either  comma, DOT, or quotes?

You can do that as long as no transliteration is used.

For example, when using German, one has the choice between

  - Native keyboard
  - Latin-Pre
  - Latin-Post

(in the setup tool).

When using Native keyboard, typing a . commits.

But when using transliteration, e.g. Latin-Pre or Latin-Post,
the dot might be part of a transliteration and not a literal dot.

For example, typing “.c” in Latn-Pre gives a “ċ”. Therefore,
one cannot commit when a . is typed because one does not yet know
what follows, this might not be intended as a literal dot.

Whether a . could compose with something following or not depends
on the transliteration method used of course. Currently, I do
not commit immediately when a . is typed if *any* transliteration
is used. This is the code:

            if typed_character and unicodedata.category(typed_character) in itb_util.categories_to_trigger_immediate_commit:
                input_phrase = self._editor.get_transliterated_string()
                if input_phrase and input_phrase[-1] == typed_character and not self._editor.trans_m17n_mode:
                    self.commit_string(input_phrase + u' ', input_phrase = input_phrase)


So it is not only done for . but for all characters which have one
of these categories:

categories_to_trigger_immediate_commit = ['Po', 'Pi', 'Pf', 'Ps', 'Pe', 'Pc', 'Sm', 'Sc']

If no transliteration is used, it can be immediately committed when
one such characters is encountered. When transliteration is used, it
depends on which transliteration exactly is used whether a commit is
possible or whether one has to wait. In this check:

     if input_phrase and input_phrase[-1] == typed_character and not self._editor.trans_m17n_mode:

I also check whether the last character typed is still the last character
of the input phrase. For example, with some transliterations like
Latn-Post, “c.” gives a “ċ”. In that case, input_phrase[-1] is “ċ”,
i.e. it is *not* the . which has been typed last because that dot
has been combined with something else already because of the transliteration.
So for such types of transliterations, committing is possible
if input_phrase[-1] == typed_character because that means that the
. is really a dot. But for some types of transliterations, such a trailing
. could be combined with stuff which follows, therefore direct commit is not
possible. That’s why I have the

    and not self._editor.trans_m17n_mode:

at the moment, which disables this direct commit for *all* transliterations.

I could list the transliterations separately here:

   if input_phrase and input_phrase[-1] == typed_character and not self._current_ime in ['t-latn-pre', ..... all transliterations here which could combine such stuff with characters typed later ...]

i.e. prevent commit only for transliterations where a . (or other such
characters from categories_to_trigger_immediate_commit could possibly
combine with stuff typed later).

Comment 4 Mike FABIAN 2014-09-22 07:16:59 UTC
(In reply to Pravin Satpute from comment #2)
> Yeah, i do remember :)
> 
> Problem scenario is here, if i select word from candidate i get extra space
> and now if i want to remove that extra space when i space backspace again
> word get selected in preedit.

Currently you could use the following as a workaround:

   Instead of typing backspace, type arrow-left and delete.

> I think its happening due to my perception. i.e. typing DOT, COMMA, DOUBLE
> QOUTE only when word is not in preedit. 
> 
> We can definitely type these marks even in preedit and press space. 

You can also type a dot after committing *without* removing the space
(only if surrounding text is supported!). For example, if you type

    “word”

and then commit by typing space you have:

    “word ”

If you now type a . (and surrounding text is supported), then
the . and the “ ” will be exchanged automatically and you get

    “word. ”

If surrounding text is not supported, this gives you

    “word .”

(for example in gnome-terminal surrounding text does not work).

But if surrounding text is not supported, then typing backspace
will not be able to open the preedit again either, i.e. then
it is not problem using backspace.

I am checking whether I can make the arrow keys better as well though.

Comment 5 Mike FABIAN 2014-09-22 07:21:46 UTC
latin-pre is not the only example where . (and other such
characters) cannot be committed immediately because
characters  typed later might transliterate together
with the “.”. Another example is /usr/share/m17n/mr-itrans.mim:

$ grep '"\.' /usr/share/m17n/mr-itrans.mim 
  (".") ("~") ("#") ("$") ("^") ("*") ((S-\ )) ((C-@))
  (".D" "ड़्")
  (".Dh" "ढ़्")
  (".c" "ऍ")			      ; not in ITRANS Devanagari table
  (".N" "ँ")
  (".n" "ं")
  (".a" "ऽ")
  (".h" "्")
  (".." "।")			      ; not in ITRANS Devanagari table
  (".c" (delete @-) "ॅ")	      ; not in ITRANS Devanagari table
mfabian@ari:~
$

Comment 6 Pravin Satpute 2014-09-22 07:24:25 UTC
Yeah, i remembered those tricky key mapping now in transliteration.

I liked the workaround. Its solving the issue.

If you dont have any improvement plan for this bug, feel free to close as a NOTABUG :)

Comment 7 Fedora Update System 2014-09-24 12:23:25 UTC
ibus-typing-booster-1.2.11-1.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/ibus-typing-booster-1.2.11-1.fc19

Comment 8 Fedora Update System 2014-09-24 12:23:59 UTC
ibus-typing-booster-1.2.11-1.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/ibus-typing-booster-1.2.11-1.fc20

Comment 9 Fedora Update System 2014-09-25 10:36:32 UTC
Package ibus-typing-booster-1.2.11-1.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing ibus-typing-booster-1.2.11-1.fc19'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-11392/ibus-typing-booster-1.2.11-1.fc19
then log in and leave karma (feedback).

Comment 10 Fedora Update System 2014-10-11 07:00:09 UTC
ibus-typing-booster-1.2.11-1.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 11 Fedora Update System 2014-10-11 07:03:28 UTC
ibus-typing-booster-1.2.11-1.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 12 Pravin Satpute 2014-10-13 03:37:54 UTC
looks good now :)

Thanks you for fix.

Comment 13 Fedora Update System 2014-11-05 06:44:15 UTC
ibus-typing-booster-1.2.11-1.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/ibus-typing-booster-1.2.11-1.fc21

Comment 14 Fedora Update System 2014-11-17 06:30:39 UTC
ibus-typing-booster-1.2.11-1.fc21 has been pushed to the Fedora 21 stable repository.  If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.