Kitty – A fast, featureful, GPU based terminal emulator | Hacker News Reader

Kitty – A fast, featureful, GPU based terminal emulator

sw.kovidgoyal.net

385 pointsGedxx195 comments

I rarely use anything new because my work environment is holy, but I tried Kitty because it had a Unicode menu built-in. I like to send unicode smileys to friends on IRC. :)

Anyways here are my impressions after 1 month.

1. You have to transfer terminfo to all ssh servers because the kitty term does not exist there.

2. By default mouse selection with double click + drag to select multiple lines is not normal. I believe this could be fixed but I haven't figured out how yet. (I could not re-create this right now, maybe it was fixed in some recent upgrade)

3. Unlike gnome-terminal (my old default) it actually opens up to fullscreen if you used it in fullscreen mode last.

4. Unlike gnome-terminal I could immediately figure out how to make it open up a few default tabs like a session on start up.

5. Its CLI tools don't accept the same arguments when defining a session, as when using them outside of the session definition. This was barely documented.

Overall the impression is good because I'm still using it. I rarely use anything new this long if it has issues affecting my workflow.

> You have to transfer terminfo to all ssh servers because the kitty term does not exist there.

terminfo made sense decades ago when most people were connecting to 1 big centralised mainframe from a mix of random terminals. Now we have people using one (software) terminal to connect to many servers big and small. Requiring terminfo to be updated on the remote side is just nuts.

Kitty should just identify as xterm like every other terminal written in the last 20 years.

> Kitty should just identify as xterm like every other terminal written in the last 20 years.

This is not my experience at all. I'd say most of terminals, including modern ones, have unique terminfos and work miserably when it's not installed. Examples include ST, kitty, alacritty. On top of that we have terminal multiplexers like tmux and screen which provide their unique terminfos as well.

Then our experience diffs greatly. I can't remember the last time I saw a $TERM which wasn't 'xterm' or 'xterm-256color'.

I find myself in between. I've seen many terminfo's set to other things, which don't work, or have to be set every time I'm connecting to a new server which is too much extra work for every new server in my opinion. So I always just set it to xterm-256color and forget it

I use rxvt-unicode which sets $TERM to "rxvt-unicode-256color," which is not recognized by a number of server to which I have to connect to from time to time.

There's a whole story about that, part of which is that at the time terminfo had to cater for old systems where there's a limit on the length of a terminal type name. But the same applies as for a missing kitty terminfo entry. The terminfo database is designed so that one can copy records around, and one can put them in a directory in one's home directory if one does not have administrative access to update the system database.

Debian systems have had an rxvt-unicode-256color entry for approaching 10 years, now. FreeBSD for about the same.

* https://sources.debian.org/src/ncurses/5.9-10/debian/rxvt-un...

* https://svnweb.freebsd.org/base/head/share/termcap/termcap?r...

xterm-256color-italic user here (comments in text editor are italic).

> Kitty should just identify as xterm like every other terminal written in the last 20 years.

You can do that by adding "term xterm-256color" to kitty.conf. The manual page warns against this but it seems to be mostly compatible. Kitty-specific extensions probably won't function remotely but it still serves as a nice portable terminal which can be configured with dotfiles.

The fact that the terminal is identified based on a TERM environment variable made sense if you want to support many hardware terminals which can't otherwise identify themselves and predate terminfo.

Maybe in the modern world applications could use an escape sequence to check for extensions on top of standard xterm?

1) kitty +kitten ssh myserver

That solves that.

FWIW that doesn't copy user capabilities; for that use:

  infocmp -x xterm-kitty | ssh myserver tic -x -o \~/.terminfo /dev/stdin

Could you explain this a bit more? I'm not sure what `ssh myserver tic -x -o \~/.terminfo /dev/stdin` is trying to do nor that it's correct as you typed it. Should `tic` be `-tic`?

tic is the TermInfo Compiler

The command on the left side of the pipe dumps the terminfo for "xterm-kitty" to stdout

The command on the right side launches ssh to "myserver" and executes tic to compile from stdin and output to the ~/.terminfo directory (which nurses/terminfo will search by default).

So basically it takes a local terminfo entry and copies it to the user-local terminfo path on the remote host.

The command will work for any other terminal too; just replace xterm-kitty with whichever entry you'd like copied.

Thanks!

As much as I like kitty, that shortcut is the only reason I've continued to use it for the past 18 months. Needing to manually fix it every time I connect to a new VM would've otherwise killed the appeal for me. `+kitten ssh` solves it nicely.

I've found that doing TERM=xterm-256color works better for me because of default debian bashrc on remote servers.

I wish I had known about this a year ago. A whole lot less to type than “mkdir -p ~/.terminfo/x ^D scp /usr/share/terminfo/xterm-kitty user@server:~/.terminfo/x/“

it seems to break on sudo. Haven't found a fix for that yet

I just set up this alias:

    alias ssh='TERM="xterm-256color" ssh'

Generally works just fine for me. I tried the kitten approach but I had some issues as well.

thanks it helps

> You have to transfer terminfo to all ssh servers because the kitty term does not exist there.

Ouch, that's a dealbreaker. I remember having to set up my own termcap/terminfo entries decades ago, when 1200 bps was fast and I had few viable choices for terminal emulators, and all of them had their quirks. Hard pass.

