Cmd + `~` does not switch between OS windows in Kitty under Mac OS

[mattpolzin]

Describe the bug
Cmd + ~ does not switch between OS windows in Kitty under Mac OS. For most apps, that shortcut would cycle between windows of the same application. For Kitty, you see a diagnostic-like output in the terminal of " (arg: 9)".

To Reproduce
Steps to reproduce the behavior:

1. With more than one Kitty OS window open in Mac OS, press the tilde key while holding the command key.
2. See indicated output text and note that the window with focus has not switched.

Environment details

kitty 0.24.2 created by Kovid Goyal
Darwin MacBook-Pro-2.local 20.6.0 Darwin Kernel Version 20.6.0: Mon Aug 30 06:12:21 PDT 2021; root:xnu-7195.141.6~3/RELEASE_X86_64 x86_64
ProductName:	macOS ProductVersion:	11.6 BuildVersion:	20G165
Frozen: True
Paths:
  kitty: /Applications/kitty.app/Contents/MacOS/kitty
  base dir: /Applications/kitty.app/Contents/Resources/kitty
  extensions dir: /Applications/kitty.app/Contents/Resources/Python/lib/kitty-extensions
  system shell: /bin/bash
Loaded config files:
  /Users/mattpolzin/.config/kitty/kitty.conf

Config options different from defaults:
background_opacity            0.95
font_family                   JetBrains Mono Regular
macos_thicken_font            0.25
scrollback_pager_history_size 1073741824
shell_integration             frozenset({'disabled'})
tab_activity_symbol           ⦿
tab_bar_style                 powerline
tab_powerline_style           slanted
window_padding_width          FloatEdges(left=2.0, top=2.0, right=2.0, bottom=2.0)
Colors:
	color4                        #0000b2   
	foreground                    #b7cbff   

Environment variable names seen by the kitty process:
	COMMAND_MODE
	HOME
	LANG
	LOGNAME
	PATH
	SHELL
	SSH_AUTH_SOCK
	SSL_CERT_FILE
	TMPDIR
	USER
	XPC_FLAGS
	XPC_SERVICE_NAME
	__CFBundleIdentifier
	__CF_USER_TEXT_ENCODING

Additional context
The problem is reproducible with no configuration applied. Interestingly (but perhaps not importantly), the output noted above with "arg: 9" is only printed when using the bash shell. In zsh, the bug persists, but nothing is printed to the screen.

[kovidgoyal]

Works for me running from master with

kitty --config=NONE

You should run kitty with

kitty --debug-input

that will tell you what is happening to the keypresses. And the
"diagnostic output" you are talking about is just the encoded key event
being sent to the terminal.

[page-down]

Did you configure Cmd+` in System Preferences -> Keyboard -> Shortcuts -> Keyboard -> Move focus to next window?

If more than one instance of kitty is opened, for example by running the kitty command in the terminal, the OS windows of these two instances will not be switched via Cmd+` .

Unfortunately I no longer have macOS 11 available for testing, but I believe it should work fine.

[kujohn]

I am also having this issue, I have tried kitty --config=NONE and this is what I get:

6;9u

In other terminals without configuration, this would allow me to cycle windows. Any tips?

[page-down]

I am also having this issue

Are you using kitty 0.24.2? What's in your System Preferences "Shortcuts" ? (see my comment above)
Try running the following command to provide more information.

defaults read com.apple.symbolichotkeys

kitty --config=NONE --debug-input
# press cmd+` and see the logs

[mattpolzin]

I discovered that on one of my laptops, 0.24.2 was not exhibiting the issue even as my other laptop with the same version was... going to look into suggestions mentioned above next! Thanks!

The laptop this is working on is running Mac OS 11.5 whereas the one it is not working on is running 11.6, but that could also be total coincidence.

[mattpolzin]

Ok, I have not had time to digest the following yet, but I'll share in case anyone is curious. There does seem to be some meaningful difference in the output of --debug-input between the laptop where switching windows is working vs. the laptop where it is not working.

[EDIT] I should mention, I have also confirmed that I have Cmd+` turned on in my system preferences (and it works in other apps on both laptops).

Working:

-------------- flags changed -----------------
NSEvent: type=FlagsChanged loc=(829.236,263.865) time=348760.3 flags=0x100108 win=0x7fc77fc3a350 winNum=13374 ctxt=0x0 keyCode=55
flagsChanged: modifier: super native_key: 0x37 (<noname>) glfw_key: 0xe064 mods: super 
on_key_input: glfw key: 0xe064 native_code: 0x37 action: PRESS mods: super text: '' state: 0 updateIMEPosition: left=290.500000, top=68.500000, width=7.000000, height=15.000000
ignoring as keyboard mode does not support encoding this event
---------------- key down -------------------
NSEvent: type=KeyDown loc=(829.236,263.865) time=348760.6 flags=0x100108 win=0x7fc77fc3a350 winNum=13374 ctxt=0x0 chars="`" unmodchars="`" repeat=0 keyCode=50
keyDown triggerred global macOS shortcut ignoring
----------------- key up --------------------
NSEvent: type=KeyUp loc=(829.236,263.865) time=348760.6 flags=0x100108 win=0x7fc77fc3a350 winNum=13374 ctxt=0x0 chars="`" unmodchars="`" repeat=0 keyCode=50
keyUp ignored as corresponds to previous keyDown that trigerred a shortcut
-------------- flags changed -----------------
NSEvent: type=FlagsChanged loc=(829.236,263.865) time=348760.8 flags=0x100 win=0x7fc77fc3a350 winNum=13374 ctxt=0x0 keyCode=55
flagsChanged: modifier: super native_key: 0x37 (<noname>) glfw_key: 0xe064 mods: none 
on_key_input: glfw key: 0xe064 native_code: 0x37 action: RELEASE mods: none text: '' state: 0 updateIMEPosition: left=290.500000, top=68.500000, width=7.000000, height=15.000000
ignoring as keyboard mode does not support encoding this event

Not working (different laptop):

-------------- flags changed -----------------
NSEvent: type=FlagsChanged loc=(575.594,1081.6) time=4724080.8 flags=0x100108 win=0x7f9209e3bb30 winNum=144427 ctxt=0x0 keyCode=55
flagsChanged: modifier: super native_key: 0x37 (<noname>) glfw_key: 0xe064 mods: super 
on_key_input: glfw key: 0xe064 native_code: 0x37 action: PRESS mods: super text: '' state: 0 updateIMEPosition: left=115.000000, top=68.000000, width=7.000000, height=15.000000
ignoring as keyboard mode does not support encoding this event
---------------- key down -------------------
NSEvent: type=KeyDown loc=(575.594,1081.6) time=4724081.2 flags=0x100108 win=0x7f9209e3bb30 winNum=144427 ctxt=0x0 chars="`" unmodchars="`" repeat=0 keyCode=50
Press: native_key: 0x32 (`) glfw_key: 0x60 mods: super char_count: 1 deadKeyState: 0 repeat: 0 
	TextInputCtx: doCommandBySelector: (noop:)
