Bug 981179 - RFE: punctuation marks should commit the preedit buffer
Summary: RFE: punctuation marks should commit the preedit buffer
Alias: None
Product: Fedora
Classification: Fedora
Component: ibus-typing-booster
Version: 19
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: anish
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2013-07-04 08:20 UTC by Pravin Satpute
Modified: 2015-04-12 23:12 UTC (History)
4 users (show)

Fixed In Version: ibus-typing-booster-1.2.2-1.fc18
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2013-07-28 01:11:29 UTC
Type: Bug

Attachments (Terms of Use)

Description Pravin Satpute 2013-07-04 08:20:34 UTC
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):

How reproducible:

Steps to Reproduce:
1. type word "english" using i-t-b
2. press "."
2. it keeps all things in preedit buffer 

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 :)

Comment 1 Pravin Satpute 2013-07-04 08:21:40 UTC
just wondering how it will affect on processing speed, one extra condition.

Comment 2 Mike FABIAN 2013-07-11 11:29:38 UTC
IRC log discussing this bug:

<mfabian> pravins: What do you think about this:
                                                          [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> But rather after passing it to libtranslit
<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> 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@dhcp193-68.pnq.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]

Comment 3 Pravin Satpute 2013-07-11 11:36:35 UTC
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?

Comment 4 Fedora Update System 2013-07-15 17:08:29 UTC
ibus-typing-booster-1.2.2-1.fc19 has been submitted as an update for Fedora 19.

Comment 5 Fedora Update System 2013-07-15 17:09:13 UTC
ibus-typing-booster-1.2.2-1.fc17 has been submitted as an update for Fedora 17.

Comment 6 Fedora Update System 2013-07-15 17:10:35 UTC
ibus-typing-booster-1.2.2-1.fc18 has been submitted as an update for Fedora 18.

Comment 7 Fedora Update System 2013-07-17 03:00:24 UTC
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:
then log in and leave karma (feedback).

Comment 8 Fedora Update System 2013-07-28 01:11:29 UTC
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.

Comment 9 Fedora Update System 2013-08-02 03:26:15 UTC
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.

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