Kitty 0.17 – GPU-accelerated terminal emulator | Hacker News Reader

Kitty 0.17 – GPU-accelerated terminal emulator

sw.kovidgoyal.net

76 pointsselrond73 comments

Open articleView on HN

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

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

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

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

It hadn't even occurred to me Putty was named that based on the word containing tty.

It's literally branded PuTTY in all of the website, UI, etc.

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.

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.

I can't think of anything more petty or pathetic then taking the side of a mob that demands an open source developer change the name of the software he makes in his free time.

People talk about entitlement in games but here you are not even paying or even having a pretense of sponsoring.

Just gross.

I don't even particularly care if he changes the name or not. If he makes decisions on the basis of spiting as many people as possible, he reveals himself to be a foolish and irresponsible individual. Unfortunately it's not even the first such incident, and as far as I can see, he learned nothing from the last one. That is a perfectly valid reason to avoid his software. What am I supposed to do, send all my life's savings to a project that I have no reason to expect will deliver quality?

(“Criticising me for punching your face really shows your entitlement. You don't pay me to choose whom I punch in the face. You have no right to tell me how I spend my free time!”)

Also, mobs occasionally have a point. The opposite of the ‘five billion flies’ fallacy is still a fallacy.

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.

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.

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

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

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.

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.

> 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

Awesome! I will try infotocap and rebuild ncurses from ports along with any other apps and see. Thanks.

Doing `export TERM=xterm` has worked consistently for me

Yep it works for the most part - I remember having weird issues once in a while - not sure if it was build from git kitty that I was using or some TERM compatibility thing.

It's pretty much always the case in such situations that the terminal emulator is not XTerm and the "xterm" entry in termcap/terminfo simply does not describe it.

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...

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!

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.

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.

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.

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

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

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.

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...

Unfortunately, that breaks scrolling in VIM, which I also use. I do use scrolling with the track pad in VIM sometimes and I care more about that than scrolling in my terminal.

Maybe I should try re-enabling it again. It's been a while. Maybe tmux or VIM fixed this.

I think this is fixed. I'm using tmux and vim with mouse scroll enabled for both and haven't experienced any issues.

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.

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.

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.

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

Seems you are right, I always assumed alacritty was derived from the ideas in kitty (and hence the name being similar)

first commit in alacritty: Sun Feb 21 08:15:41 2016 -0800

first commit in kitty: Fri Oct 14 12:33:27 2016 +0530

The names are similar because they both do a wordplay on TTY (teletypewriter)

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

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?

Kitty has a very nice way to search and insert unicode characters (shift+control+u).

I tend to use the CTRL+Shift+U shortcut with the codes memorized or looked up from https://unicode.org/charts/ (https://odoepner.wordpress.com/2018/01/04/enter-unicode-char... goes through how to use it) instead, so I can use them all over (IRC + Slack + Browser + Terminal).

Good to know though, so thanks for the reply.

Tabs are probably the biggest thing.

I see. For someone using tmux, seems that would be a non-feature. Thanks for the reply!

One thing about tabs, which ironically has come up now for Microsoft Windows Terminal, is that they do not fit at all well with the idea of application-resizable terminals, which has been the widely case for terminal I/O since the days of 80/132 column application-switchable terminals back in the 1970s. If (just to pick a mild example) one tab is a 24-line terminal and another is a 25-line terminal, they aren't the same size in the GUI.

Line up a row of real terminals, and of course they do not constrain one another, size-wise. Indeed, back in the 1990s the DTTerm terminal emulator pioneered the terminal emulators' abilities for applications to set any arbitrary size (within reason) for a terminal emulator.

I did a quick review of terminal emulators in light of this, and varyingly tabbed terminal emulators do not support application resizing (DECSLPP/DECSNLS/DECSCPP) at all or support it in limited, or at least odd (compared to real terminals), ways. Konsole, possibly the best of the bunch, implements resizing properly, leaving large margins when the requested terminal screen size does not match the GUI window size, but triggers a GUI resize whenever a tab receives the input focus back, so application-requested size changes do not last if one switches amongst tabs. One tabbed terminal emulator author is actively opposing the idea that terminals should be resizable by applications emitting these control sequences, completely reversing course from DTTerm's innovation.

The problem for Windows Terminal is compounded by the fact that it isn't just supporting terminal I/O applications, it is supporting console I/O applications. In console I/O not only can applications set the screen buffer size at whim, they can also set the window rectangle. Not supporting either is a huge and very noticable step backwards, by over three decades, for Windows TUI applications that Windows Terminal is aimed to be compatible with.

A tabbed UI is not a universally unproblematic thing when it comes to terminal emulators. (-:

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.

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.

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

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.

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.

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.

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!

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...

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...

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.

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.

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).

"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/

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.

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.

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).

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.

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

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

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.

A discussion from 2 years ago:

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

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.

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.

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.

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.

OpenGL is actually pretty high-level. I don't know how much detail of the hardware it lets you get - probably mostly through hardware-specific extensions. The most basic usage is really hardware oblivious. There are many even more high-level toolkits on top of that, such as Qt. But if you need some flexibility and performance, using OpenGL is probably your best bet.

Yeah, plus hardware accelerated font rendering isn't trivial.

> 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.

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.

Reply on news.ycombinator.com