-
-
Notifications
You must be signed in to change notification settings - Fork 2.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Keymaps with altgr keys don't work on windows #7129
Comments
I have the same issue. Helix 23.03. Windows Terminal 1.16 and PowerShell 7.3.4. |
What keyboard layout are you using? If entering You can work around this by adjusting your keymap: "C-A-[" = { d = "goto_prev_diag", D = "goto_first_diag", f = "goto_prev_function", c = "goto_prev_comment", a = "goto_prev_parameter", t = "goto_prev_class", p = "goto_prev_paragraph", T = "goto_prev_test", g = "goto_prev_change", G = "goto_first_change", space = "add_newline_above" }
"C-A-]" = { d = "goto_next_diag", D = "goto_last_diag", f = "goto_next_function", c = "goto_next_comment", a = "goto_next_parameter", t = "goto_next_class", p = "goto_next_paragraph", T = "goto_next_test", g = "goto_next_change", G = "goto_last_change", space = "add_newline_below" } |
Ah. I'm on Swedish layout. It requires AltGr to type brackets. |
Spanish layout here. I also have to press AltGr, but why does it work properly in Insert mode and not in Normal mode? |
I think it's because insert mode reads the input as actual text while normal mode listens to the raw key presses. |
Oh I see, thank you for your fix by the way, it works perfectly now. I wonder if this is going to be fixed upstream though... |
I am a bépo layout user. I have the same problem with many keys: An other result is that some default shortcuts just don't work : |
I don't think we can do anything about this. This is just... windows legacy madness. The issue is fundamental that
So on a german layout, for example, pressing: This is how the OS handles it and its to applications to sort out the details. I looked at windows terminal and there are tons of PRs and issues about alt-gr handling. I am not sure if the terminal emulator can do better here. The current behavior seems to actually be intentional but I am not sure if I read the code correctly. Either way this is not something that should be solved in helix. I see that crossterm actually does some pretty complex handling (including calling the windows API to translate key events) so tey probably just need to handle this case there too. I don't use windows or a keyboard layout that uses atlgr so I can't debug this. I will submit a bug report to crossterm. |
This problem does not occur with Vim. See Key mapping in Vim Help. |
vim is written in C and therefore doesn't use crossterm. It doesn't have anything to do with the way we interpret key events. If we just ignored the modifier here then it would be impossible to create separate bindings for |
In fact they exactly implement what I sugesseted upstream to crossterm: https://github.com/vim/vim/blob/6ffcc58be32aa1b337bc839cfe173b68cfde7085/src/os_win32.c#L1266 we can't do this in helix because it requires differentiating between ralt/lalt and rctl/lctl |
c-c is 0x03 The char What it is said in the comments in Vim source is that modifiers are read only when needed.
I can type I think the Vim way is less accurate and offers less mappings but is more convenient. |
same issue here |
Summary
I can't use the "unimpaired" mode because square brackets do not open the corresponding menu on Windows. On Linux, it works flawlessly.
In Insert mode, the square brackets are successfully inserted, so I don't know what's going on.
Reproduction Steps
No response
Helix log
There is nothing related to this issue in helix.log
Platform
Windows
Terminal Emulator
Windows Terminal (stable and preview) and Git Bash (+winpty)
Helix Version
helix 23.05
The text was updated successfully, but these errors were encountered: