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.