Bug 1140502
Summary: | Commit preedit even if someone press right-left arrow | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Pravin Satpute <psatpute> |
Component: | ibus-typing-booster | Assignee: | Mike FABIAN <mfabian> |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 20 | CC: | apatil, i18n-bugs, mfabian, smaitra |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | ibus-typing-booster-1.2.11-1.fc21 | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2014-10-11 07:00:09 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Pravin Satpute
2014-09-11 07:09:11 UTC
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. |