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.
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.
> 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?
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`?
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.
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 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/“
> 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.
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.
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.
> 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.
> 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.
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....
This is getting ridiculous. Goyal isn't the terrible person you make him out to be, not by a long shot. Somehow recently HN commenters have had a lot of fun cherry-picking every single instance of him not communicating perfectly sharply, in his impressive multi-decade-long career as an open source maintainer and giver of free things. Stop doing this please, you're making the world just a little bit worse.
As GGP, I feel like I should clarify: I agree with this. No knock against Kitty or Kovid - I used to use Calibre extensively, and he's maintained two beloved open source projects very well. My only point is that Kitty is a very opinionated piece of software, and one should keep that in mind if they want to use it.
OK so I saw this when people started jumping on bashing the Calibre author. They posted this[1] link as a reference.
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.
When I come across stories of these kinds of eccentricities I always remember why my mom always said: "Some people's bad points are also their good points."
In this case the kind of stubbornness that creates an opengl terminal emulator.
There is a story like this in the Netherlands with Radio Kootwijk [0], and old, architectually stunning radio station from colonial times.
There is an intricate tilework pattern in the main hall [1] 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.
Wow, it's been a while since I've heard Zed's name in the wild. That aside, the author of Kitty is Kovid Goyal - you may remember him from other such impressive open source tools as Calibre.
It's amazing how entitled and ungrateful some people are. If you don't like it, don't use it, or fork it, or patch it, or whatever. Just don't spew vitriol at someone developing free things for the benefit of others.
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.
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).
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.
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
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)
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).
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.
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
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.
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.
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.
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
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 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.
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.
You really gotta get that chip off your shoulder. Living your life intensely hating someone of no real consequence in your life is poison for your soul. Even if he's a bad guy, fine, let it go. If it's bad software people will quickly realize it for themselves and move on too. But here you're making sock puppet accounts and writing giant walls of text about some random OSS terminal author. That's seriously not healthy.
You sound like a person who just opened a account to lament about another person.
Show me a better program in that class (Calibre)
>It has no ability to self-update
WTF??
>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
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.
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.
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.
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.
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.
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.
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 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 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.
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.
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.
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?
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).
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.
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.
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)
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.
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.
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.
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.