If not composing a word, then consideredWord is always the empty
string.
Hence, it's never whitelisted, but it's also always "NotAWord",
so isWhitelistedOrNotAWord returns always true, so
allowsToBeAutoCorrected is always true. Which means that
isPrediction implies allowsToBeAutoCorrected == true.
Thus, !isPrediction && !allowsToBeAutoCorrected is strictly
equivalent to !allowsToBeAutocorrected.
Change-Id: I4ad7a7c3447851c539646d97cf55ff065e6ee115
If we are not composing a word, that isFirstCharCapitalized
and isAllUpperCase are guaranteed to return false.
Change-Id: Ic4a0be9574acf4653c729a9594f963f5bcf0c757
The fact that prediction does not accept a null argument is an
implementation detail, it should not be visible to Java code.
Change-Id: I3a156b323b6db9353de898d33f3f7c81751cecb1
Use the word the same way for suggestion and prediction. It makes
little logical sense that the trailing single quotes be removed
for suggestion lookup but not for prediction lookup.
Change-Id: I0de4b5f7c5b4c1b4ba1817ff9653d7c03967146d
Avoid special casing the whitelist dictionary by having it implement
the interface it pretends it implements
Change-Id: I8b873cb0f3fe13cefd32c8cb756a25c8ae16a2b4
The user history dictionary should be the one knowing it does not suggest words
beyond 2 characters, not Suggest.
Change-Id: Ie85ec6116eb495e0c7f51108e4620c5ae536f4bf
It's simpler to check the safety net directly inside the
function that checks for auto-correction threshold.
This introduces one very slight change in behavior. The value
checked by the safety net is not any more the "typed word" but the
"considered word", the difference being any possibly appended
single quotes.
E.g. the user types "this'''" : the typed word is "this'''" but
the considered word is "this".
This change in behavior can be considered a bugfix.
Change-Id: Ia7ab4bc933183dfbd41bb00328e4c0b5ab76bc63
If allowsAutoCorrected is false, there is no point in making
hasAutoCorrection true, since in the only place where we use
it again, it's &&'ed with allowsAutoCorrected !
Well that was extremely obscure, good thing refactoring allowed
to realize this was useless >.>
Change-Id: I34936d445f1ced17c7bd04a9524bf608f9e8b9c8
The test against hasMainDictionary is a test to know if we should
auto-correct or not. Its result should be recorded in
hasAutoCorrection, not in allowsToBeAutoCorrected.
Actually, this value being inserted in allowsToBeAutoCorrected was
causing a bug that nobody noticed: when typing in a language with
no dictionary, the word in the middle of the suggestion strip would
always be bold, as if it was going to auto-correct to itself !
This change fixes this bug.
Change-Id: Ia1f08efd7089b9c5cbede910c5b0951d83e698d2
isWhitelistedOrNotAWord takes an 'ignoreCase' argument. By looking
at the contents of the wordcomposer here, there is only one case
where its output will be different : when the word is typed with a
capital, but the lower case version exists in the dictionary.
E.g. the user typed "This".
In this case, isWhitelistedOrNotAWord in line 235 will return false
instead of true, so the test will score a true instead of a false,
so hasAutoCorrection may be true instead of false in this specific
case and that's the only case where it's different.
But in this case, allowsToBeAutoCorrected is certain to be false,
which means the result will not have changed if hasAutoCorrection
was true in the first place. So in the end this change is sure not
to change the behavior.
Change-Id: Ic41cf959c20c19165f84d9b8ff006731fa595d84
allowsToBeAutoCorrected always returns false if the word is empty.
This is because the whitelist never contains an empty string,
and isValidWord returns false if the word is empty.
Change-Id: I34ecc2a1563aea6db5b2f12796f251f6598576a2
This special casing is useless. If the word is the same as what
user typed, the scoring algorithm already ensures that it comes
out at the top. Actually, as is written in a comment here, code
executed later is actively relying on this suggestion having
the top score ! There is no need to test it for equalness and
inserting it at the top then.
Change-Id: I263a6de59b77ec72a2dcbb933361b8e16fca0681
This is only used as temporary storage to be then added to
the other variable, relying on the fact that it is hopefully
sorted. It's better to just add it right away to the final
storage.
Change-Id: I5da702ac9dc579593ab21feb2021a01e5dfdf4dc
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
This is never changed, and probably doesn't need to be.
It's public because it's going to be used elsewhere in a future
change
Change-Id: Iec8d65859c470de5e1fb0b05533356fbc3b8e91b
This will help for debug as well as serve as groundwork for
Bug: 6252660
Bug: 6166228
Bug: 2704000
Bug: 6225530
Change-Id: I74d0a7b943fb22c514ad79dc064d69ddf336d3ef
