alacritty: Can't input "@" on German keyboard with

Indeed, this works for me when alt_send_esc: false is set.

Thank you to everyone involved.

It certainly applies to macOS (10.13.x).

Can confirm that this does not work with norwegian layout as well. Norwegian layout

<colgroup> <col class="org-left" /> <col class="org-right" /> <col class="org-left" /> <col class="org-left" /> </colgroup>

meta-key	button	creates	works
AltGr	0	}
AltGr	2	@
AltGr	3	£	yes
AltGr	4	$
AltGr	5	€	yes
AltGr	7	{
AltGr	8	[
AltGr	9	]
AltGr	\	´	yes
AltGr	¨	~	yes

Same here on French Azerty, none of the AltGr combinations are working

OMG. I’am very sorry, but i’ve posted to the wrong repo -.-.

Forget what i was asking for. SORRY!

I’m seeing a version of this on macOS with a UK keyboard. AltGr + the number keys gives me the expected characters (AltGr + 2 = €, AltGr + 4 = ¢) for every number… except for AltGr + 3, which should give a #, and which is the only one I actually care about being able to enter into terminal.

This key combination just does nothing at all. On the plus side, I guess I have an excuse not to comment my code any more.

I got a bit further with this today while playing around with Alacritty on OS X again. It’s not correct that the AltGr + 3 key combination does nothing at all – I tried entering it in an Alacritty terminal containing a text-mode emacs instance, and emacs thought I’d entered M-#.

This suggests that AltGr + 3 is correctly yielding a # character, but with the Alt modifier incorrectly applied. Running with --print-events shows this happening:

[2019-02-13 14:32] [INFO] glutin event: WindowEvent { window_id: WindowId(Id(140377278525984)), event: KeyboardInput { device_id: DeviceId(DeviceId), input: KeyboardInput { scancode: 61, state: Pressed, virtual_keycode: Some(RAlt), modifiers: ModifiersState { shift: false, ctrl: false, alt: true, logo: false } } } }
[2019-02-13 14:32] [INFO] glutin event: WindowEvent { window_id: WindowId(Id(140377278525984)), event: KeyboardInput { device_id: DeviceId(DeviceId), input: KeyboardInput { scancode: 20, state: Pressed, virtual_keycode: Some(Key3), modifiers: ModifiersState { shift: false, ctrl: false, alt: true, logo: false } } } }
[2019-02-13 14:32] [INFO] glutin event: WindowEvent { window_id: WindowId(Id(140377278525984)), event: ReceivedCharacter('#') }
[2019-02-13 14:32] [INFO] glutin event: WindowEvent { window_id: WindowId(Id(140377278525984)), event: KeyboardInput { device_id: DeviceId(DeviceId), input: KeyboardInput { scancode: 20, state: Released, virtual_keycode: Some(Key3), modifiers: ModifiersState { shift: false, ctrl: false, alt: true, logo: false } } } }
[2019-02-13 14:32] [INFO] glutin event: WindowEvent { window_id: WindowId(Id(140377278525984)), event: KeyboardInput { device_id: DeviceId(DeviceId), input: KeyboardInput { scancode: 61, state: Released, virtual_keycode: Some(RAlt), modifiers: ModifiersState { shift: false, ctrl: false, alt: false, logo: false } } } }

For now I’ve added the following keybinding to my config as a temporary fix:

 - { key: Key3,     mods: Alt,              chars: "#"                  }

This works, but is not ideal because it doesn’t differentiate between Right and Left Alt. Left Alt + another key should produce that key plus the Alt modifier; Right Alt plus another key should not.

Sorry it took me a bit to test this, I only have a Windows at work. I’m getting the following output for pressing <Alt Gr> <Q> on a German keyboard with Alacritty v0.2.5 and --print-events. This is in PowerShell where an “@” is actually printed which makes me think that your reasoning for an invalid escape code may be spot on. I usually only develop software on Linux but I can try compiling Alacritty on Windows with your debug patches if it is important.

[2019-01-10 10:28] [INFO] glutin event: Awakened
[2019-01-10 10:28] [INFO] glutin event: WindowEvent { window_id: WindowId(WindowId(0x406c2)), event: KeyboardInput { device_id: DeviceId(DeviceId(0)), input: KeyboardInput { scancode: 29, state: Pressed, virtual_keycode: Some(LControl), modifiers: ModifiersState { shift: false, ctrl: true, alt: false, logo: false } } } }
[2019-01-10 10:28] [INFO] glutin event: DeviceEvent { device_id: DeviceId(DeviceId(65601)), event: Key(KeyboardInput { scancode: 56, state: Pressed, virtual_keycode: Some(RAlt), modifiers: ModifiersState { shift: false, ctrl: true, alt: false, logo: false } }) }
[2019-01-10 10:28] [INFO] glutin event: WindowEvent { window_id: WindowId(WindowId(0x406c2)), event: KeyboardInput { device_id: DeviceId(DeviceId(0)), input: KeyboardInput { scancode: 56, state: Pressed, virtual_keycode: Some(RAlt), modifiers: ModifiersState { shift: false, ctrl: true, alt: true, logo: false } } } }
[2019-01-10 10:28] [INFO] glutin event: DeviceEvent { device_id: DeviceId(DeviceId(65601)), event: Key(KeyboardInput { scancode: 16, state: Pressed, virtual_keycode: Some(Q), modifiers: ModifiersState { shift: false, ctrl: true, alt: true, logo: false } }) }
[2019-01-10 10:28] [INFO] glutin event: WindowEvent { window_id: WindowId(WindowId(0x406c2)), event: KeyboardInput { device_id: DeviceId(DeviceId(0)), input: KeyboardInput { scancode: 16, state: Pressed, virtual_keycode: Some(Q), modifiers: ModifiersState { shift: false, ctrl: true, alt: true, logo: false } } } }
[2019-01-10 10:28] [INFO] glutin event: WindowEvent { window_id: WindowId(WindowId(0x406c2)), event: ReceivedCharacter('@') }
[2019-01-10 10:28] [INFO] glutin event: Awakened
[2019-01-10 10:28] [INFO] glutin event: Awakened
[2019-01-10 10:28] [INFO] glutin event: DeviceEvent { device_id: DeviceId(DeviceId(65601)), event: Key(KeyboardInput { scancode: 16, state: Released, virtual_keycode: Some(Q), modifiers: ModifiersState { shift: false, ctrl: true, alt: true, logo: false } }) }
[2019-01-10 10:28] [INFO] glutin event: WindowEvent { window_id: WindowId(WindowId(0x406c2)), event: KeyboardInput { device_id: DeviceId(DeviceId(0)), input: KeyboardInput { scancode: 16, state: Released, virtual_keycode: Some(Q), modifiers: ModifiersState { shift: false, ctrl: true, alt: true, logo: false } } } }
[2019-01-10 10:28] [INFO] glutin event: WindowEvent { window_id: WindowId(WindowId(0x406c2)), event: KeyboardInput { device_id: DeviceId(DeviceId(0)), input: KeyboardInput { scancode: 29, state: Released, virtual_keycode: Some(LControl), modifiers: ModifiersState { shift: false, ctrl: false, alt: true, logo: false } } } }
[2019-01-10 10:28] [INFO] glutin event: DeviceEvent { device_id: DeviceId(DeviceId(65601)), event: Key(KeyboardInput { scancode: 56, state: Released, virtual_keycode: Some(RAlt), modifiers: ModifiersState { shift: false, ctrl: false, alt: true, logo: false } }) }
[2019-01-10 10:28] [INFO] glutin event: WindowEvent { window_id: WindowId(WindowId(0x406c2)), event: KeyboardInput { device_id: DeviceId(DeviceId(0)), input: KeyboardInput { scancode: 56, state: Released, virtual_keycode: Some(RAlt), modifiers: ModifiersState { shift: false, ctrl: false, alt: false, logo: false } } } }

I’ve created https://github.com/tomaka/winit/issues/756 for evaluating an upstream change to resolve this problem. There are alternative ways on how this can be resolved without requiring a change to winit, but I’d like to investigate an upstream approach first.

I might have confused you: TRIGGERED BINDING happens when I close Alacritty (Command + Q is the shortcut to close an application).

Oh, that changes everything. So there is no TRIGGERED BINDING reported when pressing RAlt + L?

If there’s no CHARACTER HAS BEEN SUPPRESSED being printed, then this probably isn’t even a keyboard issue but something different entirely. I feel like we’re getting somewhere here. 😄

Looking at the key event of the L key, the modifier alt is true. So I’m pretty certain that the problem is that the \x1b escape sequence is sent before @ is inserted. This results in issues since \e@ is not a valid escape sequence (try running echo -e "\e@" and you’ll see nothing gets printed).

From what I can tell we might need to fix this upstream and add a way to differentiate between AltGr and Alt as modifiers. Thanks for your help, this is likely the same on Windows! I’ll think about possible work arounds and open an issue upstream (and link it here) if I don’t find a solution.