Binding to "Grave" key stopped working

[bugeats]

Just updated Alacritty here on macOS 10.13.4 and one of my critical keybindings stopped working.

This doesn't work anymore:

https://github.com/bugeats/dotfiles/blob/master/src/config/alacritty/alacritty.yml#L200

But this does still work:

https://github.com/bugeats/dotfiles/blob/master/src/config/alacritty/alacritty.yml#L188

Both are configured to send the same character. My only guess is that Grave is no longer identified.

[francesca64]

1. This originates in winit, specifically a result of macOS: Implement NSTextInputClient rust-windowing/winit#518.
2. When reporting issues about keyboard handling, always include the input method + layout. For instance, grave will be interpreted rather differently on the US international layout, which is something winit was oblivious to before.
3. I recommend that someone other than me looks into fixing this, since A) it's probably not too hard, and B) I already have a lot on my plate, so I wouldn't be able to get to this for a while.

[jwilm]

@bugeats you can run alacritty with --print-events to see what key name is being detected and update your config with that.

[bugeats]

When I press Command + A I see something like this in the events:

glutin event: WindowEvent { window_id: WindowId(Id(140724590965728)), event: KeyboardInput { device_id: DeviceId(DeviceId), input: KeyboardInput { scancode: 54, state: Released, virtual_keycode: Some(RWin), modifiers: ModifiersState { shift: false, ctrl: false, alt: false, logo: true } } } }
glutin event: WindowEvent { window_id: WindowId(Id(140724590965728)), event: KeyboardInput { device_id: DeviceId(DeviceId), input: KeyboardInput { scancode: 0, state: Pressed, virtual_keycode: Some(A), modifiers: ModifiersState { shift: false, ctrl: false, alt: false, logo: true } } } }
glutin event: WindowEvent { window_id: WindowId(Id(140724590965728)), event: ReceivedCharacter('a') }

When I press Command + ` (Grave) I see this:

glutin event: WindowEvent { window_id: WindowId(Id(140724590965728)), event: KeyboardInput { device_id: DeviceId(DeviceId), input: KeyboardInput { scancode: 54, state: Released, virtual_keycode: Some(RWin), modifiers: ModifiersState { shift: false, ctrl: false, alt: false, logo: true  }  }  }  }
glutin event: WindowEvent { window_id: WindowId(Id(140724590965728)), event: KeyboardInput { device_id: DeviceId(DeviceId), input: KeyboardInput { scancode: 54, state: Released, virtual_keycode: Some(RWin), modifiers: ModifiersState { shift: false, ctrl: false, alt: false, logo: false  }  }  }  }

I appears to me that the Grave character is not even being sent/recognized.

[bugeats]

Input method: both native MacBook Pro keyboard, and external USB keyboard in US English.

[jwilm]

Given that Command + Grave is a system keybinding, I wonder if the underlying change to winit basically prevents that from being forwarded to the application.

[francesca64]

Is it really considered necessary for winit to handle system keybindings? I've put together a fun hack that makes this work again (https://github.com/francesca64/winit/tree/macos-grave) but it feels unclean. Besides that, it results in everyone getting a grave character when using the system shortcut.

The reason this used to work was because winit's macOS keyboard handling was formerly quite naïve. Do other apps allow you to use this shortcut?

[bugeats]

Do other apps allow you to use this shortcut?

Not in my experience. Alacritty has a very raw keybinding experience on macOS and everything must be specified. I personally like it this way, and I've used it to my advantage. The Command + Grave combo is the system-wide convention for flipping between windows, scoped by application. In my case, I use it to navigate tmux sessions.

[francesca64]

Well, if someone comes up with a fix that doesn't cause issues elsewhere, I'll gladly merge it.

[francesca64]

So, the reason that hack results in receiving a grave character is because of the doCommandBySelector handler, which is implemented to just return the characters associated with the most recent key down event. This was done so that Ctrl+C/etc. would generate characters, since those don't trigger insertText and instead trigger doCommandBySelector:noop. Cmd+Grave also triggers doCommandBySelector:noop, but no other NSTextInputClient handlers.

So, new more sophisticated hack idea:

• General key down/up handing would still be done through the responder chain, setting a flag to indicate it's being received the normal way
• The event loop would forward key down/up events to custom WinitView methods that place KeyboardInput events into a queue
• Every call to insertText or doCommandBySelector would reset the flag and queue; normally the queue is just discarded
• If doCommandBySelector is triggered and the flag isn't set, then the key events in the queue are sent to the user, instead of the regular ReceivedCharacter event generation behavior

I know I insinuated I didn't want to work on this, but I'm unfortunately addicted to problem solving. I'll try to implement this tomorrow.

[francesca64]

Well, it's messy, but it seems to work: https://github.com/francesca64/winit/tree/macos-grave

@bugeats let me know if this works for you. It would also be good if other people tested this, in case of regressions.

[snoblenet]

is there a branch of Alacritty that uses your branch of macos-grave @francesca64 ?

I'd be keen to test it

[francesca64]

Here, I just threw one together: https://github.com/francesca64/alacritty/tree/macos-grave

[snoblenet]

Many thanks. I built your branch. Unfortunately it did not restore my formerly working bindings for next session and previous session in Tmux:

 - { key: Grave,    mods: Option, chars: "\x01\x29" }
 - { key: Grave,    mods: Option|Shift, chars: "\x01\x28" }

My other key bindings still work as ever so I'm sure the issue is with macos-grave. The following all did/still work:

 - { key: Grave,    mods: Command, command: { program: "/usr/local/bin/tmux", args: ["next"] } }
 - { key: Grave,    mods: Command|Shift, command: { program: "/usr/local/bin/tmux", args: ["prev"] } }
 - { key: N,        mods: Command, chars: "\x01\x6e" }
 - { key: T,        mods: Command, chars: "\x14" }
 - { key: W,        mods: Command, command: { program: "/usr/local/bin/tmux", args: ["kill-pane"] } }
 - { key: Key1,     mods: Command, chars: "\x01\x31" }
 - { key: Key2,     mods: Command, chars: "\x01\x32" }
 - { key: Key3,     mods: Command, chars: "\x01\x33" }
 - { key: Key4,     mods: Command, chars: "\x04\x34" }
 - { key: Key5,     mods: Command, chars: "\x01\x35" }
 - { key: Key6,     mods: Command, chars: "\x01\x36" }
 - { key: Key7,     mods: Command, chars: "\x01\x37" }
 - { key: Key8,     mods: Command, chars: "\x01\x38" }
 - { key: Key9,     mods: Command, chars: "\x01\x39" }

All are by analogy with common mappings in Mac GUI apps.

[unphased]

I've encountered this problem, with Cmd+Grave, but also with Ctrl+Tab. @francesca64 Do you think that is also plausibly caused by the same issue? I'll test the branch.

Ctrl+Tab seems to do something similar to Cmd+Shift+]. And might be a macOS system bind.

Update: branch fixes Grave but my Ctrl+Tab is still not getting passed in

[unphased]

log from print events:

glutin event: WindowEvent { window_id: WindowId(Id(140551206796576)), event: Focused(true) }
glutin event: WindowEvent { window_id: WindowId(Id(140551206796576)), event: KeyboardInput { device_id: DeviceId(DeviceId), input: KeyboardInput { scancode: 59, state: Released, virtual_keycode: Some(LControl), modifiers: ModifiersState { shift: false, ctrl: true, alt: false, logo: false } } } }
glutin event: WindowEvent { window_id: WindowId(Id(140551206796576)), event: KeyboardInput { device_id: DeviceId(DeviceId), input: KeyboardInput { scancode: 0, state: Pressed, virtual_keycode: Some(A), modifiers: ModifiersState { shift: false, ctrl: true, alt: false, logo: false } } } }
glutin event: WindowEvent { window_id: WindowId(Id(140551206796576)), event: ReceivedCharacter('\u{1}') }
glutin event: Awakened
glutin event: WindowEvent { window_id: WindowId(Id(140551206796576)), event: KeyboardInput { device_id: DeviceId(DeviceId), input: KeyboardInput { scancode: 0, state: Released, virtual_keycode: Some(A), modifiers: ModifiersState { shift: false, ctrl: true, alt: false, logo: false } } } }
glutin event: WindowEvent { window_id: WindowId(Id(140551206796576)), event: KeyboardInput { device_id: DeviceId(DeviceId), input: KeyboardInput { scancode: 48, state: Released, virtual_keycode: Some(Tab), modifiers: ModifiersState { shift: false, ctrl: true, alt: false, logo: false } } } }
glutin event: WindowEvent { window_id: WindowId(Id(140551206796576)), event: KeyboardInput { device_id: DeviceId(DeviceId), input: KeyboardInput { scancode: 59, state: Released, virtual_keycode: Some(LControl), modifiers: ModifiersState { shift: false, ctrl: false, alt: false, logo: false } } } }
glutin event: WindowEvent { window_id: WindowId(Id(140551206796576)), event: KeyboardInput { device_id: DeviceId(DeviceId), input: KeyboardInput { scancode: 55, state: Released, virtual_keycode: Some(RWin), modifiers: ModifiersState { shift: false, ctrl: false, alt: false, logo: true } } } }
glutin event: WindowEvent { window_id: WindowId(Id(140551206796576)), event: Focused(false) }

This is me focusing the window, pressing Ctrl, pressing and releasing A, pressing and releasing Tab, releasing Ctrl, and pressing Cmd (to focus to another window)... No ReceivedCharacter for the tab

[moon-stripe]

i think i'm seeing the same thing with <C-space>

➤ cargo run -- --print-events | grep -v Awakened
    Finished dev [unoptimized + debuginfo] target(s) in 0.0 secs
     Running `target/debug/alacritty --print-events`
glutin event: WindowEvent { window_id: WindowId(Id(140245736983792)), event: Resized(610, 414) }
glutin event: WindowEvent { window_id: WindowId(Id(140245736983792)), event: Moved(208, 611) }
[Unhandled CSI] action='l', args=[1005], intermediates=[63]
glutin event: WindowEvent { window_id: WindowId(Id(140245736983792)), event: Focused(true) }
glutin event: WindowEvent { window_id: WindowId(Id(140245736983792)), event: KeyboardInput { device_id: DeviceId(DeviceId), input: KeyboardInput { scancode: 59, state: Released, virtual_keycode: Some(LControl), modifiers: ModifiersState { shift: false, ctrl: true, alt: false, logo: false } } } }
glutin event: WindowEvent { window_id: WindowId(Id(140245736983792)), event: KeyboardInput { device_id: DeviceId(DeviceId), input: KeyboardInput { scancode: 59, state: Released, virtual_keycode: Some(LControl), modifiers: ModifiersState { shift: false, ctrl: false, alt: false, logo: false } } } }
glutin event: WindowEvent { window_id: WindowId(Id(140245736983792)), event: KeyboardInput { device_id: DeviceId(DeviceId), input: KeyboardInput { scancode: 59, state: Released, virtual_keycode: Some(LControl), modifiers: ModifiersState { shift: false, ctrl: true, alt: false, logo: false } } } }
glutin event: WindowEvent { window_id: WindowId(Id(140245736983792)), event: KeyboardInput { device_id: DeviceId(DeviceId), input: KeyboardInput { scancode: 8, state: Pressed, virtual_keycode: Some(C), modifiers: ModifiersState { shift: false, ctrl: true, alt: false, logo: false } } } }
glutin event: WindowEvent { window_id: WindowId(Id(140245736983792)), event: ReceivedCharacter('\u{3}') }
^C

that's just hitting <C-Space> and then <C-c>. The Space doesn't appear at all.

[sodiumjoe]

<C-space> was a red herring, it was a macos global shortcut I had accidentally enabled.

@unphased fyi I used bettertouchtool to work around the <C-Tab> issue (I have it bound to <C-a>n for tmux).

[sodiumjoe]

Did a bit of investigation here: rust-windowing/winit#625

I think this can be closed as wontfix. @bugeats I've had good results with remapping <C-tab> using BetterTouchTool to do something very similar.

[sodiumjoe]

@unphased the issue was fixed in winit in rust-windowing/winit#629, which should get into #1403, hopefully pretty soon

[unphased]

@sodiumjoe I tested #1403 (46316fc) and Grave bound on Cmd is still not working. It needs to be this specific key combo because this is how you switch windows in all mac apps.

It did fix Ctrl+Tab being broken though.

[sodiumjoe]

@unphased sorry i meant <C-Tab>. I think <Cmd-grave> is a wontfix rust-windowing/winit#625 (comment)

<Cmd-grave> works correctly for winit's multiwindow example, so i think once alacritty supports multiple windows, it should start working correctly for alacritty.

[unphased]

Yes that would be the true solution. I will use a BetterTouchTool key bind hack to trigger my AppleScript which toggles the windows in the meantime!

[sodiumjoe]

in any case i don't think <Cmd-grave> will be bindable to another key, so I think this issue should be closed

[chrisduerr]

Thanks for the clarification. I've updated the #1403 PR and removed this issue from the list of problems solved by it.

[lucat1]

Sorry to bring up this old issue, but I think I could be facing the same issue when trying to bind ctrl+grave. I have tested it with alt+grave and it seems to be working fine.

Here are my keybinds:

  - { key: Grave,     mods: Control,    chars: 'testtesttest'         }
  - { key: Grave,     mods: Alt,        chars: 'testtesttest'         }

[danillos]

To Grave works with Command I had to change on MacOS the Keyboard Shortcuts Move Focus to Next Window to another one, I used Alt + `