feat: highlight autocomplete suggestion when it matches typed word

[Mounil2005]

Contributor checklist

• This pull request is on a separate branch and not the main branch
• I have tested my code with the ./gradlew lintKotlin detekt test command as directed in the testing section of the contributing guide

---

Description

Once the user has typed enough of a word that the first autocomplete suggestion exactly matches it (e.g. typing "Buch" when "Buch" is itself a suggestion), that suggestion chip is now highlighted (bold, accent blue text) to indicate that tapping it is effectively a no-op, matching the existing Scribe-iOS behavior described in the issue.

• app/src/keyboards/java/be/scri/services/GeneralKeyboardIME.kt: setSuggestionButton and setAutocompleteButton now accept the word currently being typed. If a suggestion's text exactly matches it (case-insensitive), the button is rendered bold using R.color.theme_scribe_blue instead of the default text color. Tap behavior is unchanged — it still deletes the current word and re-inserts the suggestion (a no-op when they're equal).
• app/src/keyboards/java/be/scri/helpers/AutocompletionHandler.kt: passes the current word through to updateAutocompleteSuggestions so the exact-match check has what it needs.

Tested by running ./gradlew lintKotlin detekt test (all green) and ./gradlew :app:compileKeyboardsDebugKotlin.

Related issue

• Closes Highlight autocompletion if it is the word the user is typing #410

[github-actions]

Thank you for the pull request! 💙🩵

The Scribe-Android team will do our best to address your contribution as soon as we can. The following are some important points:

• Those interested in developing their skills and expanding their role in the community should read the mentorship and growth section of the contribution guide
• If you're not already a member of our public Matrix community, please consider joining!
  • We'd suggest that you use the Element client as well as Element X for a mobile app
  • Join the General and Android rooms once you're in
• Also consider attending our bi-weekly Saturday developer syncs!
  • Details are shared in the General room on Matrix each Wednesday before the sync
  • It would be great to meet you 😊

Note

Scribe uses Conventional Comments in reviews to make sure that communication is as clear as possible.

[github-actions]

Maintainer Checklist

The following is a checklist for maintainers to make sure this process goes as well as possible. Feel free to address the points below yourself in further commits if you realize that actions are needed :)

• Tests for changes have been written and the unit test, linting and formatting workflows within the PR checks do not indicate new errors in the files changed

  • Tests may need to be reran as they're at times not deterministic

• The CHANGELOG has been updated with a description of the changes for the upcoming release and the corresponding issue (if necessary)

[andrewtavis]

praise: Thanks so much for the PR, @Mounil2005! We'll try to get to the review in the coming days :)

note: For UI changes like this, would you be able to send along a screenshot that includes the change? If it's something like this, then maybe there's no need for a screenshot of the state before the change, but before and after screenshots are also quite helpful as a reviewer in knowing that the work has been completed before going into the code. Just suggesting! 😊

[Mounil2005]

While testing this locally with Scribe German, I found that the native dictionary engine
(NativeSuggestionEngine.getAutocompletions) explicitly filters out the exact typed word from its completions, it's designed to only suggest extensions of what you've typed (e.g. typing Buch only returned buchen, Buchhändler, Bücherei, never Buch itself). That meant the highlight-on-exact-match feature could never actually trigger through the primary suggestion path, since the exact match never reached the UI.

