Skip to content

fix(macos): resolve paste/copy key codes for non-QWERTY layouts - #1822

Draft
io41 wants to merge 1 commit into
OpenWhispr:mainfrom
io41:fix/paste-non-qwerty-layouts
Draft

fix(macos): resolve paste/copy key codes for non-QWERTY layouts#1822
io41 wants to merge 1 commit into
OpenWhispr:mainfrom
io41:fix/paste-non-qwerty-layouts

Conversation

@io41

@io41 io41 commented Aug 25, 2026

Copy link
Copy Markdown

Problem

resources/macos-fast-paste.swift hardcodes the virtual key codes it posts: 0x09 for v and 0x08 for c. Those values are positions on a QWERTY layout, not characters. On Dvorak, Colemak, and similar layouts they land on different keys, so the synthesized ⌘V and ⌘C are not paste and copy.

Both paths are affected:

  • Auto-paste after dictation silently does nothing (or triggers whatever shortcut happens to live on that key).
  • --copy selection capture returns COPY_OK because the frontmost app resolved fine, but the clipboard was never populated — so the caller believes it captured a selection that it did not.

On a Dvorak layout, v is at key code 47 and c is at key code 34.

Fix

Look the key code up in the active keyboard layout with UCKeyTranslate instead of hardcoding it. keyCodeForCharacter(_:) walks key codes 0–127 through the current TISCopyCurrentKeyboardLayoutInputSource() layout and returns the one that produces the requested character.

If the lookup fails, it falls back to the QWERTY key code for the same mode0x08 in copy mode, 0x09 in paste mode. Keeping the fallback mode-aligned matters: falling back to a single constant would let a failed lookup in copy mode post ⌘V, overwriting the user's selection instead of copying it.

No behaviour change on QWERTY: the lookup returns the same values that were previously hardcoded.

Notes

  • Adds import Carbon for the Text Input Services and UCKeyTranslate APIs.
  • The --copy stdout contract (COPY_OK <pid> <name>), exit codes, and the ordering of the AXIsProcessTrusted() check and frontmost-app resolution are all unchanged.
  • Self-contained in the one file — no build-script or caller changes.

Testing

  • swiftc compiles clean.
  • On a non-QWERTY (Dvorak) layout, the lookup resolves v to key code 47 and c to key code 34, confirming the resolution path runs rather than silently falling back.
  • Verified end to end in a local packaged build on macOS 15 (arm64): dictation auto-paste inserts text, and selection capture populates the clipboard so in-place selection edits work.

macos-fast-paste.swift hardcoded 0x09 for 'v' and 0x08 for 'c', which are
only correct on QWERTY. On Dvorak, Colemak and similar layouts the posted
Cmd+V / Cmd+C landed on the wrong key, so paste and selection capture
silently did the wrong thing.

Look the key code up in the current keyboard layout via UCKeyTranslate
instead. Falls back to the QWERTY key code for the same mode if the lookup
fails, so a failed lookup never turns a copy into a paste.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant