Please submit xterm-kitty terminfo to ncurses database

[z0rc]

As kitty introduced its own terminfo, running ssh from it is getting quite difficult because this terminfo isn't widely available. I'm aware about kitty +kitten ssh solution, but it isn't suitable when you have big amount of remote servers that constantly changing or running automation like Ansible or Kitchen.

Ad-hock solution with compiling terminfo on remote server works, but long-term solution would be submitting xterm-kitty to ncurses. After inclusion this would be automatically picked up by all Linux distributions in some time. Wide adoption would take years, but it's right approach. tmux, st and multiple other terminal emulators went this way. Of course this would require to make xterm-kitty a stable interface, and don't change it frequently.

ncurses accepts contributions in quite old way and doesn't use vcs of any sorts. In order to submit terminfo, please reach out developer as instructed at https://invisible-island.net/ncurses/ncurses.faq.html#report_bugs. More info on terminfo database at https://invisible-island.net/ncurses/#download_database.

[kovidgoyal]

In my experience ncurses upstream is not very responsive (or maybe they just dont like me :). As far as I know most distros already package kitty. If they follow the kitty packaging guidelines they should have a separate kitty-terminfo package which you can simply install on your servers. If not bug your distro kitty package maintainer to create such a package. Alternately if you use ansible/puppet/whatever simply create a rule in them into install the kitty terminfo file into /usr/share/terminfo or ~/.terminfo

That said feel free to try to get the kitty terminfo file included in ncurses, maybe they will listen to you. I will be happy to provide any help/support needed.

[z0rc]

Missing xterm-kitty in ncurses is a show stopper for me. If xterm-kitty is included in ncurses it's safe to assume that it's available everywhere, just like bash is available everywhere. Otherwise, imagine a team of 10 developers and hundred of various server roles, no way that change that satisfies some desktop quirks of single developer would be accepted across the whole infrastructure.

That said I'll reach out ncurses upstream and we'll see, how it goes.

[maximbaz]

Just curious, why kitty +kitten ssh is not suitable for when you have big amount of remote servers? It seems to work fine for me, I simply aliased that command to ssh and forgot about this issue altogether.

[z0rc]

@maximbaz because Ansible, Kitchen and probably other tools, that exec ssh directly, despite your shell configured aliases.

Second issue comes up, when you do kitty +kitten ssh to remote server under one user, then do sudo -i to login as root for example, and get the same issue with missing terminfo again.

Probably there are some other similar cases, that haven't stumbled upon while evaluated kitty. But general unavailability of xterm-kitty requires to much of a hassle when working on remote environments.

[kovidgoyal]

Even if ncurses included the terminfo file today, it would be years before you could be confident of having it available everywhere. But as I said, I am happy to provide any info/support needed to get the terminfo into ncurses.

[kovidgoyal]

So to summarize the ncurses maintainer's response:

1) He does not like kitty's license (I'm happy to change the license of just the terminfo file to CC license, if needed) 2) He does not like kitty TERM variable. This is not going to change as it would break lots of programs that turn on various features when they see a TERM variable of the type xterm-whatever. A situation that was created by the ncurses maintainer refusing to add new capabilities for various things. 3) He does not like the fact that kitty has introduced new capabilities into the terminal ecosystem

About what I expected from my previous interactions with him. He excels at presenting excuses to maintain the status quo. I'm afraid I am not interested in tying kitty to this particular boat anchor. There's a reason the terminal ecosystem has stagnated for so long, and ncurses is a big part of that stagnation.

[z0rc]

A bit more context at https://lists.gnu.org/archive/html/bug-ncurses/2018-09/msg00007.html

Well, thing is, there is no alternative, and going rouge won't help with adoption of this terminfo. It's your call, but from perspective of regular user it's a lose-lose situation.

Ultimately there is nothing wrong of being picky about things you care and maintain, to some extent all developers are like this. The ncurses maintainers answer doesn't have an ultimate "no" context. I propose to continue discussion, as I truly hope we can find a consensus for this case.

[maximbaz]

Just wondering, would it not be a better approach to convince ssh maintainers to upload terminfo files on connect, basically to make ssh behave like kitty +kitten ssh does? I assume ssh itself would even have permissions to upload terminfo files for all users, so sudo -i will work as expected.

That way ncurses will not be a bottle-neck anymore, not for kitty, not for any other terminal that is not yet included in ncurses database.

