Alacritty – A fast, cross-platform, OpenGL terminal emulator

Not sure if you don't consider Windows a major OS, but Kitty doesn't work there.

There still are no scrollbars in Alacritty: https://github.com/alacritty/alacritty/issues/775

Use Wezterm is you want a modern rust based terminal with basic nice stuff like scrollbars.

Surprisingly in some tests [1], foot was rendering faster than alacritty for me (Wayland, Nvidia GPU)

https://github.com/alacritty/alacritty/issues/289#issuecomme...

Can't live without Lua config

I didn't even know about that and I've been using kitty for years

iTerm2: cmd+shift+a = select output of last command. I can then cmd+c, open whatever editor I want (or `pbpaste | less` if I want `less`).

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.

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...

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 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.

Foot is really great. I often open terminals for executing single commands, so I appreciate its short startup time

I'm glad Alacritty is so conservative with adding features. There are plenty of options for "feature packed" terminals.

I use tmux for scrollback, panes, tabs, etc. So I'm happy there is an option for a barebones GPU terminal.

kitty is being rewritten in Rust from C.

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.

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.

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.

[0] https://github.com/alacritty/alacritty/issues/50

[1] https://github.com/alacritty/alacritty/issues/6578

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.

I think it's unfair to label tmux "stinky".

It is slower, that's true, but so many times I've had to restart my terminal or I've quit it accidentally and tmux has saved my bacon.

Performance is adequate (for me), it's cross platform and gives me multiple cut/copy buffers.

Terminals emulators aren't aware of tmux panes, so it'd likely needs to redraw the whole thing if even a single pane changes.

Tmux scans every character at least once.

It's more the latter: Ghostty doesn't introduce any groundbreaking features, instead it's a bunch of incremental improvements/nice-to-have's.

The closest thing is a Discord server linked in this post: https://mitchellh.com/writing/ghostty-devlog-003

Beta invites are nearly random, though.

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

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.

basically I don't need to use tmux anymore to manage my tabs and windows

Also fast, the dev is really nice, supports font ligatures, prefer lua config.

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.

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.

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

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.

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.

I can't remember what the issue was exactly, but Kitty does something that makes it work not-so-nice when SSHing into some machines.

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?

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.

> energy efficiency

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.

> energy efficiency

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.