macOS: Input Improvements

[mitchellh]

Sorry for the vague title. This PR addresses multiple issues:

1. Fixes macOS: super+period doesn't reach Surface keyCallback #4540
2. GTK: performable keys that map to menu accelerators always perform their action #4522 is fixed for macOS only
3. Fixes macOS: Keybindings should take precedence over standard menu shortcuts #4590
4. Fixes an untracked issue where command+key events will not send release events for Kitty keyboard protocol, something I only noticed while working on this.

There are multiple components to this PR.

Part 1: App/Surface.keyEventIsBinding

This new API (also available in libghostty as ghostty_surface_key_is_binding) returns a boolean true if the given key event would match a binding trigger if it was the next key event sent. It does not process the binding now.

This can be used by event handlers that intercept key events to determine if it should send the event to Ghostty. This helps resolve #4590 for us but is also part of all resolved issues.

Part 2: macOS performKeyEquivalent changes

macOS calls performKeyEquivalent for any key combination that may trigger a key equivalent. if this returns true then it is handled and macOS ceases processing the event.

We were already using this to intercept things like Ctrl+/ which triggers a context menu in macOS Sequoia. But we now expand this to intercept all events to check for bindings. This lets us fix #4590.

Additionally, it's been changed to special case cmd+period. I'm sure more need to be added.

Part 3: NSEvent local listener for command keyUp events

macOS simply doesn't send keyUp events for key events with command pressed. The only way to work around this is to register an NSEvent local listener. We now do this. This fixes the untracked issue noted above.

[AlexJuca]

@mitchellh macOS prioritizes global or application-level shortcuts (e.g., ⌘C for copy, ⌘V for paste). The keyDown event is handled, but the keyUp is ignored by the O.S., so NSEvent is the only other viable solution.

Your solution is pretty good.

[mitchellh]

Your solution is pretty good.

Awesome. Thanks!

[liby]

Hi! I noticed that in this PR, both vim and nvim folders are renamed to "vim" in the Xcode project references. While the final build output still correctly maintains the distinction between vim and nvim folders, I'm curious about the motivation behind this change in the project structure.

I see that both folders contain identical content at the moment, but having two identically named "vim" folders in the Resources group (as shown in the Xcode project navigator) might be a bit confusing for future maintenance. Could you share the reasoning behind this unification of names in the Xcode project?

[mitchellh]

Hm. I didn’t do this on purpose at all. So this was somehow a mistake. I’ll take a look!