[kovidgoyal]

@zorc Again, simply get your linux distribution's maintainers to create a separate package for kitty-terminfo and install that. Or distribute the terminfo file via Ansible. There are plenty of alternatives. If you insist on enthroning ncurses as the one true source of truth for terminal capabilities you are essentially dooming the terminal ecosystem to perpetual stagnation.

The only use for terminfo is to detect terminal features. If the terminfo maintainer refuses to accept any new features then it is a dead weight on the entire ecosystem. I contacted him to try to get him to include terminfo entries for new features adopted by many modern terminals, such as styled underlines (kitty, all VTE based terminals, hyper). I was refused and told to go add my own fields to kitty's terminfo. So that's what I did. If the maintainer now says he wont accept the terminfo file because it has those extra fields, I dont know what to tell you. And I'll note that the maintainer of ncurses happily allows xterm to have hundreds of extra definitions in its terminfo file which is included with ncurses http://lists.gnu.org/archive/html/bug-ncurses/2018-02/msg00008.html http://lists.gnu.org/archive/html/bug-ncurses/2018-02/msg00009.html

Similarly many people have been begging for years for a terminfo property for truecolor, it was finally added this year I think after being refused endlessly on the grounds that "no one needs truecolor in a terminal". As a direct result of that we have the insane mess described here: https://gist.github.com/XVilka/8346728

@maximbaz yes that is the best way to liberate the terminal ecosystem from ncurses, as I noted here: https://sw.kovidgoyal.net/kitty/faq.html#i-get-errors-about-the-terminal-being-unknown-or-opening-the-terminal-failing-when-sshing-into-a-different-computer

[z0rc]

@kovidgoyal I got your point. I know how to automate this, but in general this won't happen, if you have a team of developers. Changing configuration of entire server fleet, just because single developer uses uncommon terminal emulator? This sounds a bit ridiculous.

My point isn't about enthroning the ncurses, but making life of regular user a bit easier given existing solutions by making thing to work out of the box in all cases, even if takes a couple of years to do so. I would wholeheartedly support alternative solution, that can replace ncurses in the long run, if there is any. My only wish is to make it common, so I don't have worry what TERM should be used when doing ssh. Maybe it's possible to convince OpenSSH team to support this, but I don't think it's easier than ncurses case.

[maximbaz]

Maybe it's possible to convince OpenSSH team to support this, but I don't think it's easier than ncurses case.

Would you mind starting a thread on their mailing list, shortly describing what we want and why we want this? Let's see what the response will be.

[z0rc]

@maximbaz Sorry, I already have my share by discussing this at ncurses ML (it's not over yet). It's your idea, so I believe you'll be able to better represent it.

[kovidgoyal]

Well, hopefully kitty will not remain an uncommon terminal emulator for much longer :)

[kovidgoyal]

And this is the email exchange I just had with the maintainer of ncurses:

Email I sent: https://lists.gnu.org/archive/html/bug-ncurses/2018-09/msg00011.html

reproduced below since I dont trust the integrity of ncurses mailing list.

On Sun, Sep 09, 2018 at 07:31:33PM +0300, Igor Urazov wrote:
> Sorry, sent last message directly, submitting for mailing list this time.
> 
> On Sun, 9 Sep 2018 at 18:47, Igor Urazov <address@hidden> wrote:
> > Thomas, thanks. What kind of licenses are suitable for you? I believe
> > MIT or BSD are okay, right?
> Also there is option to re-license terminfo file under CC, how about this?
> 
> As of "xterm-kitty", there was a reason why this name was picked. At
> this moment ecosystem around terminal emulators accumulated a lot of
> assumptions: if $TERM = "xterm-*", then do something for various
> comparability reasons. Kovid, you have some examples, right? Thomas,
> maybe you have some ideas how to keep this compatibility, if
> xterm-kitty terminfo name is changed.

Sure I can dig up examples if needed, but this is a very common hack
used by many terminal emulators. For example, termite uses xterm-termite
gnome-terminal uses xterm-256color, konsole uses xterm-256color -- the
list goes on and on. The question is why is it a problem for ncurses in
the first place. Does xterm have some kind of most favored terminal
status that gives it permanent ownership over all xterm-* names. And
if so, IMO it is highly unfair. 

