keyboard: Preserve ascii_mode across keyboard switches

[thelastlin]

Pull request

Issue tracker

Fixes will automatically close the related issues

Fixes # N/A

Feature

Fix keyboard ascii_mode being unconditionally reset on layout, by making the per-keyboard setting fall back to the global theme default and preserving the current mode in lastAsciiMode before switching away.

Code of conduct

• CONTRIBUTING

Code style

• make sytle-lint
• Conventional Commits

Build pass

• make debug

Manually test

• Done

Code Review

1. No wildcards import
2. Manual build and test pass
3. GitHub Action CI pass
4. At least one contributor review and approve
5. Merged clean without conflicts
6. PR will be merged by rebase upstream base

Daily build

Login and download artifact at https://github.com/osfans/trime/actions

Additional Info

Hi all,

This RFC pull request fix keyboard ascii_mode being unconditionally reset on layout, by making the per-keyboard setting fall back to the global theme default and preserving the current mode in lastAsciiMode before switching away.

Thanks for your review.

[Copilot]

Pull request overview

This PR aims to stop ascii_mode from being unconditionally reset when switching keyboard layouts by preserving the last used ASCII mode per keyboard and making per-keyboard reset behavior fall back to the theme’s global default.

Changes:

• Persist the current ascii_mode into a per-keyboard lastAsciiMode when switching layouts.
• Make resetAsciiMode in keyboard presets optional (Boolean?) so it can fall back to the theme default.
• Update keyboard reset behavior to default to theme.generalStyle.resetASCIIMode instead of always true.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

File	Description
app/src/main/java/com/osfans/trime/ime/keyboard/KeyboardWindow.kt	Updates keyboard switching flow to preserve ascii_mode across layout switches.
app/src/main/java/com/osfans/trime/ime/keyboard/Keyboard.kt	Changes resetAsciiMode default to follow the theme-level setting.
app/src/main/java/com/osfans/trime/data/theme/model/TextKeyboard.kt	Makes resetAsciiMode nullable and adjusts YAML decoding to allow fallback behavior.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[ENOA-REIAH-UION]

Kind of awkward—this review was supposed to be posted yesterday, but something came up and it got stuck in my drafts. Even more surprising, @Bambooin went ahead and merged this pretty questionable PR.

[ENOA-REIAH-UION]

This change is fundamentally incorrect.

You should first read the wiki carefully. Although the parameter names are identical, reset_ascii_mode under the style node and under the preset_keyboards node differ in both semantics and scope. They cannot form a fallback relationship.

In other words, identical names do not imply the same configuration level, nor do they justify inheriting default values from each other.

If this is what you consider a bug, I would suggest reviewing the wiki in full before determining whether the current behavior is actually incorrect.

[thelastlin]

Thanks for reviewing this RFC PR.

This change is fundamentally incorrect.

You should first read the wiki carefully. Although the parameter names are identical, reset_ascii_mode under the style node and under the preset_keyboards node differ in both semantics and scope. They cannot form a fallback relationship.

In other words, identical names do not imply the same configuration level, nor do they justify inheriting default values from each other.

If this is what you consider a bug, I would suggest reviewing the wiki in full before determining whether the current behavior is actually incorrect.

Currently, reset_ascii_mode is not well documented in wiki 1 2. Check for
trime-schema.json and trime.yaml, the fallback is the natural reading.

Would you like share the full documentation, or design decisions for both style/reset_ascii_mode and preset_keyboards/<keyboard>/reset_ascii_mode?

[ENOA-REIAH-UION]

Suggested change

	currentKeyboard?.let {
	val mode = rime.run { statusCached }.isAsciiMode
	Timber.d("Leaving $currentKeyboardId with ascii_mode $mode, switching to $target")
	it.lastAsciiMode = mode
	}

This change seems unnecessary.

During the initial keyboard initialization, currentKeyboard should not be null. When switching keyboards, lastAsciiMode also appears to be updated in detachCurrentView.

Given this, this assignment does not seem to have any practical effect. Have you tested a case where this makes a difference, or is there something I might have missed?