Skip to content
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

Open
xroberx opened this issue May 24, 2023 · 13 comments
Open

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

xroberx opened this issue May 24, 2023 · 13 comments
Labels
C-bug Category: This is a bug O-windows Operating system: Windows upstream

Comments

@xroberx
Copy link

xroberx commented May 24, 2023

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

@xroberx xroberx added the C-bug Category: This is a bug label May 24, 2023
@sicher
Copy link

sicher commented May 24, 2023

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

@CptPotato
Copy link
Contributor

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
Copy link

sicher commented May 24, 2023

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

@xroberx
Copy link
Author

xroberx commented May 24, 2023

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

@CptPotato
Copy link
Contributor

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
Copy link
Author

xroberx commented May 24, 2023

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

@kirawi kirawi added the S-waiting-on-review Status: Awaiting review from a maintainer. label May 24, 2023
@xavier-gl71
Copy link

xavier-gl71 commented Sep 13, 2023

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
Copy link
Member

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:

  • precompose unicode
  • set ralt modifier
  • set rctrl modifier

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
Copy link

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
Copy link
Member

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
Copy link
Member

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
Copy link

xavier-gl71 commented Sep 13, 2023

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

@pascalkuthe pascalkuthe added the O-windows Operating system: Windows label Oct 3, 2023
@pascalkuthe pascalkuthe changed the title Square brackets don't work in normal mode on Windows Keymaps with altgr keys don't work on windows Jan 1, 2024
@JeromeSchmied
Copy link

same issue here

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-bug Category: This is a bug O-windows Operating system: Windows upstream
Projects
None yet
Development

No branches or pull requests

7 participants