> 
> Last question about Su/Tc/setrgbb/setrgbf. I'm not entirely common
> with terminfo syntax and don't know how these capabilities are
> essential. Nor I'm aware how of their history with ncurses. But maybe
> we can omit them from xterm-kitty definition for inclusion in terminfo
> database and run reduced feature set, when they are missing. Still
> this would allow Kovid to distribute full featured terminfo with
> kitty.

They help applications detect the corresponding features. If you remove
them then what happens is that you get bugs like X feature works on my
local computer but not when I SSH in. That is a huge mess that will
create endless confusion and bug reports and that is completely
unnecessary. Again, why does it bother ncurses what terminfo fields are
in a particular terminals definition? I assume ncurses is smart enough
to ignore fields it does not understand, though I may be being overly
optimistic there. I will remind you that you are the one that suggested
I use terminfo as a key value database
http://lists.gnu.org/archive/html/bug-ncurses/2018-02/msg00008.html and
claimed that xterm already does this. Again, why does xterm get to do
this but no other terminal?

And email I received in response (which was not posted to the email list) from the maintainer of ncurses:

> Sure I can dig up examples if needed, but this is a very common hack                                                                           

...all of which are addressed in the faq.                                                                                                        

> used by many terminal emulators. For example, termite uses xterm-termite                                                                       
> gnome-terminal uses xterm-256color, konsole uses xterm-256color -- the                                                                         
> list goes on and on. The question is why is it a problem for ncurses in                                                                        
> the first place. Does xterm have some kind of most favored terminal                                                                            
> status that gives it permanent ownership over all xterm-* names. And                                                                           
> if so, IMO it is highly unfair.                                                                                                                

not at all: you are causing the problem, and I will not deal with you                                                                            
if you want to pursue this path.

I will note that he did not answer my question quoted above about why using xterm-kitty is a problem for ncurses, and completely ignored the second part of my mail about why xterm is allowed to have custom properties in the ncurses database but kitty is not.

And apparently I am the one that is somehow causing a problem. I am at a loss as to how to proceed at this point. I give up.

[z0rc]

https://lists.gnu.org/archive/html/bug-ncurses/2018-10/msg00024.html

https://invisible-island.net/ncurses/terminfo.src.html#toc-_Kitty

[blueyed]

@kovidgoyal Will you rename Kitty's own terminfo to kitty now also?

[kovidgoyal]

No, I will not. I chose to use xterm-kitty for a good reasons. Just grep the net for the number of shell scripts that detect functionality based on something like:

switch($TERM) {
case "xterm=*") ....

[blueyed]

Hmm, but there are certainly incompatibilities with xterm, e.g. handling of bold/bright colors, and certainly other things.

I would assume that people would update their rc files / scripts if necessary, no?

E.g. rxvt-unicode is also not matched by those scripts.

Renaming it would give us the benefit of having the terminfo available on systems already (not a problem really for me, but what this issue is about).

[tomjakubowski]

I think users who want to use upstream's terminfo can set term kitty in their config. https://sw.kovidgoyal.net/kitty/conf.html#opt-kitty.term

[barraponto]

Alternatively, users can ensure kitty's terminfo files are installed. Since there is no Ubuntu 18.04 package for kitty, binary installs can solve this issue by creating a $HOME/.terminfo/x directory and then symlinking or copying $HOME/.local/share/terminfo/x/xterm-kitty into it.

Maybe we should add this to the binary install instructions?

[kovidgoyal]

the kitty binaries automatically use their bundled terminfo, there is no need to do anything.

On Wed, Oct 16, 2019 at 08:21:47AM -0700, Capi Etheriel wrote:

Alternatively, users can ensure kitty's terminfo files are installed. Since there is no Ubuntu 18.04 package for kitty, binary installs can solve this issue by creating a $HOME/.terminfo/x directory and then symlinking or copying $HOME/.local/share/terminfo/x/xterm-kitty into it.

Maybe we should add this to the binary install instructions?

-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/kovidgoyal/kitty/issues/879#issuecomment-542754790

[barraponto]

I installed kitty on Ubuntu 18.04 using the binary install. Then I logged in to it using ssh from an Archlinux host. I had the usual terminal issues.

In Archlinux, echo $TERMINFO returns /usr/lib/kitty/terminfo. But once I ssh into the Ubuntu host, echo $TERMINFO returns nothing. Running echo $TERM in either host returns xterm-kitty as expected.

I then proceded to copy the xterm-kitty file into $HOME/.terminfo/x in the Ubuntu host. Using ssh now shows no issues. That's why I think it matters.

