If the separator is not a space, then we will always call
setPunctuationSuggestions and reset the suggestion strip anyway.
If the separator is a space, then the cursor has a space on
the left, which means isCursorTouchingWord depends only on
whether it touches a word on the right. If we were displaying
the "add to dictionary hint", it means a suggestion was just
chosen, so it had to be displayed, and that requires a composing
word and no non-separator at the right of the cursor.
In the end, if we go through this postUpdateSuggestions call,
we are sure we will reset the suggestions later in this method,
either by calling postUpdateBigramPredictions, or
setPunctuationSuggestions.
Change-Id: I95d5f77a5d0ac6d1a6ced8d67d6ac8f650db4a32
Just after this, clear() will be called, removing the suggestion
strip from the screen. It will later be displayed again through
onStartInputView, which will update its content.
Change-Id: I15c23ad2adecab76b0791d7fc222d15b6533f3bd
The responsivity is better like this. This does not seem to
feel slow as the previous comment seemed to indicate.
Also remove a stale comment.
Change-Id: I4e7bf9fe28716e112db182e44b3fa88ee4526bb4
After reverting an auto-correct we always have a separator after
the previously inserted word, and the cursor is never touching
a word. Showing predictions is the right thing to do, while
calling postUpdateSuggestions will invariably yield an invariably
blank suggestion strip, which is not very helpful.
Likewise, after we pick a suggestion, we should be showing the
predictions unless showing the addToDictionary hint. There was
a bug here in the corner case that the word would be a candidate
for user dictionary, but the user dictionary provider is not
available: in this case we should be showing predictions, but
we were showing an unhelpful empty suggestion bar.
Change-Id: I287bb5eb4af762bd5a433e85e185fab6d203e91a
If suggestion and prediction messages both happen to be in
the queue, the latest one will win (update the suggestion strip
later than the other, overwriting any previous suggestions).
So when we enqueue either one, it is always safe to cancel
all messages of both types.
Change-Id: Iad9dd06d08c49f60cac16b88edcc9531a18ec02e
TypedWordValid and AllowsToBeAutoCorrected are almost the
same thing; the difference is whether the word is also a
whitelist entry or not. In this case, TypedWordValid was
the right one to test.
Change-Id: I695fe5b9f6bbe9d3ba314c646da3a25742c9f4ed
Stop storing an int in each of the different class types, and
just store a string in the top class.
Change-Id: I2af1832743e6fe78e5c1364f6d9cc21252bf5831
Output to the ResearchLogger is now queued and only flushed if the word
the user was working on is a dictionary word.
multi-project commit with Ic713ec00777fbdcf4a937b3c77b995257e100fc7
Bug: 6188932
Change-Id: I9de15227ff51be23083d9096f1c1b3d83802fff7
