The only use of mDeleteCount is to implement delete
acceleration. It's reset at each non-delete code point, and
is guarded by a timer.
Plus, ultimately we want to remove this completely :
acceleration should be implemented by actually deleting
stuff faster, not by deleting several code points at a time.
Change-Id: Ia3144860b3aa2499034f2a2a7c81f32087af9598
We don't support LOG_FULL_TEXTVIEW_CONTENTS any more, nor do
we have any plans to support it again in the future.
This also is a prelude to removing mIsExpectingUpdateSelection.
Bug: 11226045
Change-Id: Ib68c6daf52993b87225a7ea9e71a414caaecfdb7
cherripick of I9c6a948331726a821bd3ccec9c1d02dec2c4703a
(forward cherrypicking this because the automerger is stuck now.)
This bug was leading to corrupted rendering of surrogate pairs in the following
scenario.
1. Type some emojis
2. Move the cursor at the beginning of the text field
3. Hit backspace even though there's nothing to delete
4. Move the cursor after some emoji
5. Hit backspace
The root cause of this issue was the out-of-sync mExpectingUpdateSelection if
handleBackspace() gets called when the cursor reaches at the beginning of the
TextView. In such case, mExpectingUpdateSelection shouldn't be set true because
there's nothing to delete, so there will be no onUpdateSelection() calls associated
with it. Due to this bug, the cache in RichInputConnection could get stale at step 4
described above. Then the following handleBackspace() that should delete a surrogate
pair was not working correctly because of the stale cache.
bug: 11181913
Change-Id: I1cbf444d8d105416e7de75c16d80b3797f470495
The available space was not computed correctly. This makes the
decision to ellipsize/expand the middle suggestion correct.
Also, the scale was not applied correctly in some cases.
Finally, for some reason ellipsize does not work as we expect.
I'm not sure how to get it to work like we want it to, but
this works around the problem in a simple manner.
Bug: 11158757
Change-Id: I083e7ac56e157f100923733e67b92a6368a526c9
In new format, each bigram entry has flags (1 byte), a terminal id (3 byte),
a time-stamp (4 byte), a counter (1 byte) and a level (1 byte).
Bug: 10920255
Bug: 10920165
Change-Id: I0f7fc125a6178e6d25a07e8462afc41a7f57e3e1
This reverts commit 56402cf10a.
I'll submit this on 10/16 after the final cut for Bayo.
Change-Id: I0fe4ab64fd8dfa1e63e29adf00388743fca6a1ed
bug: 11144401
This reverts commit 220ce8f269.
Sorry, but we are now in the week before the final cut for the next launch. We shouldn't be taking new features like this at this point. Let me revert this change for now. I'll re-revert this after the cut next week.
Change-Id: Ia8b00680c992ec526e6a858945f2380cbcdfdd55
There used to be two "Swiss" keyboard layouts, labelled fr_CH and de_QY,
available in LatinIME. They were, however, not actually Swiss layouts
but instead work-arounds to be able to get French or German with qwertz
or qwerty (instead of azerty and qwertz) layouts, respectively. These
were thus removed by commit f6972561fc
replacing them with the generic fr-qwertz and de-qwerty layouts instead.
Here, now, is a proper Swiss keyboard layout, following Swiss standards
for people accustomed to typing on Swiss keyboards, with the expected
tailorings for French and German.
Change-Id: I9feed752053ecc694c84db713284f69bc1daf155
This is not useful because we're going to call setSelection again
with different values on the connection right away.
Also a preliminary change for
Bug: 10792236
Change-Id: I46c6ef1fbb3624086099bf81afddb0ef5ae85661
