mirror of
https://github.com/ghostty-org/ghostty.git
synced 2025-04-12 10:48:39 +03:00
67f47a6e22
Fixes #5522 This commit re-dispatches command inputs that are unhandled by our macOS app so they can be encoded to the pty and handled by the core libghostty key callback system. We've had a special case `cmd+period` handling in Ghostty for a very long time (since well into the private beta). `cmd+period` by default binds to "cancel" in macOS, so it doesn't encode to the pty. We don't handle "cancel" in any meaningful way in Ghostty, so we special-cased it to encode properly to the pty. However, as shown in #5522, if the user rebinds `cmd+period` at the system level to some other operation, then this is ignored and we encode it still. This isn't desirable, we just want to work around not caring about "cancel." The callback path that AppKit takes for key events is a bit convoluted. For command keys, it first calls `performKeyEquivalent`. If this returns false (we want to continue standard processing), then it calls EITHER `keyDown` or `doCommand(by:)`. It calls the latter if there is a standard system command that matches the key event. For `cmd+period` by default, this is "cancel." Unfortunately, from `doCommand` we can't say "oops, we don't want to handle this, please continue processing." Its too late. So, this commit stores the last command key event from `performKeyEquivalent` and if we reach `doCommand` for it without having called `keyDown`, we re-dispatch the event and send it to keyDown. I'm honestly pretty sus about this whole logic but it is scoped to only command-keys and I couldn't trigger any adverse behavior in my testing. It also definitely fixed #5522 as far as I could reproduce it before.