You can work around that:

> echo "term xterm-256color" >> ~/.config/kitty/kitty.conf

Documentation advises against it, but what do they know? https://sw.kovidgoyal.net/kitty/conf.html#opt-kitty.term

Your distro may carry a terminfo package for kitty in its main repo.

On Gentoo it's x11-terms/kitty-terminfo . On Ubuntu it's kitty-terminfo . You may want to add it to your default installations of the machines you ssh into, and for machines where you can't do that, there's 'kitty +kitten ssh' as others have already pointed out.

It's in Dickey terminfo, too, and has been since October 2018.

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

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

Goyal kitty isn't actually XTerm at all, of course, and the vanilla terminfo naming system comprises model names with suffixes. So only actual XTerm should have the prefix "xterm". In vanilla terminfo, kitty's terminal type is thus "kitty", with suffixes such as "-direct".

The PuTTY fork KiTTY, in contrast, corresponds with terminal types in the "putty-" family.

* https://news.ycombinator.com/item?id=22683277

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

> 2. By default mouse selection with double click + drag to select multiple lines is not normal. I believe this could be fixed but I haven't figured out how yet. (I could not re-create this right now, maybe it was fixed in some recent upgrade)

double click do word selection, triple click do line selection , don't know if this is configurable

I really want to like Kitty, but it's a very opinionated piece of software, and there's a number of decisions that just make it hard to. No GUI config is one, and I can't be arsed to go through multiple cycles of changing a config file, checking if it is alright, then going back. One particular sticking point for me, even after I got my config going, was that I couldn't resize my tiles with the mouse. This is by design: the author doesn't want it. The keyboard shortcuts for resizing tiles also don't work on an axis level, and you can only make a tile wider or narrower. Obviously, this means you can't configure your arrow keys to resize, as the mental model would break depending on which side of the screen the tile is on. I wanted Kitty because it has ligatures, tiling and GPU rendering, but after fighting with it a tonne, I just gave up and moved on.

And that's the thing about opinionated software: if you don't share the opinions it was built with, you're not going to enjoy using it at all. By all means, Kitty is amazing if you get into its model, but for a large portion of the audience I think Konsole or iTerm will just suit you much better.

Give alacritty a try:

https://github.com/alacritty/alacritty

Alacritty doesn't have ligatures yet, AFAIK, so it breaks my vim use in terminal :(

>so it breaks my vim use in terminal

From that Blog:

https://dev.to/22mahmoud/my-terminal-became-more-rusty-4g8l

>>Alacritty doesn't come with ligature support but you can use this fork. Or if you are using Arch you can install it from aur

https://github.com/zenixls2/alacritty/tree/ligature

I hope that helps

Hey, thanks. I'll try it out over the weekend.

> No GUI config is one, and I can't be arsed to go through multiple cycles of changing a config file, checking if it is alright, then going back

I recently switched to kitty precisely because it's portable and can be configured with a dotfile kept in git.

Doing the same with putty, iTerm2 or gnome-terminal would require automating the import/export of platform-specific config formats that I'd honestly rather not learn.

> Doing the same with putty, iTerm2 or gnome-terminal would require automating the import/export of platform-specific config formats that I'd honestly rather not learn.

Sakura is pretty nice - options can be changed in the gui/menu - config file is stored on disk.

http://manpages.ubuntu.com/manpages/focal/en/man1/sakura.1.h...

You can have your cake and eat it too though - you could have GUI to provide an optional, but convenient, way of editing a config file.

As a user of a terminal though, personally I would prefer if development time would be spent on terminal features themselves, instead of a convenience feature I'd think unnecessary. I guess this would be a nice project for somebody who really wants that: create a generic gui app to create those config files for a number of applications....

Kitty is one of those programs you install because you read about some performance improvements and mature feature stack, then completely forget about it in the background. The ideal piece of software. It just works and does the job well enough to be invisible.

Likewise I had repeated issues with iTerm breaking or consuming tons of resources for no reason which I had zero interest in debugging.

Glad to recommend it to anyone else.

...At least on MacOS. On Linux I was very happy with Termite which fit my keyboard-centric linux style https://github.com/thestinger/termite

I'm a bit curious why people on MacOS don't just use the built-in Terminal.app. It's really good and fast.

It was sort of unloved for a long time which left the opening for something like iTerm to get popular in the first place.

I'd honestly would go back but can't give up the iTerm Hotkey Window (global hotkey, semi transparent terminal quickly slides out from the top of the screen).

it doesn't have true colors for one

This is also why I use kitty instead of terminal.app. I just can't get colors working for vim. Otherwise, its surprisingly fast. Much better than iTerm imo.

Sigh. There's already a project called Kitty. It has been going for many years.

It is the feature enhancing fork [0] [1] of Putty.

0, https://github.com/cyd01/KiTTY

1, http://www.9bis.net/kitty/#!index.md

See https://github.com/kovidgoyal/kitty/issues/9#issuecomment-41... and https://news.ycombinator.com/item?id=13342497 .

I don't know what Reddit thread is being referenced. The only Reddit thread that I found was making fairly juvenile and crude suggestions for alternative names and not talking about the author.