[Luflosi]

@kovidgoyal probably assumed, that you were not using ssh. Yes, when you're logged into another machine with ssh or similar, you need to copy the terminfo file. This is made easy with the ssh kitten, see https://sw.kovidgoyal.net/kitty/faq.html#i-get-errors-about-the-terminal-being-unknown-or-opening-the-terminal-failing-when-sshing-into-a-different-computer. @kovidgoyal What is the difference between infocmp xterm-kitty | ssh myserver tic -x -o \~/.terminfo /dev/stdin and copying the terminfo file directly?

[kovidgoyal]

@barraponto When you ssh you need to have terminfo files available on the remote host, which is easy to do using the kitty ssh kitten as documented in the FAQ and pointed out by Luflosi.

@Luflosi It does not need you to know where the kitty terminfo files are on the localhost

[rdrey]

There seems to be some issue here with ubuntu snap packages that bundle their own python & curses (for example pulsemixer). They don't seem to use the system's terminfo. Not sure if there is a workaround?

[eoli3n]

What a crazy story, it seems more an ego issue than anything else.

[ctrlcctrlv]

@eoli3n You are correct, Dickey's ego is the issue, yes.

[eoli3n]

I agree, but what now ? That's the problem when the power is in a single hand...

[ctrlcctrlv]

I don't know, but certainly bumping this issue will not help.

[omeid]

I agree, but what now ?

@eoli3n See what happened with X11/Wayland, SVN/git, SourceForge/Github, and more related Vim/NeoVim. Expect an ncurses alternative/fork to pop up.

It is a tough world, you either learn and adopt, or inadvertently waiting for your irrelevance.

[NickHu]

Here's a diff of the infocmp bundled with kitty (TERM=xterm-kitty) and the one bundled with ncurses (TERM=kitty).

