In a non-enUS keyboard layout, Ctrl-Key sequences are still interpreted in enUS

[yatli]

The problem is documented in the code, here:

fvim/input.fs

Lines 277 to 289 in 3472085

	// !!Note from here on, all TextInput-triggering keys should have been filtered.
	// All that survived the purge are either non-textinput-triggering keys, or
	// textinput-triggering keys with non-shift modifier active.
	// The (possibly unwanted) side effect of this approach is the inconsistency
	// between TextInput and modifier-active Key:
	//
	// | en-US kbd sequence | en result (sent to nvim) | de result (sent to nvim) |
	// | ------------------ | ------------------------ | ------------------------ |
	// | z | z | y |
	// | Ctrl-z | <C-z> | <C-z> |
	// | ' | ' | ä |
	// | Ctrl-' | <C-'> | <C-'> |
	//

[yatli]

@VVVFO I believe the dvorak problem is exactly like the "de" case for German layout.
However, we cannot simply capture the textual input and stick modifiers onto it because some non-enUS characters don't even have a control sequence -- <C-ä> does not exist at all.

[hexacera]

Thanks for looking into and documenting this @yatli! I wonder what would happen if you send actually send <C-ä> to nvim? Sounds like ideally nvim should handle it just like any other modifier+key combo, though I tried doing some unicode mappings in my vimrc and only the unmodified ones work, probably because of a restriction of iTerm2. Would it be easier to leave the key mapping stuff to OS and nvim instead of handling them in FVim?

Anyway I'm happy to test out fixes or provide more information if needed, thank you for making FVim!

[yatli]

I'm not familiar with iTerm keyboard input logic but I believe it will be simply ignored.
In a terminal, <Ctrl-Key> maps to a non-printing ASCII key, see: https://www.physics.udel.edu/~watson/scen103/ascii.html , so it's not a combo key represented as "mod+key", but combined into a single key code.

neovim does follow the termcap convention (ctrl-key code is UPPER(key)^0x40) but even if that fails, it will send the not-understood key as a utf8 sequence, which is really nice. (see: src/nvim/keymap.c:L550, trans_special)
Culprit: see src/nvim/mbyte.c:L603, utf_ptr2char, the passthrough is not arbitrary. Only a few code planes are taken care of, and "Does not include composing characters for obvious reasons"

The OSes report keys in two ways:

1. Untranslated key codes (think of enUS) + modifier keys
2. Translated text, but no modifier keys

FVim uses both, to better perceive what's happening. Because sometimes, when modifiers are held, the OS stops reporting translated keys all together. :(

Putting all the factors together into a Cartesian product, and boom, a challenging problem that took me a few years already.

But it is definitely a goal to support keyboards from all the places and I will continue to improve the situation by working on either FVim, neovim or the upstream GUI framework.

[yatli]

Oh and, the ultimate solution is to run a little virtual machine in parallel and when there's a modified key, feed it non-modified version of the "virtual key code" and see what it produces. (joking)