Open xroberx opened 1 year ago
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 [
requires you to press CtrlAlt or AltGr then this is a problem with crossterm on Windows I think (it interprets it as C-A-[
).
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?
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.
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 : Alt-_
Alt-|
.
I don't think we can do anything about this. This is just... windows legacy madness.
The issue is fundamental that AltGr-<X>
is treated as follows by the Operating system:
So on a german layout, for example, pressing: AltGr-7
turns into ralt-rctrl-{
.
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. noremap [k [s
just works. I guess Helix wants to be too smart while Vim does this the old way : the user does not press keys, he/she types chars.
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 c-c
and c
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 c is 0x63
The char |
is on the B key on my keyboard. I bet the crossterm event is AltGr-|
or Ctrl-Alt-|
not AltGr-B
. You never get Shift-|
nor Ctrl-|
. Is the AltGr modifier needed ?
What it is said in the comments in Vim source is that modifiers are read only when needed.
AltGr-|
or Ctrl-Alt-|
is |
Shift-A
does not mean more than A
Ctrl-c
is 0x3
(aka ETX
or ^C
)I can type ^
in 3 different ways, 3 different keys: ^
dead key (without mod), AltGr-^
and Shift-AltGr-^
. With Vim all keys produce the same char ^
that can be mapped to one only command. With Helix 3 maps are needed/available with same or different commands.
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