--- xterm-kitty 2020-11-16 03:04:47.117018542 +0000
+++ kitty   2020-11-16 03:04:57.737137703 +0000
@@ -1,50 +1,40 @@
-#  Reconstructed via infocmp from file: /root/.terminfo/x/xterm-kitty
-xterm-kitty|KovIdTTY,
-   am, ccc, hs, km, mc5i, mir, msgr, npc, xenl,
-   colors#0x100, cols#80, it#8, lines#24, pairs#0x7fff,
+#  Reconstructed via infocmp from file: /run/current-system/sw/share/terminfo/k/kitty
+kitty|KovId's TTY,
+   am, ccc, hs, mc5i, mir, msgr, npc, xenl,
+   colors#0x100, cols#80, it#8, lines#24, pairs#0x10000,
    acsc=++\,\,--..00``aaffgghhiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~,
    bel=^G, bold=\E[1m, cbt=\E[Z, civis=\E[?25l,
    clear=\E[H\E[2J, cnorm=\E[?12l\E[?25h, cr=\r,
    csr=\E[%i%p1%d;%p2%dr, cub=\E[%p1%dD, cub1=^H,
    cud=\E[%p1%dB, cud1=\n, cuf=\E[%p1%dC, cuf1=\E[C,
    cup=\E[%i%p1%d;%p2%dH, cuu=\E[%p1%dA, cuu1=\E[A,
-   cvvis=\E[?12;25h, dch=\E[%p1%dP, dch1=\E[P, dim=\E[2m,
-   dl=\E[%p1%dM, dl1=\E[M, dsl=\E]2;\007, ech=\E[%p1%dX,
-   ed=\E[J, el=\E[K, el1=\E[1K, flash=\E[?5h$<100/>\E[?5l,
-   fsl=^G, home=\E[H, hpa=\E[%i%p1%dG, ht=^I, hts=\EH,
-   ich=\E[%p1%d@, il=\E[%p1%dL, il1=\E[L, ind=\n,
-   indn=\E[%p1%dS,
+   dch=\E[%p1%dP, dch1=\E[P, dim=\E[2m, dl=\E[%p1%dM,
+   dl1=\E[M, dsl=\E]2;\007, ech=\E[%p1%dX, ed=\E[J, el=\E[K,
+   el1=\E[1K, flash=\E[?5h$<100/>\E[?5l, fsl=^G, home=\E[H,
+   hpa=\E[%i%p1%dG, ht=^I, hts=\EH, ich=\E[%p1%d@,
+   il=\E[%p1%dL, il1=\E[L, ind=\n, indn=\E[%p1%dS,
    initc=\E]4;%p1%d;rgb\:%p2%{255}%*%{1000}%/%2.2X/%p3%{255}%*%{1000}%/%2.2X/%p4%{255}%*%{1000}%/%2.2X\E\\,
    kDC=\E[3;2~, kEND=\E[1;2F, kHOM=\E[1;2H, kIC=\E[2;2~,
    kLFT=\E[1;2D, kNXT=\E[6;2~, kPRV=\E[5;2~, kRIT=\E[1;2C,
-   ka1=, ka3=, kbs=^?, kc1=, kc3=, kcbt=\E[Z, kcub1=\EOD,
-   kcud1=\EOB, kcuf1=\EOC, kcuu1=\EOA, kdch1=\E[3~, kend=\EOF,
-   kf1=\EOP, kf10=\E[21~, kf11=\E[23~, kf12=\E[24~,
-   kf13=\E[1;2P, kf14=\E[1;2Q, kf15=\E[1;2R, kf16=\E[1;2S,
-   kf17=\E[15;2~, kf18=\E[17;2~, kf19=\E[18;2~, kf2=\EOQ,
-   kf20=\E[19;2~, kf21=\E[20;2~, kf22=\E[21;2~,
-   kf23=\E[23;2~, kf24=\E[24;2~, kf25=\E[1;5P, kf26=\E[1;5Q,
-   kf27=\E[1;5R, kf28=\E[1;5S, kf29=\E[15;5~, kf3=\EOR,
-   kf30=\E[17;5~, kf31=\E[18;5~, kf32=\E[19;5~,
-   kf33=\E[20;5~, kf34=\E[21;5~, kf35=\E[23;5~,
-   kf36=\E[24;5~, kf37=\E[1;6P, kf38=\E[1;6Q, kf39=\E[1;6R,
-   kf4=\EOS, kf40=\E[1;6S, kf41=\E[15;6~, kf42=\E[17;6~,
-   kf43=\E[18;6~, kf44=\E[19;6~, kf45=\E[20;6~,
-   kf46=\E[21;6~, kf47=\E[23;6~, kf48=\E[24;6~,
-   kf49=\E[1;3P, kf5=\E[15~, kf50=\E[1;3Q, kf51=\E[1;3R,
-   kf52=\E[1;3S, kf53=\E[15;3~, kf54=\E[17;3~,
-   kf55=\E[18;3~, kf56=\E[19;3~, kf57=\E[20;3~,
-   kf58=\E[21;3~, kf59=\E[23;3~, kf6=\E[17~, kf60=\E[24;3~,
-   kf61=\E[1;4P, kf62=\E[1;4Q, kf63=\E[1;4R, kf7=\E[18~,
-   kf8=\E[19~, kf9=\E[20~, khlp=, khome=\EOH, kich1=\E[2~,
-   kind=\E[1;2B, kmous=\E[M, knp=\E[6~, kpp=\E[5~,
-   kri=\E[1;2A, kund=, oc=\E]104\007, op=\E[39;49m, rc=\E8,
-   rev=\E[7m, ri=\EM, rin=\E[%p1%dT, ritm=\E[23m, rmacs=\E(B,
-   rmam=\E[?7l, rmcup=\E[?1049l, rmir=\E[4l, rmkx=\E[?1l,
-   rmso=\E[27m, rmul=\E[24m, rs1=\E]\E\\\Ec, sc=\E7,
+   kbs=^?, kcbt=\E[Z, kcub1=\EOD, kcud1=\EOB, kcuf1=\EOC,
+   kcuu1=\EOA, kdch1=\E[3~, kend=\EOF, kf1=\EOP, kf10=\E[21~,
+   kf11=\E[23~, kf12=\E[24~, kf13=\E[1;2P, kf14=\E[1;2Q,
+   kf15=\E[1;2R, kf16=\E[1;2S, kf17=\E[15;2~, kf18=\E[17;2~,
+   kf19=\E[18;2~, kf2=\EOQ, kf20=\E[19;2~, kf21=\E[20;2~,
+   kf22=\E[21;2~, kf23=\E[23;2~, kf24=\E[24;2~,
+   kf25=\E[1;5P, kf26=\E[1;5Q, kf27=\E[1;5R, kf28=\E[1;5S,
+   kf29=\E[15;5~, kf3=\EOR, kf30=\E[17;5~, kf31=\E[18;5~,
+   kf32=\E[19;5~, kf33=\E[20;5~, kf34=\E[21;5~,
+   kf35=\E[23;5~, kf36=\E[24;5~, kf4=\EOS, kf5=\E[15~,
+   kf6=\E[17~, kf7=\E[18~, kf8=\E[19~, kf9=\E[20~, khome=\EOH,
+   kich1=\E[2~, kind=\E[1;2B, kmous=\E[M, knp=\E[6~,
+   kpp=\E[5~, kri=\E[1;2A, oc=\E]104\007, op=\E[39;49m,
+   rc=\E8, rev=\E[7m, ri=\EM, rin=\E[%p1%dT, ritm=\E[23m,
+   rmacs=\E(B, rmam=\E[?7l, rmcup=\E[?1049l, rmir=\E[4l,
+   rmkx=\E[?1l, rmso=\E[27m, rmul=\E[24m, rs1=\Ec, sc=\E7,
    setab=\E[%?%p1%{8}%<%t4%p1%d%e%p1%{16}%<%t10%p1%{8}%-%d%e48;5;%p1%d%;m,
    setaf=\E[%?%p1%{8}%<%t3%p1%d%e%p1%{16}%<%t9%p1%{8}%-%d%e38;5;%p1%d%;m,
-   sgr=%?%p9%t\E(0%e\E(B%;\E[0%?%p6%t;1%;%?%p2%t;4%;%?%p1%p3%|%t;7%;%?%p4%t;5%;%?%p7%t;8%;m,
+   sgr=%?%p9%t\E(0%e\E(B%;\E[0%?%p6%t;1%;%?%p5%t;2%;%?%p2%t;4%;%?%p1%p3%|%t;7%;m,
    sgr0=\E(B\E[m, sitm=\E[3m, smacs=\E(0, smam=\E[?7h,
    smcup=\E[?1049h, smir=\E[4h, smkx=\E[?1h, smso=\E[7m,
    smul=\E[4m, tbc=\E[3g, tsl=\E]2;, vpa=\E[%i%p1%dd,

Regardless of politics, it seems like they ought to match

I've sent a message to the ncurses mailing list to try to rectify this

[kovidgoyal]

Good luck!

[kovidgoyal]

@NickHu I have sent you email as well, but as I am having email deliverability issues these days, am also posting it here:

Sure, happy to. To see the differences run

infocmp -d kitty

inside kitty.

1) kitty is missing the km capability compared to xterm-kitty
this capability indicates suport for the meta key, which kitty does
indeed support.

2) The number of color pairs is increased from 0x7fff to 0x1000
I think only ncurses uses this, so *probably* safe to change it in
xterm-kitty to match kitty.

3) kitty is missing cvvis which is an escape code to make the cursor
visible

4) There are a bunch of key definitions missing in kitty vs xterm-kitty,
that's the properties starting with k. Some empty key definitions are
represented as empty strings in xterm-kitty and are missing in kitty.
these should possibly be changed in xterm-kitty

5) The rep escape code for repeating text is missing from kitty

6) The reset (rs1) capability in kitty is incorrect

7) The sgr capability in kitty is incorrect.

[alekosot]

Just to add that simply installing the kitty-terminfo provided by both Centos 8 and Ubuntu 20.04 solved any problems I had with SSH, sudo, etc and I am not even using the kitten provided. I haven't tried older versions, Debian or Alpine yet, but it seems that this is increasingly easy to solve as time goes by.

[ctrlcctrlv]

Yup, the distributions are realizing the unreliability of the ncurses database, and packing terminfo's it refuses. Good news.

[akaWolf]

@NickHu does now kitty in ncurses and xterm-kitty in sync?

[kayshinonome]

Just to add that simply installing the kitty-terminfo provided by both Centos 8 and Ubuntu 20.04 solved any problems I had with SSH, sudo, etc and I am not even using the kitten provided. I haven't tried older versions, Debian or Alpine yet, but it seems that this is increasingly easy to solve as time goes by.

Debian has had the terminfo files since buster [Package info]

[page-down]

It is worth noting that the version of TERMINFO on the host connected via SSH should match the version of kitty that is used, otherwise there will be problems.

For example, kitty does not work properly after entering the docker container due to TERMINFO version mismatch. https://github.com/kovidgoyal/kitty/discussions/4104