Rather than removing that filter (which would make "exact match shows first" dependent on the native dictionary's internal ranking, not guaranteed), I used the dictionary's existing isValidWord/isInDictionary check separately: if what the user has typed is itself a real word, it's now always shown as the first suggestion, with the remaining slots filled by real completions, deterministically matching the behavior in the issue's screenshot rather than hoping the ranking happens to put it first.

Tested on-device (emulator) with Scribe German across several words (Buch, Haus, Auto, Zeit, and various prefixes)...the exact match consistently shows first and highlighted (bold, accent blue) whenever it's a valid word, while non-exact prefixes correctly show only extensions with no highlight.

[andrewtavis]

note @Mounil2005, @@Priyanshikaa1111: I'm thinking that it might be for the best if we move the word that the user is typing to the first autocompletion sole and just change the background to be highlighted rather than the text being blue. This at least is a common behavior in iOS keyboards. Specifically what this allows us to do is also have a space functionality where when the word is highlighted, pressing space will insert it.

The way that this works in Scribe-iOS is the following:

• Say that we have an English words registry with the words "house", "houses", "drum" and "dolphin"
• The user types "hous" and "house" is the first autocomplete, but not highlighted
• The user types "e" and "house" is the first autocomplete (not really an autocomplete anymore) and is highlighted
• There's really no difference to pressing space here
• If the user types "do", then "dolphin" is the only word that can follow
• The word "dolphin" is now the first autocomplete
• If the user presses space, then we'd insert "dolphin" in this case as it was highlighted
• We'd also make "do" the first autocomplete for if the user actually did want to type the word that they'd typed and just wanted a space instead of an autocomplete

The example above of "do" -> "dolphin" would never happen, so this example is mainly for larger words where once a user types enough of it, then it's obvious that they're typing it and we might as well insert the rest on space for them. The indication that this is going to happen is the autosuggestion being highlighted :)

How does this sound to the both of you?

CC @angrezichatterbox for this discussion 👋

[Mounil2005]

note @Mounil2005, @@Priyanshikaa1111: I'm thinking that it might be for the best if we move the word that the user is typing to the first autocompletion sole and just change the background to be highlighted rather than the text being blue. This at least is a common behavior in iOS keyboards. Specifically what this allows us to do is also have a space functionality where when the word is highlighted, pressing space will insert it.

The way that this works in Scribe-iOS is the following:

• Say that we have an English words registry with the words "house", "houses", "drum" and "dolphin"
• The user types "hous" and "house" is the first autocomplete, but not highlighted
• The user types "e" and "house" is the first autocomplete (not really an autocomplete anymore) and is highlighted
• There's really no difference to pressing space here
• If the user types "do", then "dolphin" is the only word that can follow
• The word "dolphin" is now the first autocomplete
• If the user presses space, then we'd insert "dolphin" in this case as it was highlighted
• We'd also make "do" the first autocomplete for if the user actually did want to type the word that they'd typed and just wanted a space instead of an autocomplete

The example above of "do" -> "dolphin" would never happen, so this example is mainly for larger words where once a user types enough of it, then it's obvious that they're typing it and we might as well insert the rest on space for them. The indication that this is going to happen is the autosuggestion being highlighted :)

How does this sound to the both of you?

CC @angrezichatterbox for this discussion 👋

That sounds great, thanks for the detailed writeup! I've implemented all three pieces:

1. Background highlight instead of blue text: the highlighted suggestion now shows a rounded, tinted background box behind the text, matching the Scribe-iOS reference image, instead of the bold blue text from the first version of this PR.
2. Highlighted suggestion always in the first slot + space inserts it: pressing space now checks if a suggestion is highlighted and, if so, inserts it (with a trailing space) in place of the word being typed, instead of just committing a literal space.
3. Broader trigger for "obvious" completions: highlighting no longer only fires when the user has typed a word out in full. If only one dictionary word can possibly complete what's been typed so far (the do → dolphin case), that word is now promoted to the first slot and highlighted, while what the user actually typed (do) is still offered as another suggestion in case they wanted to keep typing their own word.

I'll be attaching images shortly to show this working end-to-end.

[Mounil2005]

While testing the highlighting behavior across different word lengths, I found something worth flagging separately: the native suggestion engine's completions become increasingly unrelated to the actual typed prefix as the word gets longer, across all languages (not German-specific).

Example: typing dolp in English returns mol, DSL, Sol, AOL....none of which start with "dolp" and Dolphin never shows up as a candidate at all, despite being the obvious match. Shorter prefixes (dol) still look reasonable; the divergence grows with length.

Root cause: ComposedData.createForWord() generates random touch coordinates (Random.nextBits(2)) for every typed character instead of real ones, and this gets paired with a completely empty ProximityInfo (keyCount=0, no real key geometry). The underlying native engine is a spatial/gesture-typing correction algorithm, it ranks candidates partly by touch-point proximity, so feeding it random noise corrupts the ranking, with more accumulated noise (longer words) causing more drift from the actual prefix.

This predates this PR....it just wasn't visible before since the raw completions were only ever used for background suggestion chips. Step 3 of this PR (highlighting the single unambiguous candidate) depends on completion precision, which is what surfaced it.

Fixing it properly likely needs either real per-key coordinates for each keyboard layout or a suggest-mode that bypasses spatial correction for pure prefix lookup,both feel out of scope for #410, so flagging it here for a separate issue rather than trying to fix it in this PR. Happy to file it as its own issue if that's preferred.

[Mounil2005]

As a mitigation for the above (while the deeper fix is still open), I added a startsWith(prefix, ignoreCase = true) filter to NativeSuggestionEngine.getAutocompletions(), so any suggestion shown or highlighted is now guaranteed to actually extend what the user typed. This specifically matters for the "single unambiguous candidate" highlight, which would otherwise have trusted and potentially auto-inserted (via space) an off-prefix candidate.

Verified on-device: dolphi now correctly returns dolphin's, dolphin, dolphins instead of the earlier junk.

[Mounil2005]

some images after the final implementation.

[andrewtavis]

Hey @Mounil2005 and @Priyanshikaa1111 👋 Looks like we're also doing the work for #407 here :) A few points:

• I would have the whole highlight have rounded corners and have a bit more height while also having the gender annotation line having a bit less width that the highlight
  • This is how we're doing it in iOS and it works quite well
  • See iOS screenshot below from the issues

• Looks like we're assigning annotations for all words and that red (feminine) is the default?
  • Many of these words shouldn't have an annotation, and many of them are not feminine words
  • The annotations should be based only on the data in the nouns table
  • We're still in the process of finalizing the data process, so there might be some missing data now
  • Do your best with the data that's there and find a language that does have nouns and genders for testing, if German doesn't have them right now :)

CC @angrezichatterbox for the conversation here 😊

[angrezichatterbox]

@andrewtavis We wouldn't have a lot of suggestions right that follow this pattern as we are using autosuggestions in the android keyboard.

[angrezichatterbox]

So for every word we type we would be checking the autosuggestion data and doing a query to see the word gender right. We would have to make sure that the keyboard doesn't have to do a lot of db operations as well.

[angrezichatterbox]

This predates this PR....it just wasn't visible before since the raw completions were only ever used for background suggestion chips. Step 3 of this PR (highlighting the single unambiguous candidate) depends on completion precision, which is what surfaced it.

Fixing it properly likely needs either real per-key coordinates for each keyboard layout or a suggest-mode that bypasses spatial correction for pure prefix lookup,both feel out of scope for #410, so flagging it here for a separate issue rather than trying to fix it in this PR. Happy to file it as its own issue if that's preferred.

I think there is already a pure prefix based check in the codebase. We would have to make slight changes to the exising autosuggestions to be more deterministic.

[andrewtavis]

I think there is already a pure prefix based check in the codebase. We would have to make slight changes to the exising autosuggestions to be more deterministic.

Yes, this is true. We should be using this instead of something new.

So for every word we type we would be checking the autosuggestion data and doing a query to see the word gender right. We would have to make sure that the keyboard doesn't have to do a lot of db operations as well.

Very true! This needs to be optimized.

@andrewtavis We wouldn't have a lot of suggestions right that follow this pattern as we are using autosuggestions in the android keyboard.

This highlight is specifically for autocompletions. Is it possible to have the autocompletions be a bit more alphabetical and then use the autosuggestions from the current implementation?