Installation not quite right?

sudo tic -x -o /lib/terminfo/x/ ~/kitty-terminfo/terminfo/xterm-kitty-256color.ti

This created the the file in /lib/terminfo/x/x/xterm-kitty-256color (an extra directory level).

infocmp -xT $TERM

Didn't have the expected result as I hadn't reconnected using the new Terminal-type string at that point.

P.S. Thank you for writing this; my previous workarounds for making PuTTY behave acceptably did not work on Ubuntu 18. Using KiTTY + your recommended settings made it all usable. Though – try as I might – I still can't get Vim to see Shift + arrow keys.

Thanks for pointing these out! In regards to Vim - assuming you're running appropriate terminfo settings both on server and client (which should be KiTTY) - should recognize shift+arrows and jump between words. Are you using tmux with it?

I am using KiTTY and, unlike PuTTY it definitely sends all the sequences; testing with cat shows unique escapes for arrow keys alone and every combination Shift, Alt, and Ctrl, again in and out of tmux. I know Vim can receive them, too as Ctrl + V then Shift + up in insert mode prints the same sequences, it just doesn't respond to that in normal mode.

The arrow key defs don't match for me. In cat without tmux, pressing up, down, left, right then Shift + … gives me this:

^[[A^[[B^[[C^[[D^[[1;2A^[[1;2A^[[1;2C^[[1;2D

So the Shift + … combos match but your terminfo file has the unmodified keys as this:

kcuu1=\EOA, kcud1=\EOB, kcuf1=\EOC, kcub1=\EOD,

Which match smkx mode. Why is that?

I have been trying a modified version:

diff --git a/terminfo/xterm-kitty-256color.ti b/terminfo/xterm-kitty-256color.ti
index 2571173..e68e525 100644
--- a/terminfo/xterm-kitty-256color.ti
+++ b/terminfo/xterm-kitty-256color.ti
@@ -67,14 +67,40 @@ xterm-kitty-256color|xterm-style terminfo for KiTTY with 256 colors,
        kb2=\E[G,
        kbs=\177,
        kcbt=\E[Z,
-       kcub1=\EOD,
-       kcud1=\EOB,
-       kcuf1=\EOC,
-       kcuu1=\EOA,
-       kind=\E[1;2B,
+       kcuu1=\E[A,
+       kcud1=\E[B,
+       kcuf1=\E[C,
+       kcub1=\E[D,
        kri=\E[1;2A,
-       kLFT=\E[1;2D,
+       kind=\E[1;2B,
+       kUP=\E[1;2A,
+       kDN=\E[1;2B,
        kRIT=\E[1;2C,
+       kLFT=\E[1;2D,
+       kUP3=\E[1;3A,
+       kDN3=\E[1;3B,
+       kRIT3=\E[1;3C,
+       kLFT3=\E[1;3D,
+       kUP4=\E[1;4A,
+       kDN4=\E[1;4B,
+       kRIT4=\E[1;4C,
+       kLFT4=\E[1;4D,
+       kUP5=\E[1;5A,
+       kDN5=\E[1;5B,
+       kRIT5=\E[1;5C,
+       kLFT5=\E[1;5D,
+       kUP6=\E[1;6A,
+       kDN6=\E[1;6B,
+       kRIT6=\E[1;6C,
+       kLFT6=\E[1;6D,
+       kUP7=\E[1;7A,
+       kDN7=\E[1;7B,
+       kRIT7=\E[1;7C,
+       kLFT7=\E[1;7D,
+       kUP8=\E[1;8A,
+       kDN8=\E[1;8B,
+       kRIT8=\E[1;8C,
+       kLFT8=\E[1;8D,
        kdch1=\E[3~,
        kend=\E[4~,
        kent=\EOM,

Is there anything wrong with doing that? With application keys mode not disabled as per your recommendation, now all keys are working as expected in bash and vim outside of tmux. What vim gets matches what it expects from looking at :set termcap:

--- Terminal keys ---
t_#4 <S-Left>    ^[[1;2D
t_%1 <Help>      ^[[28;*~
t_%i <S-Right>   ^[[1;2C
t_&8 <Undo>      ^[[26;*~
t_@7 <End>       ^[[1;*F
t_F1 <F11>       ^[[23;*~
t_F2 <F12>       ^[[24;*~
t_K1 <kHome>     ^[[1;*~
t_K4 <kEnd>      ^[[4;*~
t_K6 <kPlus>     ^[O*k
t_K7 <kMinus>    ^[O*m
t_K8 <kDivide>   ^[O*o
t_K9 <kMultiply> ^[O*j
t_KA <kEnter>    ^[O*M
t_KB <kPoint>    ^[O*n
t_PE <PasteEnd>  ^[[201~
t_PS <PasteStart> ^[[200~
t_k1 <F1>        ^[[11;*~
t_k2 <F2>        ^[[12;*~
t_k3 <F3>        ^[[13;*~
t_k4 <F4>        ^[[14;*~
t_k5 <F5>        ^[[15;*~
t_k6 <F6>        ^[[17;*~
t_k7 <F7>        ^[[18;*~
t_k8 <F8>        ^[[19;*~
t_k9 <F9>        ^[[20;*~
t_k; <F10>       ^[[21;*~
t_kB <S-Tab>     ^[[Z
t_kD <Del>       ^[[3~
t_kI <Insert>    ^[[2;*~
t_kN <PageDown>  ^[[6;*~
t_kP <PageUp>    ^[[5;*~
t_kb <BS>        ^?
t_kd <Down>      ^[O*B
t_kh <Home>      ^[[1;*H
t_kl <Left>      ^[O*D
t_kr <Right>     ^[O*C
t_ku <Up>        ^[O*A
     <Mouse>     ^[[M
     <xF1>       ^[O*P
     <xF2>       ^[O*Q
     <xF3>       ^[O*R
     <xF4>       ^[O*S
     <xEnd>      ^[O*F
     <zEnd>      ^[[8;*~
     <xHome>     ^[O*H
     <zHome>     ^[[7;*~
     <xUp>       ^[[1;*A
     <xDown>     ^[[1;*B
     <xLeft>     ^[[1;*D
     <xRight>    ^[[1;*C
     <kDel>      ^[[3;*~

As far as I can see, the only reason modifier + arrow combos are not working in vim inside tmux is because of some kind of deficiency in the termcap; with term of tmux-256color I see fewer capabilities:

--- Terminal keys ---
t_#2 <S-Home>    ^[[1;2H
t_#4 <S-Left>    ^[[1;2D
t_%i <S-Right>   ^[[1;2C
t_*7 <S-End>     ^[[1;2F
t_@7 <End>       ^[[4~
t_F1 <F11>       ^[[23~
t_F2 <F12>       ^[[24~
t_k1 <F1>        ^[OP
t_k2 <F2>        ^[OQ
t_k3 <F3>        ^[OR
t_k4 <F4>        ^[OS
t_k5 <F5>        ^[[15~
t_k6 <F6>        ^[[17~
t_k7 <F7>        ^[[18~
t_k8 <F8>        ^[[19~
t_k9 <F9>        ^[[20~
t_k; <F10>       ^[[21~
t_kB <S-Tab>     ^[[Z
t_kD <Del>       ^[[3~
t_kI <Insert>    ^[[2~
t_kN <PageDown>  ^[[6~
t_kP <PageUp>    ^[[5~
t_kb <BS>        ^?
t_kd <Down>      ^[OB
t_kh <Home>      ^[[1~
t_kl <Left>      ^[OD
t_kr <Right>     ^[OC
t_ku <Up>        ^[OA
     <Mouse>     ^[[M

It doesn't seem to matter whether I use your terminfo version or my patched one, the modified arrow keys aren't recognised once vim's inside tmux.

For me, in cat without tmux, on my version of terminfo, I get exactly the same codes as you mentioned: ^[[A^[[B^[[C^[[D^[[1;2A^[[1;2B^[[1;2C^[[1;2D

When it comes to terminfo definitions - kcuu1=\EOA, kcud1=\EOB, kcuf1=\EOC, kcub1=\EOD, - these indeed are listed as terminal arrow keys - however, those are representing the key code sent by numpad without numlock on (smkx mode). Properties cuu1, cud1, cuf1, cub1 which are defined by various sources as "cursor up/down/right/left" respectively, are the normal behavior that we expect from arrow keys under function cluster (normal mode). There's also this

When it comes to tmux, there's this source and it somewhat lines up with what i have in my own .tmux.conf that I didn't end up putting in the repository, even though I included xterm-kitty-256color.ti:

set-window-option -g xterm-keys on

This should solve tmux not behaving properly.

Now, the main thing. I apologize as I porobably should have put this information in the readme in the first place. You also asked if there's anything wrong with editing terminfo... Well, as far as I understand it, terminfo files are supposed to describe capabilities of your terminal and the raw key codes it sends - the key word here being 'raw'. With all the default configuration files present in various places belonging to different libraries etc already containing some default definitions, there are high chances that they're being overwritten along the way to the program, on top of terminfo not matching the terminal. Then comes along some program that uses different libraries or uncommon features (like tmux) and everything starts falling apart for seemingly no reason, and no amount of messing with its config files make it any better. These libraries (readline and ncurses) are used by bash and they influence the output, and they were written with a real terminal and hardware in mind - terminal emulator is a big difference (hence the existence of smkx mode which emulates numlock being on and off, since remote machine has no access to the state of your hardware). However, cat displays raw codes your KiTTY sends with no subsequent modifications by any libraries, which only makes it more confusing as other programs are receiving something completely different than you just saw. To make it even more confusing, default config files often contain conditional expressions that change system's behavior based on terminfo name or its values, making even bigger mess.

So (again as I understand it) the terminfo comes first as you're probably not going to modify neither KiTTY source nor readline or ncurses sources to suit your needs and behave better (unfortunately fixing this would require cooperation of several different package dev teams beyond just KiTTY devs, would break backward compatibility, and it's simply not going to happen); only after that works as expected you can start messing with settings of various applications to make them behave the way you want them to, respond to actual unmodified key codes being sent by your terminal, and customize them to your liking. Both tmux and vim have appropriate config files and functionality to make this happen, so that's what I stick to and I recommend everyone else does as well. That said, I think you should back up you current settings just in case, stick to the terminfo file I provided in repository, and most importantly carefully check your readline config files located at /etc/inputrc, ~/.inputrc, and shell variable INPUTRC (docs) (iirc default readline /etc/inputrc config file overwrites normal mode keys with smkx variants, but cannot confirm it now), and your bash startup files as all of those may contain definitions that override either your settings in some way or the terminfo you're using. This is my only guess on the cause of your problem at the moment. For me it works because my config files are blank in regards to terminfo/key-assignments/key-code-rewrites, with exception of .tmux.conf (pure functionality rebinding + default term setup mentioned in readme + the xterm-keys on option mentioned above) and my /etc/inputrc:

set input-meta on
set output-meta on
$if mode=emacs

# mappings for Ctrl-left-arrow and Ctrl-right-arrow for word moving
"\e[1;5C": forward-word
"\e[1;5D": backward-word

$endif

So in my case raw keycodes are being sent by KiTTY to programs without anything else messing with it along the way, and I am relatively sure that they are correct (no issues in over 2 years). Locale settings are also going to severely break this (different regional physical keyboards send different key codes based on their layout etc), which is why I recommend setting en_US.UTF-8 as default, and making sure your local OS knows what kinds of keyboard layout you're using.

In the end, my own knowledge on this doesn't extend as far as is probably necessary to be 100% sure what's going on in the background in every single case, so if you find something that does work better, let me know! ;)

...by the way, vim does not support shift key at all it seems - [1] [2 in comments] - but I wasn't able to find more reliable source.

however, those are representing the key code sent by numpad without numlock on (smkx mode).

When I use my actual numpad in cat with num lock off, I get the same ^[[A type sequences, not the ^[OA type ones.

Properties cuu1, cud1, cuf1, cub1 which are defined by various sources as "cursor up/down/right/left" respectively, are the normal behavior that we expect from arrow keys under function cluster (normal mode).

But in your terminfo you have cuu1=\E[A, cud1=^J, cuf1=\E[C, cub1=^H, a linefeed and a backspace, not arrow keys?

There's also this

But KiTTY does support those modes, right? So what does that thread mean for KiTTY's terminfo?

When it comes to tmux, there's this source … This should solve tmux not behaving properly.

I came across that, too. I will give it a try.

stick to the terminfo file I provided in repository, and most importantly carefully check your readline config files located at /etc/inputrc, ~/.inputrc, and shell variable INPUTRC … So in my case raw keycodes are being sent by KiTTY to programs without anything else messing with it along the way

My /etc/inputrc is pretty vanilla with nothing that looks like up/down arrow key codes, and the latter two don't exist for me. So you're saying that even though when I press Ctrl + V then Shift + up in insert mode in vim inside tmux and see the sequence I expect, vim is receiving something else in normal mode?

I recommend setting en_US.UTF-8 as default

Not en_US but still UTF-8 and a US keyboard, don't think that's it.

...by the way, vim does not support shift key at all it seems - [1] [2 in comments] - but I wasn't able to find more reliable source.

I think it does as Shift + up/down effects page up/down inside vim (outside of tmux) and vim's help docs mention many Shift + sequences, type :h <S- and hit Tab to see all the topics.

Thanks for the detailed response. Clearly I have plenty of learning to do.

Using set-window-option -g xterm-keys on made it worse as then cat inside tmux produced the same sequence (^[[1;2A) for both Shift + up and down. I reset the arrow keys to your sequences and kept the extras:

diff --git a/terminfo/xterm-kitty-256color.ti b/terminfo/xterm-kitty-256color.ti
index 2571173..b622ad6 100644
--- a/terminfo/xterm-kitty-256color.ti
+++ b/terminfo/xterm-kitty-256color.ti
@@ -67,14 +67,40 @@ xterm-kitty-256color|xterm-style terminfo for KiTTY with 256 colors,
        kb2=\E[G,
        kbs=\177,
        kcbt=\E[Z,
-       kcub1=\EOD,
+       kcuu1=\EOA,
        kcud1=\EOB,
        kcuf1=\EOC,
-       kcuu1=\EOA,
-       kind=\E[1;2B,
+       kcub1=\EOD,
        kri=\E[1;2A,
-       kLFT=\E[1;2D,
+       kind=\E[1;2B,
+       kUP=\E[1;2A,
+       kDN=\E[1;2B,
        kRIT=\E[1;2C,
+       kLFT=\E[1;2D,
+       kUP3=\E[1;3A,
+       kDN3=\E[1;3B,
+       kRIT3=\E[1;3C,
+       kLFT3=\E[1;3D,
+       kUP4=\E[1;4A,
+       kDN4=\E[1;4B,
+       kRIT4=\E[1;4C,
+       kLFT4=\E[1;4D,
+       kUP5=\E[1;5A,
+       kDN5=\E[1;5B,
+       kRIT5=\E[1;5C,
+       kLFT5=\E[1;5D,
+       kUP6=\E[1;6A,
+       kDN6=\E[1;6B,
+       kRIT6=\E[1;6C,
+       kLFT6=\E[1;6D,
+       kUP7=\E[1;7A,
+       kDN7=\E[1;7B,
+       kRIT7=\E[1;7C,
+       kLFT7=\E[1;7D,
+       kUP8=\E[1;8A,
+       kDN8=\E[1;8B,
+       kRIT8=\E[1;8C,
+       kLFT8=\E[1;8D,
        kdch1=\E[3~,
        kend=\E[4~,
        kent=\EOM,

The deletions are only re-ordering mappings, it is effectively only additions. Now cat inside tmux is showing all modifier sequences again.

Since the terminfo for tmux-256color already has all those extra modifier sequences, I expect I'll be able to rely on them. Adding config as below to .vimrc restores key combinations:

if match($TERM, 'tmux') != -1
    set <S-Up>=^[[1;2A
    set <S-Down>=^[[1;2B
    set <S-Right>=^[[1;2C
    set <S-Left>=^[[1;2D
    set <C-Right>=^[[1;5C
    set <C-Left>=^[[1;5D
endif

When I use my actual numpad in cat with num lock off, I get the same ^[[A type sequences, not the ^[OA type ones.

But KiTTY does support those modes, right? So what does that thread mean for KiTTY's terminfo?

Yes, KiTTY does support those modes, just as putty does. The point why I linked it is it specifically mentions which properties are meant for which mode. The sequences your kiTTY sends are correct. Remote machine has no access to your numlock status, and kiTTY does not send it - there is no way to send it as far as I know. Programs from the other side can send smkx sequence to enter keypad mode, which forces KiTTY to switch codes it sends by pressing arrow keys. After that remote machine can send rmkx sequence is exit numpad mode, forcing KiTTY to switch back to normal. There's still probably something to fix in terminfo in that regard though.

But in your terminfo you have cuu1=\E[A, cud1=^J, cuf1=\E[C, cub1=^H, a linefeed and a backspace, not arrow keys?

Explained here. I constructed xterm-kitty-256color based on vanilla xterm and putty, and where the sequences with those "speed hacks" didn't cause me any troubles, I left them in as-is.

My /etc/inputrc is pretty vanilla with nothing that looks like up/down arrow key codes, and the latter two don't exist for me.

Can you paste it? Both /etc/inputrc and ~/.inputrc if the latter exists.

So you're saying that even though when I press Ctrl + V then Shift + up in insert mode in vim inside tmux and see the sequence I expect, vim is receiving something else in normal mode?

Yeah. In my understanding, Ctrl+V enters escape character immediately upon pressing the combination, then pastes in raw keycode of the next key or key combination you press; cat echoes raw key sequences that remote machine received with escape character included; both seem to do that without passing it through readline or other libraries that may modify it. I wasn't able to prove otherwise, and it lines up with what's been happening in my terminal. If you can provide any source where the process is different or exactly described, that would be helpful to explain what's really going on.

I think it does as Shift + up/down effects page up/down inside vim (outside of tmux) and vim's help docs mention many Shift + sequences, type :h <S- and hit Tab to see all the topics.

Adding config as below to .vimrc restores key combinations:

I will try those and see what happens then.

Thanks for the detailed response. Clearly I have plenty of learning to do.

As do I :D I was kind of tumbling in the dark with this, and I kind of still am. I am no expert on this by any means.

my vim, with no additional config, shows this on :set termcap :

--- Terminal keys ---
t_#4 <S-Left>    ^[[1;2D   t_K8 <kDivide>   ^[O*o     t_KJ <k7>        ^[O*w     t_k7 <F7>        ^[[18;*~  t_kh <Home>      ^[[1;*H        <xHome>     ^[O*H
t_%1 <Help>      ^[[28;*~  t_K9 <kMultiply> ^[O*j     t_KK <k8>        ^[O*x     t_k8 <F8>        ^[[19;*~  t_kl <Left>      ^[O*D          <zHome>     ^[[7;*~
t_%i <S-Right>   ^[[1;2C   t_KA <kEnter>    ^[O*M     t_KL <k9>        ^[O*y     t_k9 <F9>        ^[[20;*~  t_kr <Right>     ^[O*C          <xUp>       ^[[1;*A
t_&8 <Undo>      ^[[26;*~  t_KB <kPoint>    ^[O*n     t_PE <PasteEnd>  ^[[201~   t_k; <F10>       ^[[21;*~  t_ku <Up>        ^[O*A          <xDown>     ^[[1;*B
t_@7 <End>       ^[[1;*F   t_KC <k0>        ^[O*p     t_PS <PasteStart> ^[[200~  t_kB <S-Tab>     ^[[Z           <Mouse>     ^[[M           <xLeft>     ^[[1;*D
t_F1 <F11>       ^[[23;*~  t_KD <k1>        ^[O*q     t_k1 <F1>        ^[[11;*~  t_kD <Del>       ^[[3~          <xF1>       ^[O*P          <xRight>    ^[[1;*C
t_F2 <F12>       ^[[24;*~  t_KE <k2>        ^[O*r     t_k2 <F2>        ^[[12;*~  t_kI <Insert>    ^[[2;*~        <xF2>       ^[O*Q          <kDel>      ^[[3;*~
t_K1 <kHome>     ^[[1;*~   t_KF <k3>        ^[O*s     t_k3 <F3>        ^[[13;*~  t_kN <PageDown>  ^[[6;*~        <xF3>       ^[O*R
t_K4 <kEnd>      ^[[4;*~   t_KG <k4>        ^[O*t     t_k4 <F4>        ^[[14;*~  t_kP <PageUp>    ^[[5;*~        <xF4>       ^[O*S
t_K6 <kPlus>     ^[O*k     t_KH <k5>        ^[O*u     t_k5 <F5>        ^[[15;*~  t_kb <BS>        ^?             <xEnd>      ^[O*F
t_K7 <kMinus>    ^[O*m     t_KI <k6>        ^[O*v     t_k6 <F6>        ^[[17;*~  t_kd <Down>      ^[O*B          <zEnd>      ^[[8;*~

So it was already expecting <S-Left> and <S-Right> without me doing anything.
Setting :set <Left>=^[OZ (so, gibberish, non-existing keycode) has resulted in not being able to use left arrow and weird things happening. After resetting it to proper value, and changing <xLeft> to gibberish, nothing happened, left arrow still works as expected (skips words left, same as ctrl+left), however, actually pressing ctrl+left arrow resulted in entire chunks of text getting deleted. So we know that vim uses <Left> <Right> <Up> <Down> sequences for normal arrows - which line up with smkx mode - while x variants are for ctrl+arrows. In tmux, vim requires additional configuration to know what kind of sequences expect from ctrl+arrows (x variants end up not configured).
Even though it doesn't display that it expects anything from <S-Up> or <S-Down>, it still skips entire screens up and down in response to shift+up/down. In tmux shift+up/down does not behave the same as outside tmux, only after setting up proper <S-Up> and <S-Down> sequences is stars behaving as expected.
Even though it expects <Home>=^[[1;*H - it still behaves correctly when the key is pressed, even though the key sequence (^[[1~) does not match. It expects <xHome>=^[[1;*~ keypress, but the key sequence does not match up again. Changing any of them has no effect on vim behavior. As far as I know, KiTTY entirely ignores shift/ctrl/alt+home (as well as other function keys), as I don't get a sequence even when using ctrl+v or cat. Assuming x* variant for function keys does the same as for arrows - expecting ctrl modifier - <xHome> will never get triggered.
So I have a hard time accepting that what vim displays with :set termcap is entirely correct, there are some discrepancies. Another thing to dig deeper into.
Conclusion: Vim's <S-Up> <S-Down> <S-Left> <S-Right> sequences matter for tmux shift+arrow keys.
Vim's <Up> <Down> <Left> <Right> correspond to smkx mode sequences, and use the same sequences both outside as within tmux.
Vim's <Home> and <xHome> (and by consequence other function keys) are still a mystery, but keys itself seem to work for me without any problem, both outside and within tmux.

SO! For vim, smkx mode sequences need to be set correctly in terminfo (as I have left it in xterm-kitty-256color), as this seems to be what a lot of other software expects and it lines up with what I've seen in other terminfo and after some googling around for docs. Furthermore, you can check what sequences kiTTY is sending in smkx mode/application mode by manually switching it with command echo -e "\e[?1h\E=" (only in bash! This is smkx sequence from terminfo). After that, going with cat and pressing arrow keys should display you ^[OA^[OB^[OC^[OC^D - if that's the key sequences you're getting, then what you need to have set in terminfo is

kcub1=\EOD,
kcud1=\EOB,
kcuf1=\EOC,
kcuu1=\EOA,

which is, again, what i have set in xterm-kitty-256color. You return to normal mode manually by doing echo -e "\e[?1l\E>" (rmkx sequence). Your normal mode sequences were already showing up correctly, so if your smkx sequences match up with mine (and there's no reason they shouldn't since we both use KiTTY) the only option left where stuff goes wrong is readline library and its config file /etc/inputrc. Attach it please and let's see what's going on.

By the way, in one of your first replies, you mentioned you're getting
^[[A^[[B^[[C^[[D^[[1;2A^[[1;2A^[[1;2C^[[1;2D
out of cat after pressing "up, down, left, right then Shift + … ". Two codes for shift+up and shift+down are the same. Was that outside of tmux? Accident, or is this still happening?

Yes, as you stated vim does expect the ^[OA type sequences, and I already reverted back to those mappings in my terminfo, so now mine is the same as yours except for the additional mappings. They don't seem to hurt and looking at the full terminfo descriptions, many others have the same mappings.

I agree that vim might know more than it tells us in :set termcap, but I now have better keyboard accuracy than I've ever had before, none of the commands/shortcuts I use are broken.

In tmux, vim requires additional configuration to know what kind of sequences expect

Yes, hence the vim config I pasted above that gets things back to normal for me inside tmux.

The ^[[1;2A^[[1;2A was only happening with xterm-keys on and I haven't noticed any issues with it off.

I'm glad you were able to get it to work then! There's definitely some more digging to be done around the modifier keys, as my terminal isn't reporting all combinations correctly (especially shift+alt+arrows differ from expected values, and I didn't notice before because I never used those for anything).

Thanks again for your help and code. I figured the duplicate mappings were okay as terminfo has them for many types already. e.g. xterm+pcc3.

You're welcome! Duplicate mappings shouldn't be a problem, but it's worth remembering that you have those in case any future trouble crops up. Like xterm-keys, this still bugs me. I think it shouldn't really be affecting arrows that much, but I've stumbled upon documentation that describes kri as down, and kind as up... and other source that decsribes it as reversed (which is how you defined them). It's hard to tell which without testing them as reversed with xterm-keys on, and I suspect in your case of multiple definitions it just matters which definition comes last (or first), and since they're all mixed up you get up arrow doubled somehow.

kri and kind are as you defined them, I just put the mappings in alphabetical order. I think they're correct as ind means index: forward/down; ri means reverse index: backward/up.

Sounds logical. I must've misread it somewhere then, my bad.

Sorry for the confusion.

creidhne-a16i / kitty-terminfo

Installation not quite right? #1