The semantic space of software project names is filling up while simultaneously contracting. It's time to accept that all names going forward are going to have collisions and get on with life

Like that dude who had a go project that bowled over by Google Golang

E: found it!

https://github.com/golang/go/issues/9

To me, that incident was one of the first times I really started thinking "Google really have gone evil". I know, I know... it's "just" a name of a programming language. I don't care: it's the principle of the thing. The name was taken, and the only correct thing for Google to do when he stepped forward, was to change the name. That they chose not to really tarnished their image in my eyes, and still does to this day.

It's a shame that the other guy wasn't in a position to / willing to / whatever, sue the pants off of Google at the time.

It is quite a stretch to begin thinking of a company as having turned evil because of that issue.

As a minor detail but nonetheless I think makes a difference, the name of the other language was "Go!", not "Go". That makes the similarity in line with C#, C, C--, C++ and F, F#, F* and several others. Yes in some cases these languages are inspired by the others and in some cases not.

Because the only way this whole thing went down the way it did is if either

A) nobody did the due diligence of checking existing projects with similar names (so negligent as to be evil) or

B) they did the due diligence, found his language and decided "well he probably doesn't have the resources to be any sort of issue for us" directly considering the existence of others only for personal gain with no consideration for consequences for others (straight up evil)

They eventually closed the issue with "Status changed to Unfortunate."

Both names are terrible!

Ironically hard to google, hah. "Golang" is a bit naff, and doesn't seem to pick up everything, at least last time I was deep in Go-land

