Kitty 0.17 – GPU-accelerated terminal emulator

Kitty 0.17 – GPU-accelerated terminal emulator(sw.kovidgoyal.net)

76 points by selrond 6 years ago | 73 comments

unixhero 6 years ago |

Not to be confused with Kitty[0], a Putty fork. Also a terminal emulator!

[0] http://www.9bis.net/kitty/#!index.md

KarlKemp 6 years ago | |

The relevant Github issue is also quite memorable: https://github.com/kovidgoyal/kitty/issues/9#issuecomment-41...

I wonder if the author might be willing to reconsider. He should have newfound appreciation for how annoying name collisions can be.

pwdisswordfish2 6 years ago | | |

Ah, so he kept his attitude from back when he refused to fix security vulnerabilities in Calibre.

Good to know. I'll keep avoiding his software.

georgyo 6 years ago | | |

It's very sad that the name was not changed. It is his right not to change it, but it is to the detriment of the community of both emulators.

dkersten 6 years ago | | |

I’ve been happily using kitty for ages, but this butthurt “you hurt my feelings, so I am going to do the opposite” is very childish, immature and offputting.

crypt1d 6 years ago | | |

He comes off as quite arrogant, I wouldn't count on it.

fnord123 6 years ago | |

Holy cow I really thought this was about the putty fork.

bspammer 6 years ago | | |

There are only so many words in the english language ending in tty I suppose.

albertzeyer 6 years ago |

Btw, if the author (Kovid Goyal) reads this: You really should update your homepage (https://kovidgoyal.net/). It gives me a warning:

> W A R N I N G! Your browser is not supported by this site.I cannot guarantee that things will work as they should. Consider downloading either Mozilla >=1.4 or Internet Explorer >= 6

And it states:

> It has been tested on Internet Explorer 6 and Mozilla 1.4.

Anyway, for minimal work, I think you can simply remove the warning, and this statement about IE6/Mozilla 1.4, because as far as I can see, everything works fine.

Edit: Ah, in the 2018 thread, someone noticed the same thing: https://news.ycombinator.com/item?id=17924093

outadoc 6 years ago | |

Looking at the rest of the website, I think it fits with its theme... I don't think it's been majorly updated at all since 2003.

blinkingled 6 years ago |

Kitty is good but the only issue I have is the use of custom terminfo xterm-kitty. This means things break when ssh’ing to older Linux until you copy the terminfo manually. On BSDs it doesn’t work as there is no terminfo support.

JdeBP 6 years ago | |

It really should not be "xterm-" anything. This is another misnomer.

* http://jdebp.uk./Softwares/nosh/guide/commands/TERM.xml#MIS-...

* https://invisible-island.net/xterm/xterm.faq.html#other_vers...

The correct terminal type, per Dickey terminfo, is "kitty". (The PuTTY variant KiTTY is apparently also "putty".) And the terminfo database lends itself both to copying individual records and to having extra records in one's home directory.

* https://invisible-island.net/ncurses/terminfo.ti.html#tic-ki...

* https://invisible-island.net/ncurses/terminfo.ti.html#tic-pu...

blinkingled 6 years ago | | |

Thanks for the insight :) I have always had a bit of 'why do I gotta know that' thing going on with terminfo, console and friends - this is making me want to dig a bit deeper!

floatboth 6 years ago | |

> On BSDs it doesn’t work as there is no terminfo support

ncurses from FreeBSD Ports is built with terminfo, but the ncurses from base uses termcap. Kind of a mess :)

Most application ports have USES=ncurses without arguments, which means they will prefer the ports ncurses — if it's installed at build time. Official binary packages are built without it installed of course. So rebuilding the ncurses apps you care about would make them use terminfo.

Also you can convert terminfo to termcap: https://invisible-island.net/ncurses/man/infotocap.1m.html

checkyoursudo 6 years ago |

I like kitty because it has ligature support. I haven't found many terminal emulators in the Gentoo repository that have both ligature support and are DE-independent. That's pretty much the main reason I use kitty.

aaaaarghZombies 6 years ago |

Been using kitty for a bit, I essentially wanted to be able to render emojis in nvim. I haven't really thought about it since installing which is a good sign.

jhasse 6 years ago |

I really like kitty, but I always wonder how people can live without a scrollbar or smooth scrolling in general. Unfortunately that's a dealbreaker for me.

photonios 6 years ago | |

I use tmux in kitty. I rarely have to scroll and when I do, I can certainely do without smooth scrolling. Usually I just use tmux to search and jump through the output.

I was a heavy terminal user already but running macOS at work and linux at home, I got really annoyed by having to memorize different shortcuts. So I just gave up and started using tmux. Now, no matter what platform I am on, the behaviour is pretty much the same. I just use Kitty because it performs really well.

