Description of problem: after typing word if someone type punctuation marks it should commit the preedit buffer. Since normally punctuation indicates completion of word, so it will create good user experience for users. Version-Release number of selected component (if applicable): ibus-typing-booster-1.2.1-1.fc19.noarch How reproducible: everytime Steps to Reproduce: 1. type word "english" using i-t-b 2. press "." 2. it keeps all things in preedit buffer 3. Actual results: after pressing punctuation marks it does not commit the buffer. Expected results: it should commit the buffer, one space. So that user can directly start new word Additional info: As we discussed on Fedora i18n meeting, yet it conflicts with transliteration schemes keymap. I have one suggestion for solution: 1. Dont commit preedit buffer after user types punctuation mark key. But rather after passing it to libtranslit 2. Even after passing user typed word if libtranslit returns punctuation mark. Then immediately commit the word. I think this way should solve the problem of language dependence :)
just wondering how it will affect on processing speed, one extra condition.
IRC log discussing this bug: <mfabian> pravins: What do you think about this: https://git.fedorahosted.org/cgit/ibus-typing-booster.git/commit/?h=miketmp-debug&id=f117eb4469ab62ce142c00e3b58e9f335c0833d2 [13年07月08日 12:50:13] -i18nbot- Title: ibus-typing-booster.git - Unnamed repository; edit this file 'description' to name the repository. (at git.fedorahosted.org) [13年07月08日 12:50:14] * pravins reading [13年07月08日 12:50:41] <pravins> mfabian, yes looks good [13年07月08日 12:51:40] <pravins> mfabian, i have given one suggestion on bugzilla, might be you have already seen it [13年07月08日 12:52:05] <mfabian> First I used the same list of categories as those to strip from tokens. [13年07月08日 12:52:10] <mfabian> But then I didn’t like that when typing “up-to-date” a commit happened at up- [13年07月08日 12:52:35] <pravins> might be with it we can commit punctuation commit even for transliteration scheme as well? [13年07月08日 12:52:49] <pravins> "If we start word with single quote, it is coming in suggestion box. Since it is getting added as it is in db." [13年07月08日 12:53:41] <mfabian> That was a different bug, wasn’t it? [13年07月08日 12:54:06] <pravins> yes [13年07月08日 12:54:23] <mfabian> Words with leading quotes are not added to the database anymore, I strip punctuation and similar characters from the start and the end of words before adding them to the database. [13年07月08日 12:54:52] <pravins> yeah. i mistakenly looked at different bug ;) [13年07月08日 12:55:12] <pravins> .bug 981179 [13年07月08日 12:55:26] -i18nbot- pravins: Bug https://bugzilla.redhat.com/show_bug.cgi?id=981179 Fedora, ibus-typing-booster, NEW , RFE: punctuation marks should commit the preedit buffer [13年07月08日 12:55:29] <pravins> "Additional info:" [13年07月08日 12:55:39] <mfabian> And when the user starts typing something like “, I remove it for matching in the database and add it again to the returned candidates to make “col match “colour even though “col is not in the database, only col is in the database. [13年07月08日 12:55:55] <pravins> your commit is good in the improving punctuation handling. [13年07月08日 12:57:09] <pravins> i was just thinking if we can remove the dependency of transliteration schemes as well [13年07月08日 12:57:28] <mfabian> 1. Dont commit preedit buffer after user types punctuation mark key. [13年07月08日 12:57:34] <mfabian> <mfabian> But rather after passing it to libtranslit <mfabian> <mfabian> 2. Even after passing user typed word if libtranslit returns punctuation mark. Then immediately commit the word. [13年07月08日 12:57:35] <mfabian> <mfabian> is what you wrote. [13年07月08日 12:57:39] <pravins> yes [13年07月08日 12:57:49] <mfabian> Isn’t it difficult to know when to commit then? [13年07月08日 12:58:21] <mfabian> If typing a . we may wait for the next character. If the next character has been typed and the . is still there at the beginning of the transliterated string, can we be sure the the 3rd typed character would not change that? [13年07月08日 12:59:17] <pravins> aha, right [13年07月08日 12:59:46] <mfabian> Are there sequences longer than 2 characters starting with a punctuation character which get transliterated so something? [13年07月08日 13:00:07] <pravins> trans. scheme will not change single "." but rather some combination [13年07月08日 13:00:16] <pravins> yes. in mr-itrans.mim there are "a.y" [13年07月08日 13:00:44] <pravins> "e.c" .Dh type sequences get converted to valid characters [13年07月08日 13:01:46] <pravins> i got your point, how long to wait for commit after getting punctuation marks .. [13年07月08日 13:02:13] <pravins> tricky [13年07月08日 13:02:24] <mfabian> Lets says the user types “e.”. [13年07月08日 13:03:33] <mfabian> The, if a c follows, it should become ऍ [13年07月08日 13:03:48] <pravins> yes [13年07月08日 13:03:56] <mfabian> But if a different character, say “a” follows, i.e. we have “e.a”, then the transliteration will still have the “.” as the second last character, probably. [13年07月08日 13:04:34] <pravins> yes it will [13年07月08日 13:04:55] <pravins> and by that time user will press space to commit [13年07月08日 13:05:26] <mfabian> Then one may need to cut this into “e.”, and “a”, commit “e.” + “ ” and put the “a” back into the preëdit. [13年07月08日 13:05:35] <mfabian> After “e.” one may want to add the “ ”, but maybe not after “e~”? [13年07月08日 13:06:16] <pravins> there is one mapping for "~N" ङ् [13年07月08日 13:07:02] <pravins> so might be "e.~N" [13年07月08日 13:07:19] <mfabian> Looks quite complicated. [13年07月08日 13:07:38] <pravins> yes, agree with you [13年07月08日 13:07:56] <pravins> observing libtraslit o/p does not look helping much [13年07月08日 13:08:24] <pravins> since by the time we will wait for commit user will hit space when he will get his expected o/p [13年07月08日 13:08:49] <pravins> since by the time we will wait for commit, user will hit space when he will get his expected o/p [13年07月08日 13:08:59] <mfabian> If the user will type “ ” right after a punctuation mark, it will be committed [13年07月08日 13:13:24] <mfabian> when typing the space anyway. [13年07月08日 13:13:29] <mfabian> So in that case, committing early does not help that much, it only saves one keystroke, the space. [13年07月08日 13:14:00] <mfabian> And if something else but a space follows, it is unclear whether committing up to the punctuation character is useful or not. [13年07月08日 13:14:44] <pravins> agree [13年07月08日 13:16:47] <mfabian> Maybe, after each newly typed character, one could check whether the transliterated string contains punctuation characters with a distance from the end of the transliterated string longer than the longest possible sequence where transliteration still could happen (What is the longest possible sequence?) [13年07月08日 13:17:02] <mfabian> I.e., when the longest possible sequence were 4 and the preedit contains “abc.def” and we still find the “.” there, then we know that the “.” will not change anymore because “.def” has the maximum sequence length of 4 and the “.” has not been transliterated. [13年07月08日 13:18:16] <mfabian> So we could commit “abc. ” and put “def” back into the preëdit. [13年07月08日 13:18:32] <mfabian> I am confused whether that would make any sense or not. [13年07月08日 13:18:48] <pravins> yeah, that will not make much sense [13年07月08日 13:19:00] <mfabian> Also, I wonder whether a space should always be inserted or not. [13年07月08日 13:19:07] <pravins> it will confuse user, since he is typing some other keys and user getting commit effect [13年07月08日 13:19:22] <mfabian> Yes, it would be quite surprising probably. [13年07月08日 13:19:40] <pravins> if its truly punct. characters user will naturally press space for commit [13年07月08日 13:19:58] <mfabian> Because I also “naturally” press space after punctuation, I somehow don’t like the automatic insertion of spaces after typing “something.” [13年07月08日 13:21:26] <mfabian> When no transliteration is used, this inserts “something. “ at the moment and because I “naturally” type a space, I get “something. ” [13年07月08日 13:22:05] <pravins> ohh [13年07月08日 13:22:19] <pravins> so "." commits the string and add space as well. [13年07月08日 13:23:16] <mfabian> Swiftkey on Android automatically adds a space if “something.” is typed. [13年07月08日 13:23:20] <mfabian> Yes, I wonder what we should do there. [13年07月08日 13:23:30] *** ngoswami (~ngoswami.redhat.com) has quit: Quit: Leaving [13年07月08日 13:23:40] <mfabian> Should a space be added when punctuation triggers a commit (no transliteration) or should no space be added. [13年07月08日 13:23:56] <pravins> in regular writing we do press space after punctuation [13年07月08日 13:23:57] <mfabian> ? <pravins> difficult to say :( [13年07月08日 13:24:38] <pravins> ex. if users gets familiar with itb [13年07月08日 13:24:47] <pravins> and knows that it takes care of space after punct. [13年07月08日 13:25:01] <pravins> it can save his 1 keystroke [13年07月08日 13:25:09] <pravins> but yes that is only when he will get familiar [13年07月08日 13:25:18] <mfabian> But not always. [13年07月08日 13:25:20] <mfabian> For example when typing “col” and selecting the candidate “colour” with the number, the committed string is currently “colour ”. [13年07月08日 13:26:01] <pravins> for keeping users regular habit of typing. i will go with what you says. i.e. dont commit space for punct. [13年07月08日 13:27:02] <pravins> yeah and if users want to type colours, then he need to delete space and and "s" [13年07月08日 13:27:31] * pravins doing this regularly for some of marathi words [13年07月08日 13:27:47] <pravins> since getting 100% exact suggestion is rare considering available database [13年07月08日 13:28:07] <pravins> and knows that it takes care of space after punct.5 [13年07月08日 13:28:24] <pravins> ignore last line [13年07月08日 13:29:23] <mfabian> When the next character typed is “.”, *and* surrounding text works, then “colour .” is changed into “colour.”. But no extra space is added after the “.” [13年07月08日 13:30:30] <pravins> we need to take some review from users [13年07月08日 13:33:25]
With the above discussion it got clear that if punctuation mark is at the end of word, user will by habit press space. And if punctuation marks comes in between word it means there is some mapped combination available in transliteration scheme that is why user is not pressing the space button. So conclusion is not need to processing punct. for transliteration scheme. !! Mike i think we fixed this for non-trans IME's?
ibus-typing-booster-1.2.2-1.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/ibus-typing-booster-1.2.2-1.fc19
ibus-typing-booster-1.2.2-1.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/ibus-typing-booster-1.2.2-1.fc17
ibus-typing-booster-1.2.2-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/ibus-typing-booster-1.2.2-1.fc18
Package ibus-typing-booster-1.2.2-1.fc17: * should fix your issue, * was pushed to the Fedora 17 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.2-1.fc17' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-13051/ibus-typing-booster-1.2.2-1.fc17 then log in and leave karma (feedback).
ibus-typing-booster-1.2.2-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-typing-booster-1.2.2-1.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.