Description

On macOS, some Japanese IMEs (built-in macOS Japanese, Google Japanese Input, etc.) commit a phrase mid-typing via a single interpretKeyEvents: pass that fires insertText: (the just-committed phrase) and then setMarkedText: (the next in-progress character). The trailing [self unmarkText] in keyDownImpl was unconditionally clobbering that freshly-set marked text in our state.

After that, the IME's internal state still held the queued character but WarpHostView's markedText was empty and warp_marked_text_cleared had been dispatched. On the next keystroke (typically Enter
to commit), wasComposing was therefore false, so warp_handle_view_event ran without the composing flag and the keybinding system handled Enter as a command submission. The IME's insertText: of the queued character arrived at the post-dispatch insert path with handled=YES and was silently dropped.

The fix tracks whether the IME modified marked text via setMarkedText: or unmarkText during the current interpretKeyEvents: pass, and skips the trailing unmarkText if the IME has already touched
marked text in that pass — the IME has either cleared it (so our call would have been a redundant ClearMarkedText) or replaced it with new in-progress text we must preserve.

This change is contained to the macOS Objective-C IME plumbing in host_view.m. The Linux/Windows IME path (winit Ime::Preedit / Ime::Commit in crates/warpui/src/windowing/winit/event_loop/mod.rs) is structurally different and not affected by this PR.

Linked Issue

Fixes #7261

Note: the issue body explicitly reports Operating system (OS): macOS (15.6（24G84）), so the os:linux label appears to have been applied in error during automated triage. This PR addresses the
macOS path only; please drop the os:linux label or relabel as os:mac during review.

• The linked issue is labeled ready-to-spec or ready-to-implement.
• Where appropriate, screenshots or a short video of the implementation are included below (especially for user-visible or UI changes).

Screenshots / Videos

Before Fix

After Fix

Testing

Manual verification on macOS 15.x with the macOS built-in Japanese IME (Hiragana / Romaji mode):

1. Reproduced the bug on master with the steps from [Bug] Pressing Enter after Japanese IME conversion unexpectedly submits the form in Warp.dev #7261 — typing 漢字の入力（変換）が、 and pressing Enter dropped the trailing 、 and submitted the buffer immediately.
2. Verified the fix on this branch with cargo run --bin warp-oss (with FeatureFlag::ImeMarkedText enabled locally so inline preedit could be observed). After the fix the queued 、 is preserved across
   the split-commit, the next Enter commits it via the IME, and a subsequent Enter submits the buffer as expected.
3. Sanity-checked dead-key composition (⌥e then a → á) on a US keyboard layout to confirm the dead-key suppression branch in keyDownImpl is unaffected.
4. Ran the presubmit checks locally:

• cargo fmt --check — pass
• cargo clippy --workspace --exclude warp_completer --all-targets --tests -- -D warnings — pass
• cargo clippy -p warp_completer --all-targets --tests -- -D warnings — pass
• ./script/run-clang-format.py -r --extensions 'c,h,cpp,m' ./crates/warpui/src/ ./app/src/ — pass
• cargo nextest run --no-fail-fast --workspace --exclude command-signatures-v2 — passes for the IME-relevant suites; the only failures observed locally
  (settings::init::tests::test_migration_does_not_rerun_when_marker_present and the SSH-IAP integration suite) reproduce identically on master and are unrelated to this change.
• cargo test --doc — pass

Agent Mode

• Warp Agent Mode - This PR was created via Warp's AI Agent Mode