Kitty 0.17 – GPU-accelerated terminal emulator (opens in new tab)

The relevant Github issue is also quite memorable: https://github.com/kovidgoyal/kitty/issues/9#issuecomment-41...

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

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

Looking at the rest of the website, I think it fits with its theme... I don't think it's been majorly updated at all since 2003.

It really should not be "xterm-" anything. This is another misnomer.

* http://jdebp.uk./Softwares/nosh/guide/commands/TERM.xml#MIS-...

* https://invisible-island.net/xterm/xterm.faq.html#other_vers...

The correct terminal type, per Dickey terminfo, is "kitty". (The PuTTY variant KiTTY is apparently also "putty".) And the terminfo database lends itself both to copying individual records and to having extra records in one's home directory.

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

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

> On BSDs it doesn’t work as there is no terminfo support

ncurses from FreeBSD Ports is built with terminfo, but the ncurses from base uses termcap. Kind of a mess :)

Most application ports have USES=ncurses without arguments, which means they will prefer the ports ncurses — if it's installed at build time. Official binary packages are built without it installed of course. So rebuilding the ncurses apps you care about would make them use terminfo.

Also you can convert terminfo to termcap: https://invisible-island.net/ncurses/man/infotocap.1m.html

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

I use tmux in kitty. I rarely have to scroll and when I do, I can certainely do without smooth scrolling. Usually I just use tmux to search and jump through the output.

I was a heavy terminal user already but running macOS at work and linux at home, I got really annoyed by having to memorize different shortcuts. So I just gave up and started using tmux. Now, no matter what platform I am on, the behaviour is pretty much the same. I just use Kitty because it performs really well.

I work around the scrollbar issue by having keyboard shortcuts to open the full scrollback in vim, either on top of the current view or in a new tab. I was surprised how little it bothered me, and nowadays I even prefer it. You get all the text control in vim which is so much nicer than the scrollbar approach.

Scrolling itself seems smooth for me in general.

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

Alacritty is inspired by kitty; kitty being GPU accelerated (and alacritty also being GPU accelerated).

The major difference between them is that alacritty is written in rust (and has a really nice config that auto-reloads) and kitty is written in C with a smattering of python.

I feel like Kitty has less strange bugs due to its acceleration - e.g. font rendering is more consistent with the rest of the OS, I've had less issues with mouse and keyboard support, scroolback works, etc. It just feels like a more mature project while still providing most of the benefit.

I tried Alacritty some months ago also because of a HN post.

I think it lacks features compared to Kitty. At the very least tabs for multiple sessions and support for a transparent background made it not an option for me.

Kitty has replaced the standard terminal in Ubuntu for me, and I am quite happy with its performance and Unicode support.

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

Similar situation here. At some point opening/closing tabs got really slow for me in iterm2 and I couldn't find a way around it. With kitty it's pretty much instant and for me worth the lack of other features.

Also, a whole lot of it is written in Python and I actually contributed smaller changes in pull requests. It feels good to be able to just change things.

I did this too and used kitty for maybe more than a year. I recently switched to gvim and using :terminal though; the font rendering is better and actually I think it's even faster. Give it a try.

P.S. weirdly on Linux it's entirely opposite; vim in an xterm is much faster than gvim.

Huh, I switched to Kitty a year or so ago and then back to iTerm when they introduced GPU acceleration. Turning off ligatures made nvm much more responsive for me.

The problem with BCE is largely that it does not fit with the paradigms of ncurses and terminfo, not that it is problematic in itself. This is alas true of a large number of terminal things, from function keys through "cursor addressing mode" to erasure, whose ncurses/terminfo abstractions do not fit the actual ways that these work.

On both real (DEC) terminals and terminal emulators, background colour erase is settable off and on, with DECECM; so a full-screen application can set the behaviour and know what the colour is going to be, leading to more efficient screen redraws. The ncurses/terminfo model, in contrast, is that the behaviour is fixed on or off, and a boolean (named bce) in the database tells softwares which it is for any given terminal type.

In reality, it is the paradigms of ncurses and terminfo that are the problems here.

* http://jdebp.uk./Softwares/nosh/guide/commands/TERM.xml#MEAN...

I was a happy user of Terminal.app until I got a 4K display, which I run at scaled 2.5K, so effectively rendering 7.5K. With my Macbook Air 2018, this results for example in a FPS of ~13 when scrolling full-screen in Vim with Terminal.app rendering on a CPU, which is super annoying. Kitty brings this to ~35.

I've been using Terminal.app for years (I used iTerm2 before Terminal.app had some major improvements). I switched to Kitty so I could bind a shortcut key to opening a new terminal window--a habit I picked up from tiling window managers. I can't remember if I had other criteria, but Kitty has been surprisingly a quiet workhorse since I switched (I occasionally had TERM issues when ssh-ing).

Depends on your usage but terminal.app is quite a bit slower then iterm2's metal renderer or Alacritty (probably kitty as well but I haven't used it).

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

Not just terminals. So much software is unbearably slow today. Definitely terminals. The only terminal I can really stand is xterm with bitmap fonts.

https://danluu.com/term-latency/

> A graphical terminal emulator should use underlying graphical environment features/libraries for things like hardware-assisted rendering.

I've mostly done OpenGL recently, and I think xterm (which is fast) is an exception in that it uses just X11 primitives, but I also know that some font frawing APIs are very slow. GDI is what I have in mind mostly. So using Hardware more directly (i.e. OpenGL) might be not the worst idea.

I've noticed terminal rendering performance issues when dumping a lot of text. If that's part of your job, it's important to you. For me it seems to come up once every few years and I've poked around at alternatives.

I've also heard about performance issues with high res, large terminals. It's a lot of pixels to throw at the screen and I'm sure most terminal emulators were written with much smaller screens in mind.