Neovide: AltGr handled incorrectly

[Ninmi]

What I press in insert mode = what actually outputs
> = <
{ = exits from insert mode, sometimes inserting a number first before exiting, sometimes after. Inserts a number in normal mode.
} = same as above
[ and ] = same as {}
@ = exits insert mode into normal mode. acts as number 2 in normal mode

Seems like the keys behind alt+gr in a finnish/swedish layout simply come out as numbers? Though > returning a < is a bigger mystery.
Arch Linux, i3, fi key layout. Installed with the AUR package this time.
Finnish keyboard for reference:
http://kbdlayout.info/KBDFI/

[Kethku]

This is a known issue. AltGr is not supported properly today. I'd appreciate some help on this though since I've never used an alternative layout which requires AltGr. @jonvaldes has encountered this and might have some more background

[Kethku]

The move to SDL2 improved this somewhat, and I'm confident that it should be solvable, but my lack of expertise in this area makes it hard

[Kethku]

This is potentially related: https://github.com/Kethku/neovide/issues/125 but I'm pretty sure AltGr is not IME input...

[Ninmi]

Did not know the AltGr issue was known, apologies. However, > is behind shift key instead. A real mystery. I also don't think the AltGr issue is IME related, but I have no real knowledge either. Wish I could be of more use here! I can also confirm my IME, Fcitx, does not even pop up, though it's not a deal breaker for me as it's there for my third language and don't really need it in vim. IME not working is not that uncommon anyway. The exact same issue is in Steam chat and it has persisted unresolved for 7 years.

[jonvaldes]

Just randomly came across this on social media. Could be useful for debugging IME stuff https://hsivonen.fi/ime/

[Kethku]

This is definitely what I need to fix this. Thanks. It may be a bit before I get to it, but chances went up dramatically

_{Sent with GitHawk}

[FlatBartender]

I'm encountering the same range of issues.
In addition to the AltGr problem and the "<>" keys, I can't seem to be able to use the +, -, * and / from the numpad. The numbers, the "." and enter all work when numlock is on.
When numlock is off, only the enter key works.

I'm on Manjaro (Arch Linux derivative), on KDE, using the french layout. I'll be happy to test anything if you need a hand, neovide looks slick af

[Proximyst]

I'm on Windows using the Norwegian keyboard layout; shift+< does > for me. I suppose the <> key isn't supported at all, as it sure isn't limited to AltGr?

[iwikal]

@Kethku Have you considered using winit::event::WindowEvent::ReceivedCharacter? I think it could potentially help with this.

[Kethku]

We don't use winit. It was too buggy on too many platforms.

We use the equivalent of this in sdl: https://github.com/Kethku/neovide/blob/master/src/window.rs#L295 Which gets us part of the way there, but clearly not all the way.

[Kethku]

@Proximyst could you run neovide with --log and upload the logs after reproing the error?

[iwikal]

I made this comment after browsing the source of this AUR package https://aur.archlinux.org/packages/neovide/ which as of yesterday still did use winit.

After switching to the git master version, most of the keyboard issues disappeared. Still can't use AltGr, but everything else I tried worked!

[iwikal]

For reference, I'm using a Swedish keyboard, software mapped like this:

setxkbmap se us_dvorak caps:escape

The issues I experienced were:

• could not use caps lock mapped to escape, in either X11 or Wayland
• shift and control were swapped in normal mode
• AltGr + 2 escaped insert mode, instead of producing @ (still happens)

[Kethku]

Any idea how to get the AUR package updated?

[Nemo157]

There are two AUR packages, that one tracks releases while neovide-git tracks the master branch.

[iwikal]

Looks like it was updated yesterday. Maybe it's already fixed!

[Kethku]

Hrmm. Well until I get a concrete idea of who is managing that, I'm going to remove it from the readme

[Kethku]

I think at this point all of the issues except the alt gr one are fixed so I'm going to change this issue to track that instead.

[Proximyst]

@Kethku Here's me opening neovide, entering i, (log start) pressing right shift + < to make > (log stop), and then just ^C-ing in git bash: https://gist.github.com/Proximyst/f504af4a386689caf4e96412bb07df8f#file-neovide_rcurrent-log-L371-L386

This still creates < in the editor, making the program 100% useless for my daily use of Rust :/

[iwikal]

