Alacritty, foot, wezterm, kitty form this block of "nextgen" terminal emulators. I do find them difficult to differentiate. I personally use foot as my daily driver, but that is just because alacritty happened to have some issues with nvidia drivers (bleh). But I chalk that up to nvidia, not alacritty.
Foot is Linux only and lightweight, take it as a Wayland version of Xterm with good defaults and almost no emulation options. The rest works in all major OS. Alacrity is all about GPU rendering speed at the cost of everything else (at some point it did not have scrollbars/history). Kitty and Wezterm are packed with features and more difficult to differentiate. They are all good though.
Another +1 for Wezterm.
I also tried Alacritty in past, but felt it too basic.
Kitty was better. TBH, not sure why I left that for Wezterm.
But for now, I've settled and have no intention to change.
Ass I use Offpunk to surf the web and Chafa to display picture, my main concern is displaying images using the sixel protocol (or, in the case of kitty, its own protocol).
Last time I tried, Alacritty didn’t support sixel (while even xterm supports it)
I haven't stumbled upon any issues with alacritty + nvidia (lucky, perhaps). Though, mostly, I use vterm in emacs (unmatched customization & integration)
Wasn't for latency or throughput - I didn't notice any difference in latency, and difference in throughput is only visible when cat'ing 3MB of text.
However, for me the selling point was a text config file, which I can edit, backup, or store in git (unlike gnome-terminal, where customization was done either in GUI or in gconf, and while it's also text files somewhere they are difficult to work with).
I wrote something similar on top of TMUX and zsh. I use zsh hooks to dump the current TMUX pane to a file (/tmp/lastcmd) just before a new prompt is displayed; I also set variables $O1, $O2, ... to respective output lines. It never occurred to me to bind `less /tmp/lastcmd` to a key, though - good idea :)
(BTW: the problematic part was to make it fast enough not to be noticeable. The code that dumps the pane contents and searches for the start of the last output is written in Nim, in effect.)
It was possible in TMUX because it gives you programmatic access to the pane's content. It's probably possible to do the same with some terminals - urxvt uses Perl as an extension language, for example - but TMUX provides a compatibility layer, which means I don't need to rewrite the whole setup if I change the terminal emulator.
My understanding is that kitty has an automatic (opt-out) update feature [0][1]. I don't really like the idea of a terminal doing that.
However I like the fact that kitty developer(s) actively improved the state of the terminal emulation with their new keyboard and graphic protocols [2].
Nope, that's an update notification not an update. And its opt-in if you use kitty via a distribution package and opt-out if you use the standalone kitty binaries distributed by the developer. See https://sw.kovidgoyal.net/kitty/conf/#opt-kitty.update_check...
Funny, I always use the binaries distributed by the developers whenever I can thinking that the less intermediaries the better. Maybe I need to revise that position.
Malicious distro packagers are virtually unheard of, and another set of eyes on the software is generally better. For instance, if the developer sells out the packager can save your bacon. This is especially true on Android where selling out is more common (see: the Simple Apps situation and F-Droid) but also a valid consideration on desktop Linux.
I wouldn't assume anything about distro packages really. It's a higher bar in some systems (like Debian), lower in some (like nixpkgs), but the time investment to be in a position to sabotage something is quite low overall and requires little skill. Then there are not-distro packages that they easily abused over time. For example sourceforge was a respected distributor of software for a long time and they moved to adware installers.
I stick to official distro packages from distros I like, mainly Debian and OpenSUSE. Community packages are too sketchy for me, and I consider downloading packages from sourceforge/etc to be a Windowism. And while it's possible for a malicious entity to infiltrate the ranks of distro packagers, I think the threat of the developer selling out has proven to be more likely.
I certainly see Kitty is as a little crufty ("feature-packed" to some), but from my limited research it appears to be one of the fastest, so I can't really complain :-)
kitty is nice, but it has a problem with garbled unicode sequences (e.g. if you accidentally cat a binary file to standard output). It sometimes hangs up for a minute or two on seeing invalid unicode sequence. At least that was the case for several years, and so I switched to alacritty because it doesn't have this problem.
Nice, I like lightweight and modern terminal emulators. Just installed kitty and compared it in a sloppy way to foot [0] (by running `xxd /dev/urandom` side-by-side) and foot appears to be faster.
kitty is written in Python, which instantly lowers the ceiling for performance by an order of magnitude. I discarded it as an option in the past: the most important requirement for me is the terminal cannot crash, and I can't trust a Python program to do that.
I like Kitty graphics protocol, but never used it. Didn't know Kitty was python, always assumed it was compiled due to the reported speed benefits. Maybe I'd benefit from switch to foot since my setup is mostly wayland nowadays, extra startup speed would be great. Foot seems to also have working terminal clipboard integration with `micro` too.
Same and it also opens faster, which is important for me, as I use a tiling window manager and open/close terminals fairly often instead of using something like tmux.
I tried it for a few years a while back on macOS but it somehow felt off, I don't remember why, something to do with mouse selection. I went back to iTerm2 and that's that, you couldn't view images with feh and similar tools in macOS terminals for some reason so I had no reason to stay. Out of interest, why would I want anything faster than iTerm2 anyway? Never felt that my terminal is slow.
The main problem with iTerm2 is that the configuration is not via plain text and so it's impossible to keep track of your config in git. (I did try the dynamic profiles feature for a couples of years, but it's not the same). I use alacritty now, but I'm sure wezterm etc are also great.
in Settings -> General -> Preferences is a checkbox labeled "Load preferences from a custom folder or URL. I have that checked and the configs are saved in a text file of plist format.
On Mac, I have yet to find anything that can top the combo of Apple Terminal with the now-defunct Visor/TotalTerminal[0] haxie. Apple Terminal meets my needs well enough and TotalTerminal’s implementation of quake-style dropdown was the smoothest I’ve encountered on any platform.
iTerm2 has a dropdown window that can be enabled, but it’s surprisingly much more janky than TotalTerminal’s was despite being a first-party feature instead of a hack.
I've had the same issue with iTerm using neovim, rendering latency was just too much iTerm. However instead of Alacrity I've opted to use wezterm as it's nice to use Lua for both neovim and my terminal config.
As I broke away from windows a few years ago, I used the default terminal in popos, then got a Mac as my work machine. Then broke away from vscode to neovim and didn't like the default Mac terminal or iterm2, looked for a cross platform terminal, found alacritty and haven't looked back.
Are there other non-gpu accelerated terminals that would work just as well? Probably, but alacritty is installed, configured and works well for me
I used Alacritty for couple of years, before switching to WezTerm almost a year ago.
There were two reasons for my change, the Alacritty devs are really obsessed with speed, which is good, but.. means less features, even _optional_ features like ligatures. I like ligatures, and because they slow down the rendering slightly the alacritty devs do not want to include it[0]
The other reason is that I wanted a way to have my terminal have two different colorschemes, light for the day and dark for the night. It seems that it might be supported now with alacritty[1]? But it does also seem like you need an external script still to do it..
I went with WezTerm because it supports both natively, everything else feels the same TBH, but the fact that WezTerm has more features that are optional, is what I liked.
Yes, I did, but it's been a while and I don't remember off the top of my head the details why I settled with wezterm.
What I can say is, that I find wezterm configuration quite pleasant. Overall I think they are in the same league but Alacrity gets a lot more attention and that's why I like to remind people that there is wezterm too.
Oh that’s very interesting to hear about tmux increasing latency. I’ve not heard this before but now you mention it, it seems obvious. Could you elaborate?
Development of features are a bit hindered in Alacritty; kitty and wezterm on the other hand, have useful features and have been really good. Personally, I'm using kitty for the past month.
I've been using Konsole and I only relatively recently found out how powerful its tab/split management is. You can drag and drop tabs between different windows, and you can drag and drop panes between different tabs to create splits, which also works even between tabs in different windows.
I prefer wezterm. It comes bundled with libssh, connecting through ssh to WSL instead of going through wsl.exe makes everything feels at least 100x faster, since it avoid going through conpty.
Moved to Alacritty from iTerm2 recently. The biggest plus was the simple text config. I actively make a lot of changes to my config (always experimenting with different shortcuts and other things) and updating configs on multiple machines (work and personal) became a headache. This solved that for me; can just commit any changes to the text file and pull on other machine.
Any shortcuts with control/alt don’t work unless you add keybindings to the config with escape sequences. Some distros give you the config by default but that breaks other things such as jumping to the start of a command with ctrl+a
That is not my experience: ctrl-a jumps to the start of a command. I've not seen any issues with Ubuntu, tmux and fish.
All tmux and fish keyboard shortcuts have worked without any alacrity configuration (that I can recall).
My tmux config adds shortcuts to behave like a conventional tabbed window without any issues e.g. ctrl-n (new tab), ctrl-w (close tab), ctrl-page-up/down to navigate tabs.
It has tabs on macOS at least, but it f alls in the classic pitfall of cross platform applications where they made the mistake of not using the OS to resolve keystrokes.
So my keyboard layout doesn't work with the app at all. I've identified the issues but making a pull request for it and testing it all is a bit of work I haven't gotten round to yet.
I don't understand why more of SecureCRT's features don't get implemented into FOSS terminal emulators.
If nothing else, just being able to have clickable buttons that I can configure to paste text is IMMENSELY useful. Combine a few good click-to-paste-string buttons with a bash for loop and ssh, and you're a long way to a quick and dirty Ansible replacement for those multi-system tasks.
I gave it a shot on windows with wsl2. I hit some weird config gotchas because they switched to toml but didn't think it through too much (not a good sign). Then I just could not get my shortcuts to work with tmux and nevim. I use M+pgup/pgdn for session nav and S-left/right for window nav and instead of trying to break my config to get them to work I just gave up. I didn't see any benefits so went back to Windows Terminal.
Had similar issues as well. I use a Nordic layout for my keyboard (which includes åäö). These extra characters were a pain to bind certain key combinations to.
I use Alacritty and really like it :). I use it primarily for scripts and other cases where I want a terminal to open extremely fast. Some day I'll get around to finding a way to easily use tabs in it and I can replace Terminator (which I also really like and use, of course; but its a lot slower to open)
Been using Alacritty daily for over a year now on Ubuntu for paid and unpaid (hobby) work and it’s exactly what I need: something that doesn’t get in my way, and it renders nicely. Performance on a ThinkPad with Nvidia graphics card is great.
At the risk of missing something completely obvious: where's the "emulator" part in it? What is it emulating? It looks like a terminal (no emulator) to me. Not trolling, just trying to learn.
Thank you. I think it's a bit misleading then to call it a "terminal emulator". It's not really emulating one of those old boxes, is it? It's providing a text interface to a computer's functions. That's great but it's not emulating anything.
It emulates them in the sense that they implement a virtual display and keyboard for the same wire protocols those old boxes used. Those protocols are mostly plain text, but also escape sequences for cursors, colors, layout, etc. Check out the VT100 sequences for example.
Currently my terminal of choice on WSL, coupled with tmux. Works ok, a few bugs, doesn't work well with neovim, character artifacts remain sometimes. But on the whole steady and reliable.
I've grown dissatisfied with it, but I can't be assed to switched to anything else since it's the only terminal emulator that renders fonts well, at least on my machine.
I used to use it on windows until Microsoft released its Windows Terminal and switched over. Any reason to switch back? Windows terminal seems snappy enough.
Why would you want ligatures? I would prefer to see text as it actually is, not combining multiple characters into one. I can't trust what I am seeing if I know the text might be something it is not.
Some writing systems like the Arabic script require ligatures for correct text rendering. I think supporting the third most widely used language worldwide is reasonable.
Also ligatures are optional, you aren't affected if you don't like the feature.
I guess I'm surprised that such a crucial feature isn't standard in everything if you can't even properly display a common language like Arabic without it.
Think you can still trust what you're seeing because the char width is different, so it's not hard to differentiate
Some prefer text to be seen as it was meant to be, so that === ugliness that can't be fixed at the source due to bad unicode support can at least be fixed at the output
Same I love my ligatures to death. And there are some interesting goodies. I find the author take on `tmux` being unecessary interesting, albeit it's a quite divisive opinion. Nevertheless, it's refreshing to see the status quo being challenged.
I liked kitty, but this was part of what drove me away. My terminal at work spans the bottom half of my monitor, and is typically split into 2-3 panes. I’ll also have multiple named windows at any given time. This works amazingly well for me, and I have no desire to switch.
My other problem was having TERMINFO available on remote servers. I’m not about to start installing alternative terminal emulators in prod, and while there is a workaround to losing control characters, IIRC it’s a pain.
Alacritty uses OpenGL ES 2.0 which is not deprecated. It's shipped OOB in macOS through the ANGLE project by Google, mainly because Safari depends on it to provide WebGL support (it's kind of OpenGL ES for JavaScript). ANGLE translates OpenGL ES so that it runs on top of Metal, D3D, or desktop OpenGL.
OpenGL ES 2.0 is probably the most portable GPU rendering API there is, it pretty much runs anywhere. That said, using Metal or D3D should definitely bring noticeable improvements, especially when it comes to memory bandwidth (eg. on Metal no need to send pixels to the GPU memory for atlas-based text rendering).
What problem is having a "fast" terminal solving? I've been using urxvt for years and have never really found it to be slow. Where might I notice a difference with these "modern" "GPU-accelerated" terminals?
The delay in between typing and seeing it rendered, drawing large portions of text (which matters if you spend a lot of time in term based editors) etc ...
It's very subjective: some folks (me included) will notice the difference and feel frustrated if it's not fast enough, while others are scratching their head about how it actually makes a difference.
It could also be said, that it's of logical to expect certain things to be fast; especially when they've been around for so long. We're drawing text on the screen here, it should be fast.
Saying it matters with anything else than feeling/comfort would be overreaching.
The issue is that usually these terminals mean "higher throughput" when they say "faster", not "lower latency". The lowest-latency terminal in every test is Xterm, often by a LOT. Alacritty for a long time was actually quite bad at latency--and notably had a high variance on its latency, which is particularly miserable--but I think it improved recently? From what I remember of these benchmarks, someone using urxvt isn't going to be impressed by the supposed speed of Alacritty, if we are talking latency (and I agree: we should be, and everyone should use Xterm, which is actually an insanely good terminal).
As for throughput, I have lived in the terminal for decades, and as long as the various layers don't have massive buffers I honestly don't care how slow the terminal is: if I am dumping megabytes into my terminal backscroll I probably am going "oh shit" and am frantically hitting Ctrl-C... a slow terminal with a small buffer handles that almost immediately. I get the impression that there are maybe some use cases involving high-rate screen updates for apps that happen to run in consoles but are really GUIs... I don't use many of those and in fact try to avoid them, but I could maybe see an advantage for a high-throughput terminal to improve their simulated frame rate?
People writing fast terminal emulator care about throughput, latency and resource utilization. Kitty for instance deliberately limit throughput to keep both latency and CPU/GPU usage reasonable.
Also, by what metric is xterm so fast? I accept the idea that it is fast, even the fastest, but "a lot" seems suspicious to me. From the keyboard to the monitor, there is a lot of hardware and driver latency, I guess tens of milliseconds, so the effect of the terminal, should be relatively minor. I suspect xterm is so fast because the tool used to test it relies on the X server, and because xterm communicates with X directly, the latency will be really low from the point of view of X, but how is it end-to-end? Do we get the same results, with, say, Wayland?
The other one where xterm is uber low is https://lwn.net/Articles/751763/ is using this tool with software-based screen capture https://pavelfatin.com/typometer/, not sure how reliable that is as a proxy for end-to-end (at the time of the benchmark Wayland wasn't supported)
I only really notice it when accidentally catting a really large file. Although I prefer kitty, any of these modern terminal emulators just rip through megabytes of text in less than a second, while in older ones you have to wait for half a minute or just sigkill them.
Your buffer is too big: your terminal shouldn't be sitting there for half a minute, as it should be processing Ctrl-C immediately and unrelatedly to its screen updates and sending it, and the remote process should be blocked on a write to its output (which in turn should prevent it from creating more garbage due to the back pressure) because all the buffers between it and you are full. Having ginormous buffers and then wanting the local terminal to be super fast to clear them quickly is kind of pointless as the use case for streaming megabytes of garbage to the terminal and NOT cancelling the operation are effectively 0.
Each time I see a new "fast" terminal emulator I bench it with my only way to do it (`time cat large-text-file`) and urxvt is really quicker than other.
I agree that I've never had a problem with terminal speeds on Linux. If you're using urxvt, that's probably going to do just fine.
Where I have had problems has been on the Mac, where the system default "Terminal.app" or popular alternatives like "iTerm2.app" can each be catastrophically slow if you have a lot of control codes (as in, for example, rapidly paging through a large document in vim with an intensive color scheme active), and it could just take noticeable fractions of a second to redraw a fullscreen terminal window.
Moving to a faster terminal emulator like alacritty or kitty did make a good quality of life improvement for me in that specific use case.
I use Cygwin's mintty on Windows, and the result of `ls` is not instantaneously there. If the windows is resized to big and there are lots of files, I can see each filename get printed out one by one. In Alacritty it shows the entire result immediately.
Also, you may have commands or scripts which print out a lot, like which file in a huge list is currently getting processed, where the entire execution time of the command depends mostly on how fast the terminal is able to print those messages.
Compilation of a large project on a multiple cores can be slowed down by a terminal. Especially if the main language of the project is a fast compiling C. I'm not sure that urxvt can be a bottleneck, and if it can you'll not be able to notice the difference with alacritty without measurements, but with others it can be noticeable without any special equipment.
alo of gpu accelearted terminals are actuallly very slow. because they add silly features. basic text i/o is almost always slower. even on a good gpu! :/
Anything that dumps text on the console really fast.
An example I run into fairly often is untarring a backup in verbose mode. With modern NVMes, printing out the filenames to a slow console can be a bottleneck.
"fast" probably depends where you're coming from. Moving to Alacritty (and then WezTerm) from iterm2 was definitely a very noticeable difference for me, and just "felt" better. Of course iterm2 isn't exactly slow, but that feeling of UI immediacy in faster terminals does help me focus on the task at hand. If your existing terminal is fast enough to not notice, I suspect you've already hit the point of diminishing returns.
You can feel it. Specially as 5e92cb50239222b says in throughput. Urxvt is not one of the slow emulators so you will notice it less specially at lower resolutions.
Right now I have about 20 open (in sway) and half of them are non-local SSH sessions... so pretty pointless. I only notice SSH latency when the VPN wobbles. Or throughput if I mis-cat a log file instead of using tail...
I complain like crazy if there is any latency in gaming so it seems I'm not latency sensitive in terminals :-) or more likely: reality tempers expectations.
I use Kitty, which is extremely fast, and I often avoid calling `tail` to print the end of a long log file: the terminal is so fast in displaying it that it's useless.
Another case is when you mistakenly invoke a command that produces a lot of output. With Kitty, terminal output is so fast that the output ended before I could reach Ctrl+C.
I care about energy efficiency deeply. But in a terminal? You can't be serious.
Each terminal is in the end tied to a single person so there is no runaway scaling of instances possible. Your win in energy consumption is in the single digit watt-hours per person.
One could probably compare the energy savings coming from the terminal rendering to the extra energy consumed by the developer trying to improve performance and it might turn out to be a wash.
As for the perception of speed by people using the terminal. I too am very puzzled how this is different from audiophile movement where people claim to perceive minuscule differences in THD whatever metric they focus on today.
It might be that I've been working over dial-up sessions and intercontinental ssh sessions and the perception of slow starts to creep in when RTT gets to 100ms range. Which is probably orders of magnitude worse and more limiting than the difference between kitty and alacritty.
I highly doubt that offloading the rendering to a GPU is more energy efficient. I'm quite sure it's the exact opposite: GPUs are power hungry energy-eaters; commonly.
GPUs (namely discrete ones) often have high maximum power draw, but that's because they're generally used for tasks that require computational heavy lifting. That doesn't mean they're particularly power-hungry in terms of watts vs. amount of work done. If you offload e.g. video decoding to a GPU, that's usually more energy-efficient than decoding on the CPU.
(The heavy lifting is probably more energy-efficient on the GPU, too, but that's not directly relevant here.)
urxvt and xterm are also fast terminals. The noticably slow ones are gnome-terminal, konsole, etc. They have pretty bad latency in the time between pressing a key and that letter appearing on screen.
Neither Konsole nor GNOME Terminal are as lean and fast as (U)XTerm, however on day to day use, I fail to see input latency on these. I generally use 60-80WPM depending on what I write and how concentrated I am, and there's no noticeable lag from my perspective.
GNOME terminal was visibly slow in the days of yore, but given that the libraries powering these are already accelerated, I don't think the difference between these "accelerated" terminals are as big as touted w.r.t. GNOME Terminal or KDE's Konsole.
To be fair I haven't tried gnome terminal in some years so maybe it's improved. I have used konsole (well, yakuake, but same thing) more recently and was minorly annoyed by the latency, particularly when scrolling in emacs/etc. I have since swapped out yakuake with kitty with tdrop for the "quake mode" effect.
Yes, Yakuake uses the same Konsole framework, but they might lag behind in terms of framework version IIUC. Konsole supports more features than Yakuake and feels a bit smoother to me since I drive both daily.
Love to collaborate and make some tests with you, too.
If you accidentally pipe hundreds of thousands of lines of text (e.g. from find) to stdout, you will feel the difference. Some terminals (e.g. xterm) are particularly slow and will stall until it is done processing all the output. urxvt is not the worst, but could be better, yet doesn't always achieve 60 Hz.
My gripe with (u)rxvt (last I checked) is the atrocious font rendering and character spacing if you chose a full unicode/nerd font.
Yeah, I see no difference either, I used to use urxvt for years, then switched to kitty (which is also hardware accelerated like Alacritty), but not for the supposed "performance" gains but because it's got better features but I can't really tell the difference.
But... Alacritty does support and use the TERM variable. What you talking about? TERM should be set to alacritty, which has been in terminfo for years.
