1. 47
  1.  

  2. 13

    I was confused for a second there, but this is different from the PuTTY clone named KiTTY (http://www.9bis.net/kitty/)

    1. 10

      Started to build on OpenBSD. A few simple linuxisms (always linking with -ldl, etc.) easily resolved, then I hit

      linux_joystick.c:32:10: fatal error: 'sys/inotify.h' file not found
      

      I think I’ll stop here. I don’t need joystick support in my terminal emulator.

      1. 5

        That’s because kitty uses GLFW for window creation/OpenGL context/input handling, and bundles a copy of it. If you can make it use the system library (assuming it exists on OpenBSD) it should work.

        1. 3

          You vendor it, you own it. If it had just been a simple -lglfw I never would have noticed and the build would have just worked.

      2. 15

        Notably, the author is also the creator of the awesome FOSS Calibre app for e-books conversion & management.

        1. 5

          I’d be interested to see a side-by-side comparison of kitty to alacritty. In particular, I’ve been using alacritty at work for a while and while it’s barebones at the moment, it’s exceptionally fast (which is probably my core feature for terminal emulators). That said, kitty looks like a fine emulator.

          1. 6

            Honest question: what need do you have for a fast terminal emulator?

            1. 7

              I have a minor obsession with input latency and scroll jank. It seems to creep up everywhere and is hard to stamp out (Sublime Text is a shining counterexample). I noticed a bit of weird input latency issues when using Terminal.app (purely anecdotal), and haven’t seen the same thing since using alacritty. So that’s the need I have for a fast emulator, it enables a smooth input and output experience.

              1. 3

                I am sensitive to the same.

                This is what kept me on Sublime Text for years, despite open source alternatives (Atom, VS Code and friends). I gave them all at least a week, but in the end the minor latency hiccups were a major distraction. A friend with similar sensitivity has told me that VS Code has gotten better lately, I would give it another go if I weren’t transitioning to Emacs instead.

                I sometimes use the Gmail web client and, for some period of time, I would experience an odd buffering of my keystrokes and it would sometimes completely derail my train of thought. It’s the digital equivalent of a painful muscle spasm. Sometimes you ignore it and move on, but sometimes you stop and think “Did I do something wrong here? Is there something more generally broken, and I should fear or investigate it?”

                1. 1

                  Web-based applications are particularly bad, because often they don’t just buffer, but completely reorder my keystrokes. So I can’t just keep typing and wait for the page to catch up; I have to stop, otherwise I’m going to have to do an edit anyway.

              2. 3

                I have to admit, I thought for certain this was going to be Yet Another JavaScript Terminal but it turns out it’s written in Python. Interesting.

                Anyway I would have a hard time believing it’s faster than xfce4-terminal, xterm, or rxvt. It’s been a long time since I last benchmarked terminal emulators, maybe I smell a weekend project coming on.

                1. 6

                  kitty is written is about half C, half Python, Alacritty is written in Rust.

                  There were some benchmarks done for the recent Alacritty release that added scrollback, which include kitty, urxvt, termite, and st. https://jwilm.io/blog/alacritty-lands-scrollback/#benchmarks

                  1. 2

                    I just did a few rough-and-ready benchmarks on my system. Compared to my daily driver (xfce4-terminal), kitty is a little under twice as fast, alacritty and rxvt are about three times as fast. If raw speed was my only concern, I would probably reach for rxvt-unicode since it’s a more mature project.

                    Alacritty is too bare-bones for me but I could be sold on kitty if I took the time to make it work/behave like xfce4-terminal.

                    1. 1

                      I like xfce4-terminal, but it renders fonts completely wrong for me. It’s most noticeable when I run tmux and the solid lines are drawn with dashes. If I pick a font where the lines are solid, then certain letters look off. It’s a shame, because other vte-based terminals (e.g. gnome-terminal) tend to be much slower.

                2. 2

                  For me it’s the simple stuff that gets annoying when it’s slow. Tailing high-volume logs. less-ing/cat-ing large files. Long scrollbacks. Makes a difference to my day by just not being slow.

                  1. 2

                    I don’t care that much about the speed it takes to cat a big file, but low latency is very nice and kitty is quite good at that. I cannot use libvte terminals anymore, they just seem so sluggish.

                    1. 2

                      For one thing, my workflow involves cutting and pasting large blocks of text. If the terminal emulator can’t keep up, blocks of text can come through out of order etc, which can be a bad time for everyone involved.

                    2. 3

                      I’m on macOS.

                      I used alacritty for a while, then switched to kitty as I’d get these long page redraws when switching tmux windows—so kitty is at least better for me in that regard. Both have similar ease of configuration. I use tmux within both, so I don’t use kitty’s scrolling or tabs. The way I was using them, they were more or less the same.

                      I’m going to try alacritty again to see if it’s improved. I’d honestly use the default Terminal app if I could easily provide custom shortcuts (I bind keys to switching tmux panes, etc).

                      1. 4

                        I came back to Alacritty on MacOS just the other day after trying it last maybe 6 months ago and finding it “not ready” in my head. It’s been significantly updated, there’s a DMG installer (and it’s in brew), a lot more polished overall and it works really well and really fast. No redraws in tmux switches. Weirded redraw artifiact while resizing main window, but snaps to fixed immediately you stop, and doesn’t bother me much. Using it as a full-time Terminal replacement right now, liking it so far, will see how it goes!

                        1. 1

                          Good to know! I’ve installed it via brew now and double-checked my old config. My font (as in, not the default Menlo. I’m using a patched Roboto Mono) looks a bit too bold, so just gotta figure out what’s wrong there.

                          1. 2

                            They’ve updated config files with additional info about aliasing and rendering fonts on Mac. So take a look at that if you are using your old config. It’s not a bad idea to start from scratch.

                            1. 1

                              Thanks for the tip! I did start from scratch and moved over changes bit by bit, but I’ll have to check the new macOS specific lines.

                        2. 3

                          Cool, thanks for your input! I also use tmux, and I haven’t seen anything like what you described (I also don’t really use tmux panes, only tabs). I know there has been a longstanding vim + tmux + osx bug as well, but I haven’t used vim proper in a while.

                          1. 2

                            I think that’s my exact problem (turns out I’m even subscribed to the issue haha). I use neovim so I think it is/was applicable to both

                        3. 1

                          do any of those really measure up when benchmarked.

                          I remember doing some writing to stdout and it alacritty turned out to be slower than say gnome-terminal or whatever.

                          Might’ve been that there was a bug with my intel graphics card though, don’t remember to well.

                        4. 7

                          Moving trivial rendering problems to the GPU is insane and has to stop. Rendering a screen of text is fast enough (< 1 frame) on the CPU, so moving it to the GPU is a pointless pessimisation and tanks perf for programs that actually need the GPU for real work.

                          I’m working on a game and we occasionally get people asking why are they getting half their normal framerate, or I start the game and get massive frame hitches and wonder what did I just break, and the answer is Firefox has a tab open with a looping CSS animation.

                          1. 6

                            (serious question: I’m nowhere near this space): Why does the OS / GPU allow that?

                            If one process wants to max out the CPU, my computer gets hot, but doesn’t eg stop being responsive to input or refuse to schedule other processes.

                            1. 10

                              Your OS kernel has a sophisticated fair share scheduling system, and on a interactive machine like a laptop it has probably been tuned for UI responsiveness. GPUs don’t have anything of the sort, they just execute each task given to them to completion.

                            2. 5

                              I’m working on a game and we occasionally get people asking why are they getting half their normal framerate, or I start the game and get massive frame hitches and wonder what did I just break, and the answer is Firefox has a tab open with a looping CSS animation.

                              I’m confused. Looping CSS animations are not necessarily a trivial rendering problem?

                              1. 1

                                That is exactly the point.

                            3. 5

                              Not to be overly criticial, but I’m not entirely sure what problems are solved by this - or, more accurately, why.

                              From the bullet points on the website I gather

                              GPU rendering for scrolling

                              This is not a problem I ever had with any terminal emulator. Anywhere (well, except maybe Windows). I’ve had scrollback buffers be too small, but never had problems actually scrolling. And I have a lot of long-running terminal sessions.

                              Threaded rendering to minimize input latency

                              In my experience, threads don’t really do anything for non-multiplexed sources such as keyboards. And even for multiplexed sources, they mostly do more harm than good.

                              Supports […] features: “Graphics (images)”

                              why?

                              unicode, true-color, OpenType ligatures, mouse protocol, […]

                              so does urxvt

                              […] and several new terminal protocol extensions.

                              Not sure this is a good thing. (Insert XKCD about (n+1) Standards here)

                              tiling multiple terminal windows side by side […] without […] tmux

                              Which would probably (haven’t checked) require me to learn new keybindings.

                              Can be controlled from scripts or the shell prompt […]

                              Uh, it’s a terminal emulator. I would expect it can be.

                              […] even over SSH

                              OK, why though?

                              […] Kittens, [….] for example, […] Unicode input, Hints and Side-by-side diff.

                              I have a strong dislike of introducing unnecessary home-grown terminology and being all cutesy about it, but even so, if Unicode input is a plugin, I’m not sure about this.

                              startup sessions, […] working directories and programs to run on startup.

                              So, a shell. I don’t know, I thought this was a terminal emulator

                              Allows you to open the scrollback buffer […] for browsing the history comfortably in a pager or editor.

                              I’m pretty sure my needs are met with history, C-R and .zsh_history

                              1. 21

                                […] and several new terminal protocol extensions.

                                Not sure this is a good thing.

                                It is most certainly a good thing, terminal protocol has been stagnant and–until recently–few terminals got off the couch to implement even basic, ancient features like cursor shaping.

                                Teaching users to have higher standards, makes life easier for application developers who must target the lowest common denominator. Kitty, iTerm2, mintty, libvte (gnome-terminal, termite, etc.), and libvterm (nvim, vim, pangoterm) have been raising the bar, so the lowest common denominator is now… higher.

                                Just like Internet Explorer 6 held back the web, stagnant terminals hold back terminal applications. urxvt is the IE6 of terminals. Isn’t it a bit ironic that iTerm2/Terminal.app (macOS) and mintty (Windows) have more features than any of the terminals you find on desktop unix?

                                (Insert XKCD about (n+1) Standards here)

                                Doesn’t apply here. Thomas Dickey (xterm/ncurses) sets the standard, except there’s a loophole: the most popular behavior wins (and applications must swallow it, standard be damned).

                                The kitty/libvte/iTerm2/libvterm authors have been cooperating, which means “popular”. And I’ve seen successful efforts to “upstream” choices to Dickey.

                                libvterm author has compiled a spreadsheet of known terminal behaviors (contributions welcomed/encouraged).

                                1. 6

                                  I love these new behaviours! until fairly recently, I figured I just can’t do some things in a terminal emulator, and then someone went ahead and implemented proper right-to-left support in one of the mentioned terminals. It’s frustrating to think of how long that’s been broken for me.

                                  I was sharing this with a group so excited to finally have this feature and someone mentioned like, “I learned to read backwards”. Why should we put up with these barriers in technology? I certainly used computers before I knew English.

                                  1. 2

                                    It is most certainly a good thing, terminal protocol has been stagnant and–until recently–few terminals got off the couch to implement even basic, ancient features like cursor shaping.

                                    I’d rather have those programs just start doing proper graphics, and stop trying to use the terminal as a bad graphics protocol.

                                    1. 2

                                      Kitty has implemented several extensions, such as colored undercurl (which is now also implemented in libvte).

                                      Not to mention “just start doing proper graphics” is meaningless and would discard the actually useful properties of a terminal.

                                      1. 1

                                        I’ve always felt that the one advantage of the terminal was the ability to easily pipe data from a program to another (which I would consider a property of the shell rather than a property of the terminal) and that terminal UIs were the worst of both worlds: bad at piping and bad at rendering things. I’m sure you have way more experience with terminals than me though, so I’m wondering if you could expand on what you think the useful properties of a terminal are.

                                  2. 20

                                    I agree that reading the feature list seems like a confusing mix of shell feature plugged into a tty. However,

                                    Supports […] features: “Graphics (images)”

                                    why?

                                    Why not? Why isn’t there a “standard” yet to output graphics in my tty? Wouldn’t it be nice to ls --thumbnails and have a list of thumbnails for images? icat images? Preview graphviz result? Have a dropdown with a preview when I hover a path in Vim and hit a shortcut? I don’t see why we still can’t do any of this nowadays. I for one would welcome graphics in my terminal.

                                    1. 4

                                      As a security minded user I would argue with separation of concerns. Image formats have long been a prime attack vector due to their internal complexities. I would not like a terminal emulator to be concerned with parsing image files, a task which specialized tools still get wrong sometimes. Sandboxing/Jailing the image rendering process would also mean confining the terminal emulator. I also would like a very good terminal emulator, not a pretty meh image viewer with terminal capabilities.

                                      Continuing down this road, where do you stop? SVGs support animation and scripting, should my terminal emulator pull in V8 or an entire chromium instance to run it? What are the implications of that? (And I’m aware that sadly that is exactly what many developers already do).

                                      1. 4

                                        It’s possible to implement graphic support in other ways. Looking at Kitty, the protocol make it so the terminal emulator only require bitmap capabilities. All image parsing is done by the process writing to the tty. SVG support can be done simply by rendering it as bitmap. Animation can be done the same way they are done with text. No need for complexity or trade security for something else when you properly design something.

                                        1. 1

                                          That would be a good idea, yes.

                                          Sadly, good (software) design has become something of an exception these days :)

                                      2. 3

                                        I have a strong dislike of introducing unnecessary home-grown terminology and being all cutesy about it, but even so, if Unicode input is a plugin, I’m not sure about this.

                                        I have found the kittens interface to be the best plugin/scripting interface of any terminal I’ve ever used.

                                        The unicode input kitty allows you to insert by code point, and search/browse by character name. Think of it as vim’s digraph selector on steroids. It’s pretty cool.

                                        The kitten system is also simple enough for me to write a quick password manager (using the OS keychain) in 150 lines of python (including a bunch of unnecessary stuff like “press any key to continue” and tab completion). I tried writing an iTerm plugin once, and I gave up quickly.

                                        Kitty strikes a remarkably good balance between minimal (and low overhead) and fully-featured. I’m not sure it solves any unsolved problem per se, but it strikes a perfect balance for me. I think that’s because I’m not as interested in configuring my terminal as I’d need to be for urxvt to suit me perfectly, but I am interested in playing with very particular things.

                                        1. 1

                                          I run Terminology for irssi, despite using XFCE4, because it can display images from URLs overlaid onto the terminal.

                                          I don’t really love Terminology that much, or maybe it’s gotten otherwise better with eg. tabs since the ancient version I’m stuck with, so it is strange no one else is doing these cool things. Not even as an opt-in thing.

                                        2. 7

                                          If you don’t understand, you don’t have to use it!

                                          Uh, it’s a terminal emulator. I would expect it can be.

                                          You should read more about what that means:

                                          https://sw.kovidgoyal.net/kitty/remote-control.html

                                          1. 6
                                            […] and several new terminal protocol extensions.
                                            

                                            Not sure this is a good thing. (Insert XKCD about (n+1) Standards here)

                                            Considering that the currently used standard for terminal input still relies on timing for the alt modifier and that it cannot do lossless input (see <tab> and <ctr+i> being the same for example), I’d argue that a new standard is very much needed.

                                            I’m pretty sure my needs are met with history, C-R and .zsh_history

                                            That has little to do with history which is only about the commands you’ve entered and not their output. With kitty I can open the entire contents of the scrollback in my favourite text editor (kakoune if you’re asking), to do powerful text manipulation, instead of being constrained by whatever primitives the terminal implemented (for example, termite’s limited vim mode). After all the scrollback is just a big buffer of text so opening it in a text editor is particularly suitable.

                                            1. 1

                                              if Unicode input is a plugin

                                              That probably refers to something fancy like an emoji picker or something. Definitely not to just typing non-ASCII characters from the keyboard.

                                            2. 2

                                              I’m used to being able to dynamically change the font size on MacOS by hitting cmd+/- but this does nothing on Kitty :-(

                                              1. 4

                                                It seems Kitty’s default shortcuts are unlike other macOS terminals’. If you open the preferences text file ~/.config/kitty/kitty.conf from the “Preferences…” menu item, you can see that the file contains these commented-out lines that describe the default mappings:

                                                # kitty_mod ctrl+shift
                                                
                                                #: The value of kitty_mod is used as the modifier for all default
                                                #: shortcuts, you can change it in your kitty.conf to change the
                                                #: modifiers for all the default shortcuts.
                                                
                                                …
                                                
                                                # map kitty_mod+equal     change_font_size all +2.0
                                                # map kitty_mod+minus     change_font_size all -2.0
                                                # map kitty_mod+backspace change_font_size all 0
                                                

                                                So the default shortcuts to increase and decrease the font size are Shift+Ctrl+‘=’ and Shift+Ctrl+‘-’.

                                                For anyone who wants a terminal that provides by default macOS-standard features such as common shortcuts, session reloading, and menus, I recommend iTerm2.

                                              2. 2

                                                Just wanted to add a short note that I’ve been using kitty at home and at work and I slightly prefer to iTerm2, which I was using previously.

                                                To address cbdev’s criticisms, almost all of the benefits I’ve experienced have kitty having a significantly lower startup latency than iTerm2 and the default Terminal app. I also slightly prefer the window and tab management shortcuts kitty provides by default to iTerm2’s.

                                                1. 2

                                                  FWIW I filed an issue against kitty’s repo in hopes the author will add a short blurb about how stupid simple it is to fix conformance to MacOS X app standards.

                                                  https://github.com/kovidgoyal/kitty/issues/1313

                                                  Just add ‘kitty_mod cmd’ to your kitty.conf and away you go. I’m seeing a lot of people discard Kitty out of hand because of this one problem so this seems like a sane marketing fix.

                                                  1. 2

                                                    Good deal!

                                                  2. 1

                                                    Doesn’t work for me, since I have only nvidia-powered systems.

                                                    https://github.com/kovidgoyal/kitty/issues/456

                                                    1. 1

                                                      I installed it and it just works with ligatures in VIM and tmux with no configuration. Really what I was looking for!

                                                      1. 0

                                                        I use kitty on Manjaro, it’s pretty excellent.