Hide Forgot
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.
Opening the preedit again was requested in: https://bugzilla.redhat.com/show_bug.cgi?id=1032442
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?
(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).
(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.
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:~ $
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 :)
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
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
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).
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.
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.
looks good now :) Thanks you for fix.
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
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.