man, mccabe's snarky response to that first guy who immediately replies "references?" to his initial post (ah yes, classic HN "citation needed" guy in the flesh) is hilarious. i want to tell a bunch of google engineers who unrepentantly stole my programming language's name to go "google (sic)" the book i already wrote on it too =`(. i'm sure that went wayyyy over that dude's head, but i'm here for your 11 year-old snark, mr. mccabe =)

oh man, just noticed that the bug was immediately closed and marked "unfortunate"... how douchey is that? unfortunate for mr. mccabe, i guess, that he got in the flight path of the google Dont Be Evil TM 747 jumbo jet (lol).

It's significantly less forgivable when it's another project in the same category of software.

I don't mind overlapping names as long as they're in a different name space, but it looks like these are both some form of terminal emulator program, so I don't know how you would reasonably disambiguate them.

these terminal programs really need to pick less WiTTY names...

This Kitty terminal isn't new. Going by the history on GitHub, this terminal predates the one you linked by a couple years.

You've only looked at this superficially.

First commit of Kovid Goyal kitty in October 2016:

* https://github.com/kovidgoyal/kitty/tree/de072b3b423ad114cc4...

Hacker News post about the KiTTY fork of PuTTY in September 2011:

* https://news.ycombinator.com/item?id=2979382

And that's not the earliest for the latter.

Thanks for the correction, good to know.

You are mistaken. KiTTY project started in 2003[1] while the first commit in kitty-term was in 2016.

SO question from 2012 asking about KiTTY: https://superuser.com/questions/410398/any-simple-way-to-add...

[1]: http://www.9bis.net/kitty/#!pages/0.71.md

Kitty's ability to display is quite fun (although it is definitely not the first terminal editor to do so).

A while ago I hacked a Julia package together so that functions that emit an image (for example a plot that would usually be displayed in a Jupyter notebook or a new window) show that image in kitty. It's still a bit rough, but it is surprisingly easy to write something integrates with a lot of packages: https://github.com/simonschoelly/KittyTerminalImages.jl

Thanks for having created that package, I am a regular user and I think it's excellent!

Don't all terminal emulators have the ability to display something though?

Nope, unless you're thinking of something like `catimg`, which wouldn't really work well for the linked gplot example. `xfce4-terminal` off the top of my head is an example of a terminal emulator that supports neither sixels nor kitty's protocol.

https://github.com/posva/catimg

https://bugzilla.gnome.org/show_bug.cgi?id=729204

Works great, thank you!

Not much of a contribution to the conversation, but I've been running kitty for ~two years and it has served me really well. It's reliable, fast, great. Only thing I'd wish it had was (more intuitive) way to re-arrange panes / layouts.

There was a big update recently that added better split pane support. https://sw.kovidgoyal.net/kitty/changelog.html#id9

well, that's it then. No gripes anymore!

I have been running Kitty for just as long but never use any layout and pane features. Serious question - why would one want to do window management in their terminal vs something like tmux or screen?

I use it. It's nice but it causes a ~30 watt spike in power usage whenever I put it in the foreground. Laptop users, be advised that this terminal could drain your batteries.

Do you have a dual GPU laptop? Kitty uses more CPU than say Konsole but I can't imagine it using 30w - likely it wakes up the dGPU when it shouldn't. I use it all the time on my ThinkPad with iGPU and haven't noticed any big battery differences from when I was using Konsole.

Yes. I have a Clevo laptop with an nvidia GTX 1070 GPU. I'm using the proprietary drivers and have hybrid graphics disabled in the firmware settings. I monitor the power usage of the GPU at all times. It idles at ~8 W and spikes to 30~40 W every time Kitty is in the foreground. That's comparable to running RetroArch with some shaders.

The Intel GPU caused kernel panics during video decoding last time I tried using it so I do not have any power usage data for it.

kitty uses shaders, so I guess that might be it.

I suppose there are only a few words that end in tty, but I was a little surprised this wasn't a GPU enhancement to the already nice Kitty [http://www.9bis.net/kitty] which is based on Putty [https://www.chiark.greenend.org.uk/~sgtatham/putty/], both Windows programs.

Been using kitty for a while now; here are some interesting details about that:

- When I change my vim colourscheme, I can have it automatically propagate the new background colour to the terminal to avoid having an ugly border around it. This is specially important when using it with a padding around the edges.

- When I switch between light and dark mode (I have a script for that) I can do so by changing a single include statement in a config file and automatically propagate the new colours to all open terminals.

- I more easily have a uniform terminal theme as the configuration is done with files which support includes, so I can have the bulk of my configuration in a separate rc-files git repository and only put some local adjustments in the default config file.

- The hardware acceleration isn't really all that noticeable.

- 256-color support is a clear improvement compared to gnome-terminal, which I used before.

- Support for tabs and windows seems pretty ok, but I rarely use it because I'm already used to tmux which works seamlessly over SSH and lets me detach and re-attach sessions. Probably a neat feature if you won't use tmux though.

- Zoom in is = instead of +, which means I don't have to press/release the shift key between zooming in and out when looking for the perfect fit.

- Being able to set padding and opacity on the fly is pretty neat when you're figuring out a good balance of how much code you want to see on screen at a time.

How do you propagate config changes to open terminals?

https://github.com/DarkWiiPlayer/darkrc/blob/master/bin/upda...

Note that the regex is very simple because I have two separate config files for colours in light and dark mode. Having the colours in the main kitty config file would obviously require being more picky about what lines to feed into the pipe.

How does this compare with Alacritty?

Alacritty has fewer features (by design) i think. Alacritty is more supposed to be used with something like screen or tmux while Kitty has tabs, splits and so on.

My understanding with Alacritty is that functionality like tabs would be up to downstream software to implement. So I create a new project called "UltraAwesomeTerminal" and use Alacritty as a library.

Is that accurate? I'm kind of unsure.

Our position is that tabs is the job for your window manager. I, for example, run `i3` which makes implementing tabs in Alacritty a non-issue for me.

I use tabbed for Alacritty, it works in any WM.

https://tools.suckless.org/tabbed/

Thanks for the reply! That makes sense. And sorry for the late response.

Alacritty doesn't have ligatures[1] support. I like the project and wish it success, it has a nice, clean code, somewhat minimalistic, and clear goals. But so far it lags behind kitty.

[1] https://github.com/alacritty/alacritty/issues/50

Alacritty + Starship is heaven

https://starship.rs/

There's simply no comparison. I wrote a program that prints mpeg videos to the terminal, and used it to stress test just about every terminal out there. Nothing goes faster and smoother than KiTTY. Alacritty is no exception; in my experience it had glitchy rendering for certain characters and lagged. The only terminals I've seen that come close to KiTTY in terms of textmode graphics performance and overall quality, are probably PuTTY, Gnome Terminal, and Terminal.app. The only bad thing I could say about KiTTY is it glitches for me on occasion when rendering Emacs windows side-by-side. See also https://justine.storage.googleapis.com/printvideo.html

Meanwhile I'd just use the framebuffer here with tmux, and a parallel tty with my $HOME/bin/fbplayer script:

    #!/bin/sh
    clear
    setterm -cursor off
    echo -en "\e]P0000000"
    mplayer -really-quiet -vo fbdev2 -vf scale=:-1 "$@"  
    setterm -cursor on
    echo -en "\e]P01d2229"
    clear

Add mailx, sacc, bollux, irssi, bitlbee, cmus, fbpdf2 and fim and I won't use X any more. Even mednafen and ScummVM work with

    export SDL_VIDEODRIVER=fbcon

Try it.

Do you have a browser? Clipboard? They're the things that keep me using X.

On browser: lynx and links work on HN. Not many sites. will work, but at least with links -g you'll have images in a second tty (I use the first one with tmux). And you'll get far less distractions.

Youtube: mplayer on tty2 + youtube-dl/streamlink/mpsyt.

Reddit: lynx gopher://gopherddit.com (r/o), tuir (r/w).

Clipboard: gpm. Crude, but it's something.

Personally when I tried both (I used a dozen of different terminal emulators to test them out and see which one I like the best) it boiled down to the fact that I had some test file for Unicode characters that Kitty (and I believe Sakura?) were the only terminals that could render it properly, Alacritty was second best but it was pretty broken. Other than that feature wise I didn't feel like either of them was missing anything (for my personal use case). Alacritty has a bit faster startup time though which can be noticable.

Which characters? Is this one of the common test files that float around, like the UNSCII one? Or a private one of your own?

It was just a bunch of Unicode characters that I picked at that time to test various terminal emulators, I'm not sure what was it specifically since it's been a while (and there's a chance that Alacritty works fine now), but likely some sort of emojis and Asian scripts.

It is a shame that you cannot remember, because I do keep my eye out for this sort of thing. If it's a font problem, then it's not that interesting to me. And most of the Unicode problems tend to be either (a) people erroneously assuming that "private use" is the same for everyone, or (b) the usual problem with code points that didn't have defined widths and suchlike in earlier versions of Unicode. But very occasionally there's something worth noting.

Alactrittys font rendering was always a bit different than the rest of my DE which causes it to look jarring. Haven't seen this issue with Kitty.

I liked Alacritty well enough, but it doesn't support ligatures. Kitty does, so that's what I use.

I went the same way, but in the long run kitty's startup delay of about half a second or more just felt too sluggish for me. Luckily st can now be patched for font ligature support, and it starts up ten times faster while I don't notice any performance difference in other cases; it seems GPU-based rendering in terminals is a bit overkill in the majority of applications.

Oh. I haven’t noticed any startup lag personally. I’ll give st a try and compare.

It supports tilde tabbing on osx

Perhaps run them both and let us know.

I'm going to post this as a top-level comment rather than an answer, so that nobody feels under attack. I don't know Kovid other than from being a Calibre user and from reading about him (mostly here on HN). But I do find many of the posts in this discussion, way more insulting and close minded than anything I have read written by him.

I switched to Kitty as it was one of the few terminal emulators that supported font ligatures. So far I'm quite satisfied. It's smooth and fast.

One of my favorite features of Kitty is its support for printing images in the terminal through its graphics protocol, meant to be a replacement for libsixel. The spec's worth a read - there's few projects linked there that implement it.

https://sw.kovidgoyal.net/kitty/graphics-protocol.html

Other seemingly more minor (but which will possibly be more widely used eventually) features are different forms of underline, selectable through sub-parameters to SGR 4. I've already put this into my terminal emulator, although that version is not released yet; it exists in LibVTE and several other terminal emulators; and the Windows Terminal people also have a backlog item for it.

* https://github.com/microsoft/terminal/issues/7228

I quite like that as well, it works very well in ranger.

However, I was in awe at libsixel's support of animated pictures. I'm not sure how that's done, probably just re-drawing still images? That got me thinking: as kitty supports displaying images from shared memory, couldn't it just expose a buffer for the app to draw inside?

Going further, it would be an interesting experiment to make the terminal a fully working "wayland compositor", maybe with some extensions to control buffer placement with escape codes.

What would it bring? It seems that the most stable API for application development has been the command line interface. Going further, I'd be interested in running a terminal emulator such as kitty as the sole application on a TTY, like a fbcon replacement.

I use and love Kitty. One of my favorite features is the ability to yank text by word anywhere in the terminal and insert (https://sw.kovidgoyal.net/kitty/conf.html#shortcut-kitty.Ins...). There's also different hints that can be enacted allowing you to narrow your focus to specific items such as paths and URLs: https://sw.kovidgoyal.net/kitty/kittens/hints.html.

I know that there are TUI tools that could make this easier, but whenever I was working on Kubernetes getting information about constantly changing pods was definitely the place where I yanked/pasted more times than anywhere else.

Try tmux with my extrakto

https://github.com/laktak/extrakto

That is interesting and worth checking out. However, I'd say one of the benefits of using a featureful terminal is the ability to not have to use tmux. Am I understanding this correctly in that you have to use this inside tmux? If so, the demo on the github page is a bit misleading without the default tmux bar at the bottom...

Just this week I started using kitty as my terminal. Overall I have liked it and I really love the icat kitten so I can "cat" image files directly in my terminal.

I haven't yet figured out how to change my font color from white to amber (which has been a preference of mine). I've tried just setting color7 and color15 to the amber hex color that I like, but that isn't doing it.

The other thing I can't figure out is how to get it to stop updating the window title. I know most people probably prefer it, I just don't want it to change every time I change directories. There is an obvious preference for that in gnome-terminal and I can't figure it out in kitty.

Check out termite, it is, unlike Kitty, a no-bloat program. As of kitty, just check out it's source repo to get an idea of how messy everything it is, not to mention the horrible attitude of the author, it's like Linus^4

I agree. I had to argue with the author to convince him it was the right thing to do to fix a consistent crash on wayland because kitty wasn’t using the api right.

Previously: https://news.ycombinator.com/item?id=22673768

I've used Kitty daily for years and it's brilliant. It just does the simple things really well and crazy fast. Can't really find fault.

Not that xterm is "Eight Megabytes And Constantly Swapping"...

True, but every now and then when you accidentally run tree against your entire ~/projects directory, it finishes in a fraction of a second lag-free. Even my old terminal emulator of choice, urxvt, couldn't match that.

Strange, I always found Kitty (or Alacritty) extremely laggy for those use cases, plus firing up the fan of the computer.

Also even though constantly running at 60 FPS, input lag is in the order of 300ms.

Kitty is indeed great and I can corroborate the high performance by joining at the macOS activity monitor. Almost zero even with high speed scrolling.

I kinda wish there was a GUI configuration method though. But considering it's a terminal emulator it's not a big deal.

I'm also a macOS Kitty user. The config did take a minute to get used to, but the docs are pretty clear and it's really nice to be able to add the config to your dotfiles repo and have it available on all machines. My favorite feature though is the auto layout: it's really nice to be able to quickly switch to different layouts without having to manually move things and also not have to worry if something is going to fit into the space I have. The perf is nice too!

One thing I never figured out was how to properly set the terminal when on remote machines: it defaults to xterm-kitty, which led to problems trying to run nano on those servers. The only thing I dislike is the look of the tabs: compared to the OS native tabs it's a bit underwhelming, but they work fine.

For servers that have older versions of ncurses, you can run this command from kitty to install the xterm-kitty terminfo files on the remote host:

    kitty +kitten ssh user@host

Thanks! Seems to resolve the term issue albeit at the cost of having to remember to use the kitten instead of standard SSH.

Once the terminfo files are installed, unless the target system has restored from a backup or something, you can just revert to using plain ssh.

Or you could lobby your sysadmins to update terminfo past version 20181017 and use 'term kitty' in your config. It's too bad the people involved can't agree on using either "xterm-kitty" (Kitty author's preference) or "kitty" (ncurses maintainer's preference) for the TERM value.

https://github.com/kovidgoyal/kitty/issues/879#issuecomment-...

See https://news.ycombinator.com/item?id=22683277 .

Solution is in the FAQ: https://sw.kovidgoyal.net/kitty/faq.html#i-get-errors-about-...

I just add the following to my kitty.conf and have never had any issues with TERM:

    term xterm-256color

It's usable but i had a lot of issues. Copy pasty looses newlines, redraw issues in mutt, etc. It is absolutely "forbidden" and unsupported by the kitty author to use any other term than xterm-kitty.

The author offers a solution in the FAQ: https://sw.kovidgoyal.net/kitty/faq.html#i-get-errors-about-...

Kitty normally identifies itself as 'xterm-kitty' (in the environment variable TERM). The problem is that most terminal programs don't know that terminal type and use some less featured fallback. Most modern terminal implementations use a workaround it by pretending to be 'xterm-256color', with varying degrees of actual compatibility. (That's also what changing term in kitty.conf does).

Kitty's author really wants you to use the traditional solution of telling (programs on) the remote host what your terminal is capable of and how to use the capabilities by installing a new terminfo entry in ~/.terminfo/x/xterm-kitty on the remote side, which is what `kitty +kitten ssh [remotehost]` does. (It needs to be done only once, unless the file gets wiped on the remote end).

With the GLAMOR rendering layer, xterm has GPU acceleration. And if you enable the speed hack it's as fast as any terminal emulator. But compared to limping along at 300 or even 9600 baud, all our terminals are plenty fast, so I prefer accuracy over speed.

wasn't glamor slow as hell?

Which was that speed hack BTW?

Setting the fastScroll resource to true allows xterm to emulate the behavior of later terminal emulators, which discard screen updates for speed purposes ("speed" being measured by "how long does it take to cat a large file to the terminal in its entirety").

Before this feature, xterm was considered the slowest terminal emulator because it updated the screen with each write, the way real terminals do. But now you can turn on fastScroll and amaze your friends with fast cat times.

Glamor was slow as hell. It got better when Keith Packard stopped calling glFlush() after every draw call.

Thanks, it works well.

> You can install pre-built binaries of kitty if you are on macOS or Linux using the following simple command:

> curl -L https://sw.kovidgoyal.net/kitty/installer.sh | sh /dev/stdin

This kind of install freaks me out. Who knows what the code could do? What is the uninstall procedure? How do I dry-run and see what changes it wants to make onto my system before accept them? Can they not just offer a .deb, snap, or appimage?

It's packaged in most distributions, so maybe just use those packages? Also, there are binaries on the Github release page: https://github.com/kovidgoyal/kitty/releases , just download and put them into $PATH manually?

Given all that, I find it perfectly acceptable to offer a curly install script as an additional option for users who don't think those scripts are as problematic as people often claim on hackernews or reddit (I personally am perfectly ok with them -- I have to trust the author of a piece of software anyway, so why not also trust the installer that comes from the same source/host?).

I’d suggest reporting this upstream, but, well…

https://bugs.launchpad.net/calibre/+bug/885027

So instead I’ll suggest avoiding it altogether.

Just curl > kitty-install.sh and read it?

I don't want to parse code, I want a list of changes to my system and to be assured of an uninstall method.

How does performance compare to st? Has any one tested both?

I haven't used a considerable amount of time using st (I think for a total of 2 days on a VM?) I liked st just fine but I found the day-to-day performance of kitty really solid.

It feels like kitty takes _slightly_ longer to start up but it's still a tiny amount of time.

There's also the different configuration options, kitty has a config file but st (if memory serves) needs to be recompiled for changes.

I've found that initially kitty can have trouble rendering fonts with correct spacing but that takes a couple of minutes to tweak to your liking. And I think the colour configurations are a little more complex? I haven't had to change the config for a while though.

The GPU acceleration does make stdout much faster if it's unbuffered (in my experience) and on a 144hz monitor it looks so much smoother.

Hopefully that's enough of a comparison? Sorry I couldn't give more feedback, as mentioned I've only used st for a short time.

> It feels like kitty takes _slightly_ longer to start up but it's still a tiny amount of time.

For me the difference was large enough to switch to st. Kitty's startup takes 5-10 times as long and it's very noticable for me. As I use terminals a lot this meant a delay every time I opened an instance.

But this is a subjective thing of course. I have all the features I need with st and use a terminal multiplexer for the rest.

You can also use kitty -1 to use a single instance of kitty although the startup time is already so small I doubt you could tell the difference without measuring

I use both, but don't really feel like there is a useful comparison.

My lightly patched st /feels/ better IME, but it doesn't have anywhere near the same featureset. kitty has its fancier font support and cool kittens which make the comparison very uneven.

I limit my kitty use to a single long running instance as my vim terminal, taking advantage of its far better rendering for pretty symbols and inline images via the icat kitten. For everything else I find st/urxvt far more useful, in spite of the occasional rendering errors and font selection problems. Even going so far as to fiddle with sxiv's Xembed support to weakly imitate kitty's icat from time to time.

While this doesn't have test for everything you might care about, https://github.com/alacritty/vtebench could help you answer this question on your own machine.

Simply run the tool within the terminal under test. It's quite easy to use.

I've used both. I have no figures but kitty feels at least as fast as st with infinitely more features and a proper configuration system.

I switched to Neovim as a daily driver last week. The latency, at least on mac, was annoying. Changed terminal emulators to Kitty and now everything is snappy.

... and it's wayland-native!

Just a quick question while I'm here - what really is the point of using the GPU? Surely the CPU is adequate for a terminal's modest needs?

... I have an NVidia POS on my lappy but I don't game or use the GPU at all - in fact I removed the drivers so it doesn't drain the battery at all.

I dont like their approach in the issue of "Kitty Only uses Dark colors"[1]

1. https://github.com/kovidgoyal/kitty/issues/197

he seemed extremely reasonable to me. he explained that

* the spec said bold text and bright colours were two different attributes

* the fact that some terminals rendered the bold attribute as bright colours prevented applications from actually using bold text

* he did not want kitty to be part of the problem

furthermore, he explained that in a way that respected the person opening the bug - he didn't patronise them or say that it was his decision not to do that because he didn't care to and they could take a hike; he actually detailed his reasoning and why he was philosophically opposed to it. i might have read through that and decided that okay, kitty was not for me, but i would not have felt the author was being unreasonable about it.

For what it's worth: The issue about bold and blink performing colour changes is widespread across terminal emulators. It has come up for Windows Terminal, for example, and the libVTE people have already addressed this. In reality, the only terminfo entry that even does this any more is the linux-16color one for the built-in Linux terminal emulator.

There's a sea change happening here. It's a post-VGA world. Boldface means boldface.

* https://github.com/microsoft/terminal/issues/5682

Using bright colours for bold made sense years ago when we had much lower resolution displays. The fonts used back then were pixel based and tiny. (Think 8x8 or 8x7) It often wasn't possible to be make a bold version of a pixel font that size. You just can't do fat bold lines and not end up with a blob.

That argument flounders on the fact that in the pre-VGA (more strictly pre-CGA) world boldface and blink did not change colours, either. There was a whole world of monochrome video terminals. And, furthermore, the fonts during the heyday of the home computer revolution were boldface in several cases, including the BBC Micro's graphics mode character set, even though they were smaller than 8 by 8.

* https://damieng.com/blog/2011/02/20/typography-in-8-bits-sys...

I wouldn't call it very reasonable. I mean, I understand him, and he is correct in the essence. But...

> whatever you are using to generate that particualr text output is incorrectly using bold formatting for bright colors

The problem is that this is pretty much every app out there. All small utils we have up to date, all colorschemes, they all are made with this in mind. And most (all?) other terminals do behave this way. This is de-facto standard. If he doesn't want this behaviour himself, that's fine, he wrote this app for himself after all. But refusing to make it configurable is just stupid and arrogant. This is not really a proposal for a new feature, this is broken compatibility with everything written in the last 30 years that uses this feature. And his response wasn't "respectful" is the slightest. If anything, the guy himself seems to be enough reason to avoid using this thing.

> that's fine, he wrote this app for himself after all. But refusing to make it configurable is just stupid and arrogant

Ad hominem much?

He wrote the app. If you want features, fork the code and add them yourself. Name-calling and demanding that the auther implement your pet feature is ... self-obsessed.

Do you also call your neighbor stupid and arrogant for not mowing your lawn?

Kovid Goyal is a person with forcefully presented opinions. I've submitted bugs to Calibre before, so I can vouch that his style remains the same.

Yeah. I've tried the Kitty last year and when my colors showed different I found this Issue already closed and with some strong words/opinions from him. Hard to like it.

He's not wrong, though. He's following the spec, and users are asking him to violate it to be compatible with programs which also violate it. If everyone just followed the spec, however, colors would work beautifully for everyone all the time without anyone having to worry about weird edge cases in specific programs.

If a program you run in Kitty displays incorrect colors because it's hijacked bolding instead of implementing proper color support, you should absolutely go and make the issue known to the authors of said program as they are the ones who fucked up by violating the spec in the first place.

The whole point of standards is to make the relevant technologies more accessible. Developers too often break spec without regard for accessibility, all in the name of cool new features. This is bad, and it makes sense to discourage it by simply enforcing the spec.

The standard says "bold or increased intensity". I see brighter colors on dark background (what everybody does) more in line with it than darker colors on dark background (what Kitty does).

> He's following the spec, and users are asking him to violate it to be compatible with programs which also violate it.

Users are asking for a configuration option to behave the way every other terminal works, and the way everyone writing software that runs in terminals that relies on any behavior relies on terminals behaving.

It is not the way that every other terminal, or indeed terminal emulator, works; nor is it relied upon by "everyone".

For starters: Softwares that use terminfo, and anything built on top of it such as ncurses, only use this for one specific terminal type, linux-16color. No other terminal type in terminfo changes colour this way.

The idea that boldface and blink change colours has been on its way out since the 1990s. XTerm has had the ability since 1997; and while its XTerm personality does not, its UXTerm personality defaults to boldface meaning boldface. Of course AIXterm, at the start of the 1990s, had SGRs 90 to 97 and 100 to 107, and did 16 colours that way, not with boldface. The Windows Terminal issue shows some of how far this notion has extended in the more than a quarter of a century since.

It isn't a VGA world any more, and people aren't assuming VGA semantics any more. Ironically, before VGA, in the world of MDA et al., as seen from the SCO Console, people didn't assume these semantics back then, either. There has been a sea change. boldface means boldface. And blink actually means blink (or nothing, depending from what one's views on blinking as a GUI mechanism are).

* https://github.com/microsoft/terminal/issues/5682

* https://github.com/microsoft/terminal/issues/7388

>behave the way every other terminal works

Then use every other terminal, or make your own.

I find his replies polite, firm and to the point.

Just because his position does not match other folks, it does not mean he is wrong.

Yes absolutely. People sometimes assume that you have to implement feature XY, just to lament 1 year later that another software is not that bloated. I like people with a strong opinion and if i don't like it i use something else.

Treating accessibility like an aesthetic choice...

Not really. Did you read the issue thread? He's enforcing the spec. If anything, that improves accessibility since that's what specs are for, maximizing accessibility.

Aside from all of the debates, it's just the hardest of hardcore terminal opinions to be militantly hardline on not only going the opposite of the suckless/st default,[1] but to double down on not even implementing the means to toggle it.

I don't think I respect it, and it's one of many reasons why I bounced off kitty (and certainly helps explain why I bounce off so many design decisions in Calibre), but there's still a spark of awe in seeing it happen in public.

[1] https://st.suckless.org/patches/bold-is-not-bright/

You should ask for your money back.

I was surprised how easy it was to switch to kitty from xterm. I just copied my colors in, configured cursor/foreground/background/text settings, bam done. Dropped a star on the Github and I'm gonna use this from now on!

Update: I switched back to xterm. There were just some weird drawing issues when using it with `ne` and ssh had real issues.ssh is fixable but... eh... I don't wanna have to put time into configuring a terminal emulator further than configuring colors.

for those into these things, i just started using cool-retro-term which i just love working in now :) seems i must still try kitty though (heard good things from the nnn file mamager devs, itself also a sweet project)

Kitty is the only thing I miss from Linux since I'm using WSL 2.

I use kitty on WSL via vcxsrv but I had to hack the OpenGL support. X410 should work.

Have you tried running a x11 server on wsl? I heard that it works with a bit of linux-foo, might work for kitty

icat and diff programs are nice but I've never thought other terminals needed to print or scroll faster.

Then your workflow is different from other people who do need this feature.

Can you explain? I don't understand it either. I use iTerm2 on a modern mac; does that mean I don't have the performance problems being addressed by kitty and alacritty?

It is useful with some badly written build systems that think they have to write every invocation of gcc to stdout. Like every badly written Makefile out there. Or `cat myapp/log/yesterday.log`.

You can work around both but it's clunky. And also it's a thing that's not a must have, just a nice(r) to have.

tmux -CC mode support? Stuck on macOS for iterm2 as that’s the only terminal that seems to have it.

Can someone tell me what I get (on MacOS) with this that I don't get with iTerm?

Less customisation, awkward configuration, about the same performance (from my personal empirical analysis) if you have enabled GPU rendering on iTerm, higher memory footprint (might have improved since I tried it last), no `tmux -CC` integration, awkward tiling...

This is obviously my personal opinions and observations, but I tried it for a couple weeks and ran back to iTerm.

Has someone measured the input latency, compared to xterm and urxvt?

How does it compare to the new Windows Terminal?

It doesn't support windows, so it can't really compare.

all you need to do is to learn how to program this terminal so that you can program on it.

Kitty has been around for years. How is it just now landing on the HN front page?

My small very unscientific benchmarking on a high spec last gen Macbook pro 13 (partly consisting of watching Activity monitor while scrolling fast) is that Alacritty performs better than Kitty (despite Kittys team claiming the opposite) both in terms of frames per second and in terms of CPU use. Kitty uses maybe 30% more CPU with fast scrolling despite being slower.

Alacritty definitely isn't without flaws of its own though. There are no smooth ways of handling several instance (at least on Mac). You have to bind a shortcut to creating a new Window which will appear as a new icon. And! a new window can take 10 seconds or so to be completely responsive. I don't think I ever experienced a terminal emulator window taking more than a second to open before on any system with any emulator.

Reply on news.ycombinator.com