If you've been using a terminal for a while, you've surely stumbled across the terminal's legacy keyboard handling. Terminal escape codes were created in the 1970s and haven't been updated much.<\/p>\n\n\n\n
CTRL + J == newline\nCTRL + I == tab<\/code><\/pre>\n\n\n\nThese two examples are some of the least annoying, but the implications aren't at first obvious. Normal terminal apps can't tell whether you actually typed \"ENTER\" on your keyboard or \"CTRL\" + \"I\". From the perspective of the app, it's the same. Sadly, that's just the tip of the iceberg for these limitations.<\/p>\n\n\n\n
CTRL + ... Sequences starting with CTRL+... are basically used up by the way the terminal represents common data (CTRL + D == EOF) with \"CTRL CODES\", and CTRL+SHIFT+letter is the same as CTRL+letter<\/p>\n\n\n\n
ALT + C might be encoded as 0xc3, which collides with UTF-8 for characters like: \u00c3\u00a9.<\/p>\n\n\n\n
SHIFT + ... The terminal doesn't know the difference between \"Shift + s\" and \"S\"...<\/p>\n\n\n\n
Hyper +... Hardly any apps are cool enough to be able to work with the awesome hyper modifier... Without an enhanced way to process keycodes, this isn't possible.<\/p>\n\n\n\n
Many terminals rely on timing to distinguish codes like Alt+C from Esc + C... This generates lag and errors when typed too slow or too fast. vim-fixkey has a nice list of workarounds<\/a> to get full access to keypresses in the terminal, though even in the best case scenario, it would be limited by a timeout, and not work for Cmd, Hyper or various CTRL+x keys...<\/p>\n\n\n\n
\n\n\n\nFortunately Leonerd, the author of libtermkey<\/a> (now replaced by libtickit<\/a>), wrote the \"fixterms<\/a>\" specification and the author of Kitty has extended the fixterms<\/a> spec to cover Super, Hyper and other modifier keys. iTerm 2 is also being extended<\/a> to cover the new Kitty version of the fixterms spec.<\/p>\n\n\n\nSome of this is \"worked around\" with the XTerm ModifyOtherKeys<\/code> option that's also supported in gnome-terminal and Konsole. Unfortunately ModifyOtherKeys is not complete.<\/p>\n\n\n\nThere is discussion on the NeoVim github issues about adding fixterms support in neovim, but at this time (Nov 2021) it seems that no support is yet complete. It looks like neovim\/src\/nvim\/keymap.c<\/code> probably holds most of the code that needs to change.<\/p>\n\n\n\nhttps:\/\/github.com\/neovim\/neovim\/blob\/dc4670038e0441dfda7ba11c519b834624a1f6fd\/src\/nvim\/keymap.c#L748-L755<\/a><\/p>\n\n\n\nFix ambigous terminal key strokes? https:\/\/github.com\/neovim\/neovim\/issues\/176<\/a><\/p>\n\n\n\nSomeone may have worked on an actual code change for this, tracking at: https:\/\/github.com\/neovim\/neovim\/issues\/6279 <\/p>\n\n\n\n
TUI: enable\/disable modifyOtherKeys automatically https:\/\/github.com\/neovim\/neovim\/issues\/15352
TUI: distinguish Tab, CTRL-i (S8C1T mode) https:\/\/github.com\/neovim\/neovim\/issues\/5916
CTRL-Alt-Space isn't recognized even though terminal sends ^[^@, works in Vim https:\/\/github.com\/neovim\/neovim\/issues\/14836<\/p>\n\n\n\n
Binding <M-S-Tab> https:\/\/github.com\/neovim\/neovim\/issues\/2379<\/p>\n\n\n\n
TUI: S8C1T (8-bit) mode, v:termresponse https:\/\/github.com\/neovim\/neovim\/issues\/6279<\/p>\n\n\n\n
See: \"xterm-8-bit\" Nvim does not use 8-bit sequence detection, and always uses 7-bit sequences (for now)<\/p>\n\n\n\n
One day, hopefully Neovim will support these sequences by default, but in the mean time it's possible to map these sequences manually in Kitty and Neovim, it's possible to manually use a specific mapping by configuring Kitty's map ... send_text<\/code><\/p>\n\n\n\nhttps:\/\/github.com\/kovidgoyal\/kitty\/issues\/3248<\/a><\/p>\n\n\n\n# In Kitty.conf Example\nmap ctrl+enter send_text normal,application \\x1b[13;5u\n\n# In init.lua\nvimp = require('vimp')\nvimp.bind('n', '<C-cr>', ':echom \"Hello C + R\"<CR>')\n<\/code><\/pre>\n\n\n\nRemember, the Kitty chart for progressive enhancement is:<\/p>\n\n\n\n