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.
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.
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.
Debian systems have had an rxvt-unicode-256color entry for approaching 10 years, now. FreeBSD for about the same.
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?
That solves that.
infocmp -x xterm-kitty | ssh myserver tic -x -o \~/.terminfo /dev/stdin
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.
alias ssh='TERM="xterm-256color" ssh'
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.
> 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
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.
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.
double click do word selection, triple click do line selection , don't know if this is configurable
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.
From that Blog:
>>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
I hope that helps
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.
Sakura is pretty nice - options can be changed in the gui/menu - config file is stored on disk.
Couple of things to note here:
1. I'm pretty certain that when he says he can maintain python 2 he doesn't mean python 2 but rather the python 2 version of calibre. Note that he is not a native English speaker.
2. He never actually said he wouldn't merge python 3 code. Apparently people never read past comment #2 up until comment #4:
> Kovid has stated numerous times that any patches which work towards python3 compatibility without hurting python2 functionality or performance would be happily accepted. Oddly enough, no one has ever taken him up on that, though a number of people have insisted it is very important that he himself do that work.
3. There are plenty of people in this planet that actually don't want a UI. I've been happily using rxvt-unicode for ages because of its perl scriptability. Kitty works well and has python scritability. It's way faster at rendering new windows than alacritty and has some other features that rxvt-unicode had and other terminals don't have.
There have been plenty tiling WMs spawning left and right with a pretty significant but also niche following. Not everyone wants bloated GUI's.
Yes, but there's plenty of people to do. And, in case you missed it,
> By all means, Kitty is amazing if you get into its model [...]
In this case the kind of stubbornness that creates an opengl terminal emulator.
There is an intricate tilework pattern in the main hall  where the architect put 1 tile in wrong, on purpose. The reason was, according to him, that only god could create something perfect.
What I get out of this is that it's impossible (or rare) for someone to conceive of an architecture so grand and dearing unless you mentally consider yourself a near god.
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'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 is the feature enhancing fork 
 of Putty.
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.
E: found it!
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.
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.
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)
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).
First commit of Kovid Goyal kitty in October 2016:
Hacker News post about the KiTTY fork of PuTTY in September 2011:
And that's not the earliest for the latter.
SO question from 2012 asking about KiTTY: https://superuser.com/questions/410398/any-simple-way-to-add...
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
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.
- 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.
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.
Is that accurate? I'm kind of unsure.
setterm -cursor off
echo -en "\e]P0000000"
mplayer -really-quiet -vo fbdev2 -vf scale=:-1 "$@"
setterm -cursor on
echo -en "\e]P01d2229"
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.
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 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.
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.
Show me a better program in that class (Calibre)
>It has no ability to self-update
>It has a horrific UI
Well i don't like it too, but it's obvious that he likes it, since you talk about "Self Update" i assume you use Windows...to bad now you have two horrible UI's
Also even though constantly running at 60 FPS, input lag is in the order of 300ms.
Which was that speed hack BTW?
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.
I kinda wish there was a GUI configuration method though. But considering it's a terminal emulator it's not a big deal.
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.
kitty +kitten ssh user@host
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.
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).
> 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?
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?).
So instead I’ll suggest avoiding it altogether.
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.
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
But this is a subjective thing of course. I have all the
features I need with st and use a terminal multiplexer for the
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.
Simply run the tool within the terminal under test. It's quite easy to use.
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.
* 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.
There's a sea change happening here. It's a post-VGA world. Boldface means boldface.
> 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.
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?
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.
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.
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).
Then use every other terminal, or make your own.
Just because his position does not match other folks, it does not mean he is wrong.
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.
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.
This is obviously my personal opinions and observations, but I tried it for a couple weeks and ran back to iTerm.