@Proximyst did you built the latest git master?

[Kethku]

Agreed. That sounds like a bug thats already been fixed.

[Proximyst]

@iwikal Yes, it was the latest when I tried it; I got it from the CI on the latest commit.

[Kethku]

Very weird. https://github.com/Kethku/neovide/blob/master/src/window.rs#L127-L159 is where we handle the raw window input events, and https://github.com/Kethku/neovide/blob/master/src/bridge/keybindings.rs is where we turn those events into text input commands for the neovim process. Want to do some investigation? I'm at a loss at this point because I can't repro your error.

[mewhhaha]

I'm on Windows and on my Swedish keyboard I also have problems with Alt Gr characters as well as pressing shift + < to get >. However, I have the same problem with Alt Gr in normal nvim on Windows.

In NeoVide I made them work by rigging it so that they'd return early in handle_key_down. For Alt Gr I made a special case comparison for it, which on my machine were the bits 0x0240. For > I saw that lt and gt return special=true in parse_keycode and therefore wouldn't return at (will_text_input && !special). Making them return special=false instead works for being able to output > with my shift buttons. I'm not very well versed in SDL, Vim or NeoVide so I don't know how much these workarounds break things. I also tried this on a Linux machine where I had similar problems but didn't have time to look further into it if it was an identical issue. I only know that I can at least do Alt Gr characters in nvim on Linux. I don't know if this information is helpful, but I think this is a very cool project and I'd love to be able to use it. :mango:

[Kethku]

Very interesting! Can you create a PR with those changes so that I can review and chat about it there? Thanks so much for the investigations!

[mewhhaha]

Sure! I opened a draft #183.

[Kethku]

This is now fixed. Thanks @mewhhaha!

[mewhhaha]

I've tested it now on my Linux machine and it seems that it treats Alt Gr differently than on Windows. While Windows registers RALTMOD and LCTRLMOD it seems that on Linux it's just RALTMOD. Perhaps it'd be better to just consider RALTMOD as Alt Gr. I also saw there were issues with https://github.com/Kethku/neovide/issues/186 :cry:. Maybe it'd help to just consider RALTMOD?

[Kethku]

I've been doing some thinking. The real struggle here is that we are attempting to predict when the text input event will fire from the key pressed event. I did some logging and Im pretty sure that text input and keypressed will always happen in the same event group.

So instead of handling those in the event handler I'm going to store the results of those events in variables and then handle the results together using the key-pressed event as fallback.

This leaves only the issue of when key pressed events aren't sufficient and the text input fails. right now there is an issue reporting that which isn't correct. This is because text input doesn't produce values when modifiers are pressed. For this issue I'm at a loss. I don't know how to in a multiple keyboard layout compatible way convert modified key codes into the correct format

_{Sent with GitHawk}

[Kethku]

Reopening as the solution wasn't fully correct

[Kethku]

I don't have a solution for the second issue in the above comment besides hand writing out a mapping of various popular keyboard layouts. So my solution is going to be to build a way to configure mappings manually and provide a default set of keyboard layouts which I can have users configure in their initialization scripts. As far as I can tell there is no way around this with the input mechanisms available in sdl2.

I will also look into adding back a compile option for winit since at the moment they are fairly equivalent. This way if winit improves in the future we will be able to just swap back easily.

I have posted a question regarding this issue here: https://discourse.libsdl.org/t/textinput-event-modifiers/27326
However I haven't gotten a response :l

[Kethku]

That said, I believe the altgr part of this issue is now fixed.

[mewhhaha]

https://github.com/Kethku/neovide/commit/04773807cba0f6fd3843644a95ee6b0b54c996b7

This commit made it so AltGr keys no longer work on Linux. It still works on Windows, though.

[Catvert]

Hey ! I've got into the same issue, the altgr key not working on Linux.

[juho-p]

I have the same problem and it's probably the only thing that prevents me from using Neovide now. I tried to do some keyboard code tweaking regarding this issue myself and based on the API documentation and online discussion I concluded that SDL isn't unfortunately suitable library for handling international keyboard input for vim like editor (sorry for totally useless conclusion, since Kethku already knows much more than me about this issue based on the discussion on this thread).

