The hints, once set with `glfwWindowHint()`, retain their values until changed again. This means, that the `GLFW_DECORATED` hint only needs to be set once, even on non-macOS.
Most macOS Apps have a Help menu as the last menu item in the menu bar. They usually have a menu item with the keyboard shortcut <kbd>⌘</kbd>+<kbd>?</kbd>, which shows some kind of help or documentation. I named the menu item "Visit kitty website" and let it open the kitty website as documentation.
macOS also magically adds a search feature to the help menu.
`addItemWithTitle:` can be used instead of `initWithTitle:`. It returns an `NSMenuItem`, which removes the need for allocating an `NSMenuItem` manually and releasing it again.
`glfwGetCocoaKeyEquivalent()` in `glfw/cocoa_window.m` expects the returned characters to be of type `unichar`, which won't work for all unicode characters because it is defined as `unsigned short` according to https://developer.apple.com/documentation/foundation/unichar?language=objc, which is only guaranteed to be at least 16 bits in size. The code calling this function also expects the encoding to be UTF-16.
When I added the various keys in https://github.com/kovidgoyal/kitty/pull/1928, I missed these facts. This means, that `glfwGetCocoaKeyEquivalent()` will behave unexpectedly when called with any of the new-ish keys. Luckily this function is currently only used for determining the macOS shortcut for `new_os_window` but I plan on using it more in the future.
Some of the constants, e.g. `NSBackspaceCharacter` are UTF-16 constants, so we can't just use UTF-8 everywhere.
I fixed the problem by using either UTF-8 characters packed into a `uint32_t` or UTF-16 characters in a `unichar` and then converting them to a UTF-8 encoded char string.
`NSEventModifierFlagNumericPad` isn't guaranteed to fit in a `unichar`, which made this undefined behaviour. It also didn't work. I tried to make it work using `NSEventModifierFlagNumericPad` as a modifier instead, as can be seen in this commit, but couldn't get it to work either because the constants used are native key codes and not unicode characters. Therefore the numpad keys will be removed in the next commit.
Since `CIRCUMFLEX` and `^` were removed from `UN_SHIFTED_PRINTABLE` in b2d428618cbb2b6cc316105fe8135f6d523303da by 3a2a16f54ceac0f999fc31957e2653239a9b11b5 and b5229ec73c07dcb5ddbc0727e77f5af0e6adfb53, `generate_key_table()` wasn't yet run again.
On macOS the keyboard shortcuts are visible in the menu bar. When the keyboard shortcut is used, the corresponding menu bar item flashes to indicate which action was just executed.
kitty allows defining multiple keyboard shortcuts for the same action but macOS allows only one, so kitty needs to decide which one should be handled by macOS. Currently it chooses the first keyboard shortcut with only the command key as a modifier key or the first shortcut when there are no shortcuts with only the command key as a modifier.
When a user tries to set their own keyboard shortcut (and doesn't use `clear_all_shortcuts yes`), this won't change the shortcut displayed in the menu bar since the first (default) shortcut with the command key is <kbd>⌘</kbd>+<kbd>n</kbd>.
I think simply choosing the last defined keyboard shortcut is better. This will even allow the user to specify modifier keys other than the command key while still changing the shortcut in the menu bar. This change will not change the default behaviour because all the macOS specific keyboard shortcuts are defined after the non-macOS specific ones.
