helix-editor / helix

A post-modern modal text editor.
https://helix-editor.com
Mozilla Public License 2.0
33.22k stars 2.47k forks source link

Keymaps with altgr keys don't work on windows #7129

Open xroberx opened 1 year ago

xroberx commented 1 year ago

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

sicher commented 1 year ago

I have the same issue. Helix 23.03. Windows Terminal 1.16 and PowerShell 7.3.4.

CptPotato commented 1 year ago

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" }
sicher commented 1 year ago

Ah. I'm on Swedish layout. It requires AltGr to type brackets.

xroberx commented 1 year ago

Spanish layout here. I also have to press AltGr, but why does it work properly in Insert mode and not in Normal mode?

CptPotato commented 1 year ago

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.

xroberx commented 1 year ago

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...

xavier-gl71 commented 1 year ago

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-|.

pascalkuthe commented 1 year ago

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.

xavier-gl71 commented 1 year ago

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.

pascalkuthe commented 1 year ago

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

pascalkuthe commented 1 year ago

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

xavier-gl71 commented 1 year ago

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.

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.

JeromeSchmied commented 8 months ago

same issue here