I think is that it's very hard to detect AltGr with SDL correctly, since SDL think's its left alt key. For example, X11 SDL keyboard code just maps it to RALT: https://github.com/SDL-mirror/SDL/blob/master/src/video/x11/SDL_x11keyboard.c#L136 (of me, AltGr produces X11 code XK_ISO_Level3_Shift and not XK_Alt_R). Probably similar thing happens in Windows. For Neovide, it would be best if SDL wouldn't report AltGr as modifier at all, since it only should affect text input and not work as modifier. Of course, gaming would have different requirements, so I kinda understand SDLs way here.

I also wondered how alacritty project handles such things. It's cross platform project (Windows, Linux, Mac) which has similar requirements to Neovide regarding windowing (I think). I didn't dig very deep, but It seems to use glutin and there's also some #[cfg to check the platform: https://github.com/alacritty/alacritty/blob/master/alacritty/src/window.rs . Maybe glutin would work for Neovide as well? Not sure about it's Vulkan support though.

And if you decide to add compile option for winit, I'd be glad to try it out and play around with it. Even though the end result might be (currently) buggy. I suspect at least the AltGr is handled better (or maybe it's wishful thinking?).

[juho-p]

I did some testing with old winit version of Neovide. I tried ReceivedCharacter, as @iwikal suggested in a comment for this issue before. It might have been as easy as that (almost, just need to encode '<' for nvim.

I put my attempt of these changes here (branched off from 0.4.0 tag): https://github.com/juho-p/neovide/tree/try-to-fix-keyboard-from-old-winit-version
Diff: https://github.com/juho-p/neovide/compare/0.4.0..try-to-fix-keyboard-from-old-winit-version

I'm not that familiar with neovim internals that I'd know why this works, but it seems neovim actually tries to make sense of many kinds of inputs. For example, on my branch, I tried to type following (in vim terms):
ifoo<Esc>obar<C-c>o\<C-g> (I have C-g mapped to in my vim config, to explain the last thing. Also \ is behind AltGr for me, so I wanted to test that as well)

This actually sends following to neovim (I added some println!("DEBUG: sending command {:?}", command); to see what happens):

DEBUG: sending command Keyboard("i")
DEBUG: sending command Keyboard("f")
DEBUG: sending command Keyboard("o")
DEBUG: sending command Keyboard("o")
DEBUG: sending command Keyboard("\u{1b}")
DEBUG: sending command Keyboard("o")
DEBUG: sending command Keyboard("b")
DEBUG: sending command Keyboard("a")
DEBUG: sending command Keyboard("r")
DEBUG: sending command Keyboard("\u{3}")
DEBUG: sending command Keyboard("o")
DEBUG: sending command Keyboard("\\")
DEBUG: sending command Keyboard("\u{7}")

Those \u{some code} ("\u{1b}" instead of <Esc>, etc) things were not something I would have thought to work, but actually neovim can understand them. Everything I tried regarding keyboard works as I wanted. I tested this in Linux. I don't know if it would work on Windows.

[juho-p]

To glarify on my previous comment: That branch I created is not practical, since it is based on _ancient_ version of Neovide, but I think it shows that there is some hope regarding using winit as a solution for neovim GUI (at least for keyboard input).

[juho-p]

I played around with the code and managed to change the current master version to use winit instead of SDL: https://github.com/juho-p/neovide/commits/neovide-on-winit

This version seems to work very well for me, though I didn't test it very throughly yet so maybe I missed something obvious. Also, it's missing some window settings stuff. I didn't get setting window title and transparency to work with winit. Keyboard works just fine though, and there is no special cases needed for different layouts. Again, this is the case in Linux. I don't know if it works on Windows, for example.

Unfortunately, it doesn't probably make pull request to you based on this current version since because of those missing window configs and that winit vs. SDL thing is not at all configurable there since I just removed all the SDL code and replaced it with winit.

Edit: I tried this a bit more, and many things don't work regarding keyboard in my branch: arrow keys, page up/down, home, end, insert, del, function keys. Conclusion: my branch doesn't really work unfortunately. On the other hand, winit seems to be better than SDL regarding keyboard input. ReceivedCharacter gives pressed keys even if ctrl is pressed and it transfers them to standard ascii codes that work similar to what terminal neovim does. I'll try again later if I can get something working.

Edit again: I added those missing keys and handling alt-modifier to my branch and now it seems pretty similar to what it is in terminal neovim regarding keyboard functionality.

[Kethku]

I am reading these and thinking about them. Sorry for not responding sooner.

Getting winnit support back in is definitely a priority. Unfortunately I believe there are still lurking bugs in winnit that mean we need to keep the sdl windowing system around, so if I'm going to land that support it will have to be in a configurable way. Probably via a compile time feature.

I want to long term swap to straight winnit as it has become clear to me that the sdl folks don't really consider normal desktop apps to be their target audience. Some features will never land properly if we just used sdl2. Plus I don't like that it isn't rust first ;)

The issues highlighted above are highly complicated and require balancing multiple sometimes conflicting requirements. So it may take me some time to page it all back in and see if winnit (or my understanding of the input requirements) have improved at all since last time we tried.

[Kethku]

Something I am remembering from the last time I went down this path is that some platforms allow ctrl in receivecharacter while others don't :l So I had to do a hybrid approach similar to the input handling that exists today. Its possible (I hope) that they have fixed this since then though, so I'm very interested in trying again. The dpi handling in Winnit was vastly better so that would fix a bunch of other open issues

[juho-p]

Yes, in my branch the idea is to not check ctrl (and shift, and altgr) at all for ReceiveCharacter, because the character is some ASCII code that comes from ctrl+key combination. But this might be something UNIX or Linux specific thing done by Winit (I didn't try to figure out what exactly is happening). I think I'll try to test this in Windows 10 machine soon. Interesting to see what happens.

[juho-p]

Ok I managed to compile this on Windows (had to install 5GB of MSVC stuff, but it works!), and yeah, winit ReceiveCharacter works a bit different in Windows compared to Linux. Some basic stuff in my git branch works, like and is the same, but for many other cases it's not so good story. So basically, if using winit, I think the only way forward with current winit version would be to have different implementations for Windows and Linux (I'd guess that Mac works the same asa Linux here, but can't test it). Or maybe you could test if ReceiveCharacter is some ASCII control code and have logic based on that. Only now I start to see how deep keyboard this rabbit hole is, at least with multiple platforms. Not so easy.

[yngman]

As detailed in issue #27 (specifically here), AltGr is handled via sending <M-key> to Neovim iff the user had to use AltGr to generate key. For unfortunate European keyboard users, this means that hitting i<AltGr-+> does not generate a mere \, nor even a +, but unexpectly exits insert mode. Hitting i<C-v><Altgr-+> shows <M-Bslash> which clearly is not mapped.

After trying for an embarrassingly long time to make X11/Wayland (on Ubuntu 20.04) somehow "drop" the Alt-part of the AltGr keystroke, or using set winaltkeys to somehow ignore fancy non-terminal key support, I ended up just pasting the following into my .vimrc:

~vim
set winaltkeys=yes
for s:char in split('¶¡@£$€¥{[]}\±{}þ←đŋ©®ł¸~最↓→ðħŧłß̣̣̣´|·@©ĸ»”µł“«', '\zs')
if s:char == '\'
let s:expr = 'imap '
elseif s:char == '|'
let s:expr = 'imap '
else
let s:expr = printf('imap %s', s:char, s:char)
endif
exec s:expr
endfor
~

This generates insert-mode maps for all the <M-key> → key I could generate, including | and \. However, is this the expected way to handle this? It seems awfully local and had to actively stop myself from looping over all conceivable characters to "support" any layout.

I noticed in running neovide --log that Mod::RALTMOD is detected correctly and (importantly) separately from Mod::LALTMOD (my Alt not labeled "AltGr"). Even if I relied heavily on Meta mappings (see e.g. #186), I personally can not see the utility in mapping left & right Alt separately, nor can I at the moment with both being <M-key>, and thus would like a g:neovide_layout_options or something that sends <M-key> for Mod::LALTMOD but just mere key for Mod::RALTMOD. Ideally, equivalently for Shift+AltGr since that 4th layer is of great convenience on Linux in non-terminal applications; e.g. Shift+AltGr+* for U+00D7 (×) and Shift+AltGr+2 for U+00B2 (²).

I thus started trying to separate mod.rs:100 and extend the append_modifiers for some KeyBoardlayout::Qwerty setting or something, but at this point I realized that I'm too inexperienced in Rust and I haven't even tried remapping in my .vimrc… which worked just fine!

Is this something to consider? The expected behaviour for AltGr-support in my (local) experience is not to treat it as a 2nd Alt-key, but to pretend the target character was input (with another layer for Shift-AltGr). That's why it's labelled "AltGr" and not a second (right) "Alt", right? For reference, the layout of the household is setxkbmap se dvorak caps:escape.

[monofon]

@yngman you made my day. Also works under macOS on a MacBook Pro with german QWERTZ
keyboard.

[Kethku]

@yngman sorry for not getting to you sooner. Unfortunately I'm completely in the dark when it comes to the right choices here. I don't have a good feel for what expected behavior is and as mentioned above it appears that winit acts differently on different platforms.

I believe this is something that should be resolved with them because I would LOVE it if we could just use receive character like suggested above, but today it doesn't work correctly.

Your input remap fix is interesting, but I'm not sure I understand it. If you think its general enough to add to the keyboard layout system that seems like a good strategy because then we can just tell users to set the keyboard layout setting variable to the correct value and things should just work until we can get winit to act consistently.

Thanks for the great investigation regardless. I really appreciate it!

[clason]

@yngman (@monofon) Thanks, that does fix the problem for typing in the buffer, but apparently not in the command line -- I still can't enter :e ~/Documents etc....

EDIT On the other hand (without this fix), AltGr keys (\, {, etc. on a German layout) _do_ work on the command line.

[mborejdo]

I am also experiencing this problem on german keyboard-layout on Windows. Unfortunately the workaround does not work for me.

[guillaume-tessier-cbp]

Got the same problem with Neovide on Windows 10.
I found a trick to overcome this issue.

I read this and remapped key strokes that would not work properly.

For exemple, if backslash does not work:

1- go insert mode
2- type <Ctrl-V> followed by the key stroke of backslash (<ALTGr-8> on a french keyboard).
3- this would output something like <M-C-\> (for backslash)
4- edit your init file and add: imap <M-C-\> \

You can remap the others non working key the same way:

imap <M-C-\> \
imap <M-C-[> [
imap <M-C-]> ]
imap <M-C-`> `
" for command mode:
map! <M-C-\> \
map! <M-C-[> [
map! <M-C-]> ]
map! <M-C-`> `

Hint ! : you might have to edit your vimrc with another editor (emacs?) to get those characters 😁

Well, this is just a trick.

[lafleurdeboum]

@guillaume-tessier-cbp your workaround worked for me too ; using the following bindings in ~/.config/nvim/init.vim for my french keyboard under Arch linux, latest neovide-git installed :

" neovide doesn't load ginit.vim, setup it here :
if exists('g:neovide')
    " Workaround SDL2 AltGr keys not properly read :
    " See https://github.com/Kethku/neovide/issues/151#issuecomment-682123519
    imap <M-~> ~
    imap <M-#> #
    imap <M-{> {
    imap <M-[> [
    imap <M-Bar> \|
    imap <M-`> `
    imap <M-\> \
    imap <M-^> ^
    imap <M-@>
    imap <M-¤> ¤
    imap <M-}> }
    imap <M-]> ]

I think this mapping is exhaustive for french PC-compatible keyboards. I can tell by experience that those keys are mapped to completely different keystrokes under Mac hardware with a french keyboard.

What I don't get is how on earth do we get the right characters in command mode ? Is the input method different ?

[Kethku]

closing in favor of https://github.com/Kethku/neovide/issues/445

[marcospb19]

The name of the new issue may be misleading.
I'm using Qwerty, but br-abnt2-Qwerty (setxkbmap br abnt2) and not us-Qwerty.

Here is some unnecessary context:
abnt2 is one of the variations of brazilian portuguese keyboards (I guess the other ones are super old, cause I never saw somebody using them).

Here are some alternative ways of typing / and ?.
AltGr + q => /
AltGr + w => ?
I only use these combinations instead of typing / or ? with the ""correct"" keys, because different keyboards change the locations of those (they still br-abnt2 tho), sometimes it is the only way to type them, with AltGr.

(Both sadly exit to the normal mode in neovide).

---

But we are using Qwerty keyboard layouts :slightly_smiling_face:.

[Grzanka99]

Neovide it's still unusable with polish characters... can't insert any polish letter like ą for example. When you planning to fix that issue?

[marcospb19]

@Grzanka99 check #445