
Kitty 0.17 – GPU-accelerated terminal emulator - selrond
https://sw.kovidgoyal.net/kitty/changelog.html#id1
======
unixhero
Not to be confused with Kitty[0], a Putty fork. Also a terminal emulator!

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

~~~
KarlKemp
The relevant Github issue is also quite memorable:
[https://github.com/kovidgoyal/kitty/issues/9#issuecomment-41...](https://github.com/kovidgoyal/kitty/issues/9#issuecomment-418566309)

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

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

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

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

------
albertzeyer
Btw, if the author (Kovid Goyal) reads this: You really should update your
homepage ([https://kovidgoyal.net/](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.

I was not quite sure if this was a joke, or if the homepage was really not
updated for such a long time (it says "Created by Kovid Goyal © 2003").

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](https://news.ycombinator.com/item?id=17924093)

~~~
outadoc
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
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
It really should not be "xterm-" _anything_. This is another misnomer.

* [http://jdebp.uk./Softwares/nosh/guide/commands/TERM.xml#MIS-...](http://jdebp.uk./Softwares/nosh/guide/commands/TERM.xml#MIS-CONFIGURATION)

* [https://invisible-island.net/xterm/xterm.faq.html#other_vers...](https://invisible-island.net/xterm/xterm.faq.html#other_versions-id)

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

* [https://invisible-island.net/ncurses/terminfo.ti.html#tic-pu...](https://invisible-island.net/ncurses/terminfo.ti.html#tic-putty)

~~~
blinkingled
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!

------
checkyoursudo
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
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
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
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
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...](https://web.archive.org/web/20180821055830/http://www.joehanchoi.com/quick-
fixes-for-tmux-2-1-on-osx/#enablingmousesupport)

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

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

------
robotmay
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
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
I think Alacritty was first. At least it became popular first.

~~~
dijit
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

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

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

------
kabacha
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
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-...](https://github.com/kovidgoyal/kitty/issues/160#issuecomment-346470545)

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

~~~
JdeBP
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...](http://jdebp.uk./Softwares/nosh/guide/commands/TERM.xml#MEANING)

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

~~~
dh-g
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
"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/](https://danluu.com/term-latency/)

------
easel
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
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
Using Ubuntu I was only a `sudo apt install` away from running it.

------
ecopoesis
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
A discussion from 2 years ago:

[https://news.ycombinator.com/item?id=17915829](https://news.ycombinator.com/item?id=17915829)

------
Shorel
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
With due respect - this sounds like the terminal emulator equivalent of a
ricer car:
[https://en.wikipedia.org/wiki/Rice_burner](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
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/](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.

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

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

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

