Operating system
macOS
Orca version
v1.4.192
Details
Short summary
A cursor chord pressed over a composing Hangul syllable is sent twice. One Option+← moves the cursor two words instead of one. The syllable itself no longer relocates — that part of #12871 is fixed — but the chord's byte still goes out twice.
What happened?
Typing 가나 다라 마바사 with the macOS Korean 2-Set IME, holding 사 in the preedit, then pressing Option+← once: the cursor lands before 다라. One backward-word from the end of that line should land at the start of 마바사.
Cmd+← looks correct only because \x01 is idempotent — two of them land where one does.
How can we reproduce it?
- macOS, Korean 2-Set input source.
- In the integrated terminal, type
가나 다라 마바사 and do not commit the final 사.
- Press
Option+← once.
- The cursor moves two words back, to before
다라.
Why this is separate from #12871
#12871 was about the composing character being carried to the cursor destination and committed there. #14730 and #15017 hold and dispose the chord until the syllable commits, which fixed that: the syllable stays put. The count was never part of that issue and is not addressed by either PR — #15017 discards a timed-out chord rather than sending it, which does not deduplicate.
The mechanism is described in the first commit of #14742 (c070b84fa) by its author:
#14730 fixed the order: a chord resolved mid-composition now waits for the syllable to commit instead of overtaking it. It still resolves that chord on the composing keydown, and on Korean 2-Set the platform then replays the same chord unmarked after keyup, so both copies fire. Cmd+Left hides it by being idempotent; Option+Left sends \x1bb twice and jumps two words.
That PR was closed as superseded because #12871 is fixed. The double send has never had an issue of its own, which is why it is filed here.
Anything else that might help
deferredChordSender is present in v1.4.192 and on main, so the ordering fix is shipped. imeChordSnapshot — the release-keyed decision that would send the chord once — is absent from both, so nothing currently keys a composing chord on its release.
Japanese and Chinese IMEs differ here: they swallow the chord inside a live preedit rather than committing and replaying it, so a chord pressed there produces no byte at all until the composition ends. A fix has to distinguish the two at the key's release, which is what #14742 was building.
Operating system
macOS
Orca version
v1.4.192
Details
Short summary
A cursor chord pressed over a composing Hangul syllable is sent twice. One
Option+←moves the cursor two words instead of one. The syllable itself no longer relocates — that part of #12871 is fixed — but the chord's byte still goes out twice.What happened?
Typing
가나 다라 마바사with the macOS Korean 2-Set IME, holding사in the preedit, then pressingOption+←once: the cursor lands before다라. One backward-word from the end of that line should land at the start of마바사.Cmd+←looks correct only because\x01is idempotent — two of them land where one does.How can we reproduce it?
가나 다라 마바사and do not commit the final사.Option+←once.다라.Why this is separate from #12871
#12871 was about the composing character being carried to the cursor destination and committed there. #14730 and #15017 hold and dispose the chord until the syllable commits, which fixed that: the syllable stays put. The count was never part of that issue and is not addressed by either PR — #15017 discards a timed-out chord rather than sending it, which does not deduplicate.
The mechanism is described in the first commit of #14742 (
c070b84fa) by its author:That PR was closed as superseded because #12871 is fixed. The double send has never had an issue of its own, which is why it is filed here.
Anything else that might help
deferredChordSenderis present in v1.4.192 and onmain, so the ordering fix is shipped.imeChordSnapshot— the release-keyed decision that would send the chord once — is absent from both, so nothing currently keys a composing chord on its release.Japanese and Chinese IMEs differ here: they swallow the chord inside a live preedit rather than committing and replaying it, so a chord pressed there produces no byte at all until the composition ends. A fix has to distinguish the two at the key's release, which is what #14742 was building.