That's a reference what we get when pressing ctrl + shift + c.

[1.288686403s] [INFO ] [alacritty] winit event: WindowEvent { window_id: WindowId(WindowId(94882226519600)), event: KeyboardInput { device_id: DeviceId(Wayland(DeviceId)), event: KeyEvent { physical_key: KeyI, logical_key: Character("C"), text: Some("C"), location: Standard, state: Pressed, repeat: false, platform_specific: KeyEventExtra { key_without_modifiers: Character("c"), text_with_all_modifiers: Some("\u{3}") } }, is_synthetic: false } }
[1.349699787s] [INFO ] [alacritty] winit event: WindowEvent { window_id: WindowId(WindowId(94882226519600)), event: KeyboardInput { device_id: DeviceId(Wayland(DeviceId)), event: KeyEvent { physical_key: KeyI, logical_key: Character("C"), text: Some("C"), location: Standard, state: Released, repeat: false, platform_specific: KeyEventExtra { key_without_modifiers: Character("c"), text_with_all_modifiers: Some("\u{3}") } }, is_synthetic: false } }

This branch should sort of work now, except for macOS users given that OptionAsAlt is not ported yet.

As it was discussed on IRC, I've added transition from old winit keys into their modern counterparts.

The one more question is what should we do with the Numpad bindings, we had them before, but with the current winit, they are not encoded into the virtual key code directly, but rather reside in the position option.

We still have information whether a binding was from a numpad or not, but it could require config changes, such as adding an implicit field default to None or Standard.

We could also drop support for old numpad keys in the config and solely rely on our new keys, that would require users to delete a few lines, but I don't think that's an issue. I'd prefer this variant btw.

For what it's worth alacritty has seen config changes in the past that required users to make modifications to their config.

@kchibisov could you give an example of a change that a user would need to make to replace the old numpad keys with the new keys in their config?

@afh there's no difference between them and normal keys now. Unless you manually define special set of bindings just for numpad, which differ from regular keys there shouldn't be an issue.

So all NumpadSubtract/Add are now just -,+, etc.

@perfbot (just testing stuff)

Thanks for clarifying, @kchibisov. Personally I do not use NumPad keys specifically, yet I could see someone wanting to do that. Would it be possible and useful to introduce a Numpad modifier to Control, Alt, or Shift when specifying a key binding?

For example:

key_bindings:
   { key: Minus, mods: Numpad, action: DecreaseFontSize }

It's just not clear how default bindings should work then, should we separately define numpad bindings or not, because it affects all the keys. What we get now from the winit is

Key { code: Character("-"), position: Numpad }
Key { code: Character("-"), position: Standard }

We could add implicit Standard field to all the bindings, and translate Numpad to Numpad bindings, and still have the bindings separate... That could work, but not sure how convenient it could be.

The numpad thing in the config should be resolved now.

Thank you so much for working on this, @kchibisov, and keep up the great work!! 🎉 I'm happy to see this merged and look forward to the next alacritty release (candidate) as it should resolve a long standing issue I had with alacritty on OpenBSD (see rust-windowing/winit#2032).