Per-app "Exact Typing": turn off autocorrect / auto-replace / auto-caps in chosen apps (terminals, SSH clients, coding-agent apps)

[djbclark]

Summary

Please add a per-app opt-out for Pastiera's text-rewriting features (auto-correct, auto-replace on space/enter, auto-capitalize, double-space-to-period), keyed by the target app's package name (EditorInfo.packageName).

PhysiBoard, a GPLv3 fork of Pastiera for the Titan 2 Elite, ships this as Exact Typing. Its announcement describes it as turning off autocorrect/auto-caps "for specific apps (terminals, editors) where they get in the way — one toggle per app": https://www.reddit.com/r/unihertz/comments/1vu7ugm/physiboard_for_t2e_holdfn_voice_typing_alwayson/

It would be good to have this upstream, so people who want literal input don't have to leave official nightlies (and the Plektra successor).

Use case

I use a Titan 2 Elite as a coding and CLI device: SSH/mosh terminals, and mobile front-ends for terminal coding agents (Claude Code, Codex, etc. running in tmux on a remote box). In those apps, every token has to stay exactly as typed:

1. Shell: ls, cd, git, rm -rf, --amend
2. Paths and identifiers: usr, tmp, pkg, package names, snake_case
3. Agent/TUI replies: y, n, short option numbers, continue (auto-caps on the first letter breaks these)
4. Code: def, fn, impl, short variable names

Turning auto-correct off globally fixes this but makes chat and email worse. Toggling it manually each time you switch apps is error-prone, and there's no external API (e.g. for Tasker) to flip Pastiera prefs per app.

What Pastiera does today (checked against main @ 474fa10, 2026-09-08)

1. Correction settings are global or per-language, not per-app. SettingsManager.kt has auto_correct_enabled, auto_correct_enabled_languages, suggestions_enabled, auto_replace_on_space_enter, auto_capitalize_first_letter, auto_capitalize_after_period, double_space_to_period, but nothing keyed by package.
2. Automatic suppression is based only on the field's input-type variation. core/InputContextState.fromEditorInfo() sets restrictedReason only for TYPE_TEXT_VARIATION_URI, the *_PASSWORD variations, EMAIL_ADDRESS and FILTER. All of shouldDisableSuggestions/AutoCorrect/AutoCapitalize/DoubleSpaceToPeriod come from that one value.
3. The app's own TYPE_TEXT_FLAG_NO_SUGGESTIONS is not used for gating. It's logged in the debug dump but doesn't turn off auto-correct. (Separately, onStartInput ORs NO_SUGGESTIONS into info.inputType itself, after updateInputContextState(info), so the original flag is still readable at that point.)
4. Per-app Enter behavior already exists and is the right model. resolveAppEnterBehavior() looks up info.packageName in SettingsManager.getAppEnterBehaviorOverrides() (a JSON list of AppEnterBehaviorOverride(packageName, …)), with a built-in messenger default set (MESSENGER_ENTER_BEHAVIOR_PACKAGES). There's also an AppPickerDialog composable. Exact Typing could reuse the same storage pattern and picker.

Where this hurts, and where it doesn't

• Termux is mostly fine already. TerminalView.onCreateInputConnection reports TYPE_NULL, or TYPE_TEXT_VARIATION_VISIBLE_PASSWORD | TYPE_TEXT_FLAG_NO_SUGGESTIONS when char-based input is enforced. Pastiera treats the second as a password field, so smart features turn off. (The separate "Termux isn't detected as an input field" problem is [Request] Always enabled option #35.)
• The real gap is apps whose input box looks like a normal text field: native compose/input bars in SSH clients and agent companion apps, and WebView/xterm.js terminals whose hidden textarea shows up as plain multi-line text. For these, only a user-chosen per-app switch (or honoring NO_SUGGESTIONS, below) helps.
• Caveat for PWAs: a web app like Collie (https://github.com/AltanS/collie) running in Chrome reports Chrome's package name, so per-app keying can't target it without affecting the whole browser. Honoring the field's own flags is the only thing that helps there.

Proposal

A. Per-app Exact Typing (main request)

Add Settings → Auto-correction → Exact Typing (per app), a list of packages with an add-app picker. When the target app is on the list:

1. No auto-correct and no auto-replace on space/enter.
2. No auto-capitalization (first letter or after period).
3. No double-space-to-period, and no spaced-hyphen-to-en-dash.
4. Suggestions may still show in the bar, but they're only inserted if the user picks one.
5. SYM, modifiers, Nav Mode, layouts, and the per-app Enter behavior stay the same.

Possible implementation: add something like RestrictedReason.APP_EXACT_TYPING (or an exactTyping flag) in InputContextState, set when info.packageName is on the list, so every existing shouldDisable* path picks it up for free. Store the list like app_enter_behavior_overrides and add it to backup/BackupContract.kt so it survives backup/restore (see #294).

I wouldn't ship hard-coded defaults beyond maybe a couple of obvious terminal packages; a user-editable list is enough.

B. Honor the app's own "no suggestions" signal (cheap complement)

Optionally (maybe behind a toggle, default on), treat an app-supplied TYPE_TEXT_FLAG_NO_SUGGESTIONS (read before Pastiera adds it in onStartInput) as "don't rewrite words" (no auto-correct/auto-replace), while leaving auto-caps to the field's CAP_* flags. Well-behaved terminal and code-editor apps get the right behavior with no setup, and it may also help the PWA case.

Related issues (none cover this)

1. [Request] Always enabled option #35: "Always enabled" option for Termux / Nix-on-Droid (field detection, not correction)
2. Keyboard still correcting things with all smart stuff off #266 (closed): "Keyboard still correcting things with all smart stuff off"
3. First letter after @ capitalized #276: "First letter after @ capitalized" even with smart features off
4. New feature suggestion: Language-specific Autocapitalization Setting #302: language-specific auto-capitalization setting (an example of scoping these settings more finely than global)

I'm happy to test a nightly on a Titan 2 Elite with Termux, an SSH/mosh client, and an agent companion app.

[djbclark]

Also LMK how you feel about AI code; I can try to implement this via AI if that is okay with this project. I can use Fable 5.1 and code review with multiple other agents including GPT-6 Astra.

[pzauner]

Go ahead; you seem to know how to build software.