rsify 6 years ago | | |

FYI you can configure mouse wheel (or in my case just trackpad) scrolling in tmux [1], I've had this configured for years and it's worked really well for me.

[1] https://web.archive.org/web/20180821055830/http://www.joehan...

climb_stealth 6 years ago | |

I work around the scrollbar issue by having keyboard shortcuts to open the full scrollback in vim, either on top of the current view or in a new tab. I was surprised how little it bothered me, and nowadays I even prefer it. You get all the text control in vim which is so much nicer than the scrollbar approach.

Scrolling itself seems smooth for me in general.

Hackbraten 6 years ago | |

According to the website, isn’t smooth scrolling exactly what kitty offers?

jhasse 6 years ago | | |

This is what I mean: https://github.com/kovidgoyal/kitty/issues/1123

robotmay 6 years ago |

How does this compare to Alacritty on Linux? I've been pretty happy with Alacritty for the past few years but I'm always interested in trying new things.

dijit 6 years ago | |

Alacritty is inspired by kitty; kitty being GPU accelerated (and alacritty also being GPU accelerated).

The major difference between them is that alacritty is written in rust (and has a really nice config that auto-reloads) and kitty is written in C with a smattering of python.

floatboth 6 years ago | | |

I think Alacritty was first. At least it became popular first.

izacus 6 years ago | |

I feel like Kitty has less strange bugs due to its acceleration - e.g. font rendering is more consistent with the rest of the OS, I've had less issues with mouse and keyboard support, scroolback works, etc. It just feels like a more mature project while still providing most of the benefit.

Shorel 6 years ago | |

I tried Alacritty some months ago also because of a HN post.

I think it lacks features compared to Kitty. At the very least tabs for multiple sessions and support for a transparent background made it not an option for me.

Kitty has replaced the standard terminal in Ubuntu for me, and I am quite happy with its performance and Unicode support.

pmoriarty 6 years ago | |

Kitty is very feature rich, while alacritty seemed to have very few features in comparison, last time I checked.

diggan 6 years ago | | |

As someone who is currently using Alacritty, and been since it first appeared on HN (years ago?), what specific features are you missing in Alacritty that Kitty has?

bjakubski 6 years ago |

I've recently made a switch to Kitty from iterm2. I couldn't suffer general slowness and visible lag when using vim or nvim anymore. Various solutions and workarounds provided only minimal relief. With kitty the performance improvement was dramatic. Configuration is more involved (config file), but I've managed to set everything up as I'm used to in short time. I'm happy so far, but ymmv

climb_stealth 6 years ago | |

Similar situation here. At some point opening/closing tabs got really slow for me in iterm2 and I couldn't find a way around it. With kitty it's pretty much instant and for me worth the lack of other features.

Also, a whole lot of it is written in Python and I actually contributed smaller changes in pull requests. It feels good to be able to just change things.

camgunz 6 years ago | |

I did this too and used kitty for maybe more than a year. I recently switched to gvim and using :terminal though; the font rendering is better and actually I think it's even faster. Give it a try.

P.S. weirdly on Linux it's entirely opposite; vim in an xterm is much faster than gvim.

jamil7 6 years ago | |

Huh, I switched to Kitty a year or so ago and then back to iTerm when they introduced GPU acceleration. Turning off ligatures made nvm much more responsive for me.

kabacha 6 years ago |

I've been using Kitty with Xonsh shell on Qtile dekstop and Qutebrowser browser for over a year now. What a time to be a Python dev!

quotemstr 6 years ago |

I really like how kitty addresses the weird compatibility issues of bce [1] by providing a facility to just do character cell property modifications in an efficient and correct way [2].

I wish ncurses were more eager to adopt descriptions of innovations in terminal emulator design.

[1] https://github.com/kovidgoyal/kitty/issues/160#issuecomment-...

[2] https://sw.kovidgoyal.net/kitty/protocol-extensions.html#ext...

JdeBP 6 years ago | |

The problem with BCE is largely that it does not fit with the paradigms of ncurses and terminfo, not that it is problematic in itself. This is alas true of a large number of terminal things, from function keys through "cursor addressing mode" to erasure, whose ncurses/terminfo abstractions do not fit the actual ways that these work.

On both real (DEC) terminals and terminal emulators, background colour erase is settable off and on, with DECECM; so a full-screen application can set the behaviour and know what the colour is going to be, leading to more efficient screen redraws. The ncurses/terminfo model, in contrast, is that the behaviour is fixed on or off, and a boolean (named bce) in the database tells softwares which it is for any given terminal type.

In reality, it is the paradigms of ncurses and terminfo that are the problems here.

* http://jdebp.uk./Softwares/nosh/guide/commands/TERM.xml#MEAN...

nvarsj 6 years ago |

On Mac at least, kitty seems to be the best terminal option. It's fast/low latency, has no font rendering issues, and fully supports ligatures (iterm2, alacritty, all have issues in my experience). It also works well with tmux.

jwr 6 years ago |

Hmm. I tried it and I'm trying to find reasons why this is better than Apple's default Terminal.app?

It's obviously better than iterm2, but Apple's built-in terminal is actually rather fast.

jhrmnn 6 years ago | |

I was a happy user of Terminal.app until I got a 4K display, which I run at scaled 2.5K, so effectively rendering 7.5K. With my Macbook Air 2018, this results for example in a FPS of ~13 when scrolling full-screen in Vim with Terminal.app rendering on a CPU, which is super annoying. Kitty brings this to ~35.

pfranz 6 years ago | |

I've been using Terminal.app for years (I used iTerm2 before Terminal.app had some major improvements). I switched to Kitty so I could bind a shortcut key to opening a new terminal window--a habit I picked up from tiling window managers. I can't remember if I had other criteria, but Kitty has been surprisingly a quiet workhorse since I switched (I occasionally had TERM issues when ssh-ing).

dh-g 6 years ago | |

Depends on your usage but terminal.app is quite a bit slower then iterm2's metal renderer or Alacritty (probably kitty as well but I haven't used it).

lloeki 6 years ago | | |

"Slower" is not a metric. Latency is, though, and Terminal.app is a top contender (and rips iterm2 to shreds, even in throughput, not that throughput matters in practice).

Please stop spreading cargo cult information dating from 10.4 days. Terminal.app has been great ever since 10.6.

https://danluu.com/term-latency/

pfranz 6 years ago | | |

I don't think I've seen issues in practice, but I thought last time I saw benchmarks Terminal.app blew away the others. I believe it used some non-standard method to render to screen.

easel 6 years ago |

Kitty has the best intersection of performance, platform support, and features i have found. It’s not without warts, and doesn’t support windows (yet) but one can dream.

jstimpfle 6 years ago |

How can I tell if this is interesting to me without actually compiling and running it? Are there any screenshots or videos? Any benchmarks?

Shorel 6 years ago | |

Using Ubuntu I was only a `sudo apt install` away from running it.

ecopoesis 6 years ago |

The standout feature Kitty has for me is keeping its config in a regular text file, so like all my other basic tools it can be configured from my dotfiles repo and a simple setup script. So much simpler then fussing with iTerm’s plist.

merricksb 6 years ago |

A discussion from 2 years ago:

https://news.ycombinator.com/item?id=17915829

Shorel 6 years ago |

Testing it now.

I have to learn a few new shortcuts, but I am quite satisfied so far, it does all things I want in a terminal that Alacritty did not, like tabs and transparency.

einpoklum 6 years ago |

With due respect - this sounds like the terminal emulator equivalent of a ricer car: https://en.wikipedia.org/wiki/Rice_burner

"fast"? What, terminal emulation is slow now? Needs hardware acceleration? Be serious.

A graphical terminal emulator should use underlying graphical environment features/libraries for things like hardware-assisted rendering.

jstimpfle 6 years ago | |

Not just terminals. So much software is unbearably slow today. Definitely terminals. The only terminal I can really stand is xterm with bitmap fonts.

https://danluu.com/term-latency/

> A graphical terminal emulator should use underlying graphical environment features/libraries for things like hardware-assisted rendering.

I've mostly done OpenGL recently, and I think xterm (which is fast) is an exception in that it uses just X11 primitives, but I also know that some font frawing APIs are very slow. GDI is what I have in mind mostly. So using Hardware more directly (i.e. OpenGL) might be not the worst idea.

mgaffney 6 years ago | | |

> https://danluu.com/term-latency/ This was written in 2017. It's got great information but I'm guessing most, if not all, of the terminals tested have newer versions. Just think of what 3 years of feature bloat could have done to their performance.

einpoklum 6 years ago | | |

Wow, those graphs are mind-blowing!

But it sounds like what should really be written is a fast, hardware-backed, low-latency but limited-feature graphics library.

Then have your terminal use that. I still say that direct awareness of the hardware is _way_ too much coupling.

pfranz 6 years ago | |

I've noticed terminal rendering performance issues when dumping a lot of text. If that's part of your job, it's important to you. For me it seems to come up once every few years and I've poked around at alternatives.

I've also heard about performance issues with high res, large terminals. It's a lot of pixels to throw at the screen and I'm sure most terminal emulators were written with much smaller screens in mind.