text: <none> glfw_key: ` marked_text: ()
on_key_input: glfw key: 0x60 native_code: 0x32 action: PRESS mods: super text: '' state: 0 updateIMEPosition: left=115.000000, top=68.000000, width=7.000000, height=15.000000
sent encoded key to child
----------------- key up --------------------
NSEvent: type=KeyUp loc=(575.594,1081.6) time=4724081.3 flags=0x100108 win=0x7f9209e3bb30 winNum=144427 ctxt=0x0 chars="`" unmodchars="`" repeat=0 keyCode=50
Release: native_key: 0x32 (`) glfw_key: 0x60 mods: super 
on_key_input: glfw key: 0x60 native_code: 0x32 action: RELEASE mods: super text: '' state: 0 updateIMEPosition: left=115.000000, top=68.000000, width=7.000000, height=15.000000
ignoring as keyboard mode does not support encoding this event
-------------- flags changed -----------------
NSEvent: type=FlagsChanged loc=(575.594,1081.6) time=4724081.6 flags=0x100 win=0x7f9209e3bb30 winNum=144427 ctxt=0x0 keyCode=55
flagsChanged: modifier: super native_key: 0x37 (<noname>) glfw_key: 0xe064 mods: none 
on_key_input: glfw key: 0xe064 native_code: 0x37 action: RELEASE mods: none text: '' state: 0 updateIMEPosition: left=115.000000, top=68.000000, width=7.000000, height=15.000000
ignoring as keyboard mode does not support encoding this event

[mattpolzin]

Finally (regarding prior suggested troubleshooting), here's the output of the defaults read on my laptop where switching is not working:

mattpolzin: ~ $ defaults read com.apple.symbolichotkeys
{
    AppleSymbolicHotKeys =     {
        15 =         {
            enabled = 0;
        };
        16 =         {
            enabled = 0;
        };
        164 =         {
            enabled = 1;
            value =             {
                parameters =                 (
                    262144,
                    4294705151
                );
                type = modifier;
            };
        };
        17 =         {
            enabled = 0;
        };
        18 =         {
            enabled = 0;
        };
        19 =         {
            enabled = 0;
        };
        20 =         {
            enabled = 0;
        };
        21 =         {
            enabled = 0;
        };
        22 =         {
            enabled = 0;
        };
        23 =         {
            enabled = 0;
        };
        24 =         {
            enabled = 0;
        };
        25 =         {
            enabled = 0;
        };
        26 =         {
            enabled = 0;
        };
        79 =         {
            enabled = 1;
        };
        80 =         {
            enabled = 1;
        };
        81 =         {
            enabled = 1;
        };
        82 =         {
            enabled = 1;
        };
    };
}

[mattpolzin]

Whoa! So, the output of that defaults read was really different on my other laptop. On a whim, I went into my system preferences and I unchecked and then re-checked the box next to "Move focus to next window" and that fixed the problem!

Thanks so much for the help looking into this!

[page-down]

Thank you for the debugging information.

So the the values were all non-existent, right?

The only way I could fix this would be to use the default values when they don't exist.
Unless there is another way to read the unconfigured default values.

[mattpolzin]

At the end of this all, it seems to me there was some kind of bug in Mac OS (since simply toggling a preference back and forth fixed it).

So, doesn't seem like Kitty needs to address the problem directly, but I suppose even a warning message on startup (or via a flag of some kind like --check-system-defaults) that the defaults values look broken could help.

Again, I don't see this as a problem Kitty needs to fix. This comment thread was instrumental in me being able to fix it for myself, though.

[kujohn]

I followed @mattpolzin suggestion of disable/enabling and it works now, thank you!

[kovidgoyal]

@page-down: Perhaps we need to keep a default set of shortcuts, and use
that if the definition for a particular action is missing from the
plist. I assume that toggling the preference causes the shortcut to be
written to the plist with "disabled", so when the shortcut is missing
altogether from the plist, we assume it has a default value and is
enabled?

[page-down]

@kovidgoyal

Perhaps we need to keep a default set of shortcuts ...

This seems to be the only way to go for now, but Apple is likely to change things in future versions.
(And I don't know about the defaults in previous macOS version.)

... when the shortcut is missing altogether from the plist,
we assume it has a default value and is enabled? ...

If it does not exist (the entire plist not exist or the individual id not exist),
then the default state from the current system will be used.
However, only some shortcuts are enabled by default.

(Toggling any of these will save all (default) configured shortcuts with value, whether enabled or disabled.)