https://bugzilla.redhat.com/show_bug.cgi?id=981179
--- Comment #2 from Mike FABIAN <mfabian(a)redhat.com> ---
IRC log discussing this bug:
<mfabian> pravins: What do you think about this:
https://git.fedorahosted.org/cgit/ibus-typing-booster.git/commit/?h=miket...
[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(a)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]
--
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug
https://bugzilla.redhat.com/token.cgi?t=tjRJNQ54wG&a=cc_unsubscribe