Alacritty v0.5 | Hacker News Reader

Alacritty v0.5

blog.christianduerr.com

128 pointssbt567108 comments

Been using Alacritty on my Linux desktop for the better part of the year and it's been simply a joy. It convinced me to install it on my mac and windows machines too.

I know it's just a terminal and very mundane to be excited by, but the performance shows if you're a heavy command line user. tail logs look smoother, typing never lags, really well done.

Given its enormous latency, is that all placebo effect?

I'm sure it is. I use it because it works well in my config, specifically I was able to configure the fonts the way I wanted it. Before that I used xterm and it was absolutely fine. Typing lag? Please. The only terminals I've ever seen performance issues are the Mac ones like iTerm 2.

Here's a YouTuber doing some tests.

https://youtu.be/PZPMvTvUf1Y?t=586

Was a lot faster there.

Displaying gobs of output in a terminal is pretty much the most useless benchmark you can do for a terminal emulator. You never watch output that goes by faster than you can read, unless you're actively watching movies through aalib or libcaca.

I would be happy to have a "framedrop" equivalent for terminals when this happens, as it's totally useless from my perspective.

Not to say that optimizing throughput it's useless (total time adds up over the course of a day), but latency and start-up time are really what matters in a terminal emulator.

It's also hard to measure correctly, because some terminal features such as output reflow and ligature support hide major spikes in latency that you only experience occasionally but can be incredibly annoying (say hi to all url regex matchers!).

alacritty felt absolutely abysmal in the latency department when I last tried it one year ago, which is even worse than most libvte based terminals.

kitty is much better, but it's not exactly a lightweight terminal. It still starts in no less than a full second compared to mere a tenth of a second of urxvt, xterm or mlterm. urxvt always felt more consistent to me, but all three outclass pretty much all other terminals I ever tried.

For those using a tiling window manager, the built-in tabbing and multi-window support is pretty much useless too. Having true-color support is probably the only big argument I can see, which is nice to have for inband images, but again.. something rarely used in practice.

> You never watch output that goes by faster than you can read, unless you're actively watching movies through aalib or libcaca.

This is not true for me.

During development I often run programs that spew an enormous quantity of log output, and I'm watching to see if I notice a pattern in the output visually, or if it just looks normal. Either some critical or warning message in a different colour or boldface, or a shape to the messages that I'd recognise.

Although in principle I could use various output filters, grep etc., sometimes that's effort and I'd rather just run the thing and have it run quickly.

Also it's convenient to have all the output readily available if I do want to look at something that happened, as I can scroll to that place and look at pages of surrounding context in detail. If I use output filters, then I have to faff about re-running the program with different filters, or with all outputs enabled so I can step through everything around the event of interest.

Admittedly sometimes its better to output to a file and search the file, but sometimes visual output at 60Hz works quite well.

I have been known to skim manuals very fast as well. I guess in the era when man pages were everything, I got used to scrolling really fast to look for things of interest. It's interesting that a brain is able to recognise particular word-forms that flick by extremely fast, much faster than reading them. I've had people tell me they cannot do this, so I guess it's a learned skill.

Not only that, but when some terminal program decides to spew a bunch of output again and you don't want to interrupt it, you're going to have to wait until it's finished before you regain control.

No one wants to waste their time waiting for something that could be done already.

So faster terminal output can make a real, useful difference in everyday use.

For this situation, an action to skip output until it settles would be even better. A fast terminal isn't as fast as no terminal.

Is it as fast as Kitty now?, last time I check the fastest one was still Kitty (https://sw.kovidgoyal.net/kitty/)

It has had a lot higher throughput than Kitty for a long time, but whether it is perceived as faster is a different thing. Some people in this thread say alacritty has high latency, which might make it feel more sluggish.

Kitty has a better feature set imo, too, but is a shame the author is such an ass about Windows that he refuses to even contemplate support for it.

Why does that make him an ass? It's his project, he can do whatever he likes with it.

It doesn't, it is his attitude when people ask about it that makes him an ass.

Kitty seems to have lower latency, and you can feel it, but it has really weird broken font rendering for me.

I've used alacritty, and then just went back to using konsole. I didn't really get any feeling it was 'faster'.

Why does every rust project claim to be 'blazing fast'?

There was a blog post with some benchmarks in 2018: https://jwilm.io/blog/alacritty-lands-scrollback/ But not sure if this is still applicable.

Some other benchmarks show it as slower, particularly with respect to latency (where I agree with the people who say this is the most important metric: "throughout" has only really ever mattered to me in extreme cases, such as with mintty, which slowly renders all intermediate states); this was brought up in a Hacker News discussion of this link you just posted, and has been discussed elsewhere, such as reddit.

https://news.ycombinator.com/item?id=18006751

https://www.reddit.com/r/rust/comments/8ffddi/alacrittys_not...

The whole "Alacritty is the fastest terminal emulator in existence" just frankly just comes off as dishonest marketing BS given that people even elsewhere here on this thread keep reporting jank issues :/, and it kind of gives the Rust community in general a "bad look" since a lot of projects also claim they are "blazing fast" and it makes you wonder "are you really checking that? are you measuring the right thing?".

My comment about rust and 'blazingly fast' is a bit offhand, but my point is just because it's native, doesn't mean it's fast. People can, and do, write crappy slow code in any language.

C++ projects (or D, Zig, Nim, Swift, or your native language of choice) don't sell themselves as 'blazingly fast' every single time but all, in principle, produce fast native code.

If the competition was written in say Ruby or TCL they might have had a point in touting the language used as a performance enhancer.

But all terminals people care about are already C/C++ -- Rust doesn't have that much (if any) speed advantage there...

It's all down to algorithms used... It's not like terminal code will take benefit from e.g. memory aliasing related optimizations...

There are a ton of terminal emulators out there based on HTML5, CSS, and Javascript, little Chromium apps and similar. And on some platforms they're often the only ones offering certain features or extensibility.

And they're naturally much slower than Alacritty and any normal Linux terminal emulator.

>There are a ton of terminal emulators out there based on HTML5, CSS, and Javascript, little Chromium apps and similar.

Just not those people really care about -- except maybe the one in VSCode.

And of course, they are not those that Alacritty competes with and alludes to being faster to.

"Faster than HTML5-based terminals!!!" would be a pretty low bar, if not embarrasing as a motto...

Throughput vs latency. Latency is not the absolute best (still fine though) but it can keep up when you accidentally spam your terminal with a huge logfile.

> Why does every rust project claim to be 'blazing fast'?

It doesn't seem particularly mysterious to me. Performance is often a feature that an author of some software has put a lot of time and work into, is proud of and can be a differentiating factor between it and other alternatives.

I don't know if "every" Rust project makes the same claim, but one of Rust's wheelhouses is in performance critical code, so it's not particularly surprising---at least to me---when people who enjoy writing performance critical code produce such things in Rust.

Now, I don't really know the first thing about benchmarking terminal emulators and performance was never really a concern for me when I used to use Konsole. I personally switched to Alacritty because it worked better in cases that I cared about: https://twitter.com/burntsushi5/status/967896697421615105

I've used some of your code (ripgrep?), and it is fast.

I didn't claim it's mysterious, just that every Rust project I see says 'blazingly fast' somewhere on its web page. Other native languages that are fast (C++, D, etc.) don't seem to feel the need to advertise their speed.

Golang projects seems to use the same claims too -- even if they're way behind C/C++ etc equivalent projects in performance.

In many cases it's just newby devs surprised by how faster (almost for free) they get than some scripting language they used before...

Rust straddles the line between the statically typed, compiled languages and newer more featureful ones that tend to be slower due to things like GC, dynamic typing, running on a VM. For those migrating from C++ they want to advertise it as a better language without performance compromise. For those coming from the other side the primary benefit may actually be the increased performance.

In the case of Alacrity the author did go to great lengths to optimize and benchmark the text rendering. It really is fast. That's not usually an issue in a terminal, but I have had rare moments when an excessive amount of text output caused me to wait for the terminal to catch up.

>the author did go to great lengths to optimize and benchmark the text rendering

I think they went to great lengths to optimise the text output buffering but not necessarily the text rendering. Their benchmarks involving catting large files don't require the rendering to be fast.

And they never tell you how many blazing-fasts there are to a regular fast.

On Windows, Alacritty is actually extremely fast compared to anything else I've tried, including windows terminal, powershell and CMD, from startup time to keystroke delay. Unfortunately many of the third party terminals for windows that have normal terminal features are Electron apps and are so slow they're unusable (looking at you Terminus). On Linux I don't see a difference between Alacritty and konsole, terminator, rxvt, etc.

I didn’t realize Alacrity supported Windows. That’s great to know! Finding useable console on Windows was always a pain for me.

I've noticed the same thing, and on macOS, too.

Non-free operating systems have a really poor selection of terminal emulator software, both in terms of feature sets and in terms of performance. They're usually inflexible (Microsoft's old terminal emulator, like for PowerShell and CMD by default) or extensible but based on web technologies, and in both cases, they're slow.

iTerm2 can be made to perform passably, but only by throwing GPU acceleration at the problem, which doesn't seem to be necessary for popular and banal terminal emulator choices on Linux, like Gnome Terminal and Konsole.

The performance differences become much more visible if you're a tmux user, in many cases.

I've done simple test with this command `time fd` on ~/.

Actually alacritty was faster than kitty and konsole.

2.8x 3.0x 3.6x

> I've used alacritty, and then just went back to using konsole. I didn't really get any feeling it was 'faster'.

Anecdata: I switched from Konsole to Alacritty about a month ago, after playing around with it for a bit, going back to Konsole, and realizing how everything in Konsole now felt surprisingly sluggish. Not in the sense that I can actually tell how much slower a certain operation is, but it feels like Konsole is working with one arm tied behind its back.

FYI, still doesn't support font ligatures, if you're into that sort of thing: https://github.com/alacritty/alacritty/issues/50

Last time I checked I remembered encountering absolutely horrendous input latency with alacrity, does anyone know if this is still the case?

I tested it about a week ago:

https://news.ycombinator.com/item?id=23954002

It's pretty much on par with Visual Studio Code.

There's also this:

https://github.com/dsissitka/dev-env-config/commit/96f162c4b...

They still claim it's "the fastest terminal emulator in existence."

I fought really hard to like alacritty and tune it to be fast and ultimately it was laggy and slow as heck. The rendering pass was abysmal last I checked. If there are too many characters on the screen, fps falls off a cliff. No modern terminal should have render performance of O(n), n=characters. If I hit enter you don't need to re-rasterize all those glyphs.

st with tmux is pretty great. Just about the lowest input latency you're likely to find on Linux, AFAIK, and tmux means you need few or no patches to st to have a full-featured term. Not as low-latency as Mac terminal, but then again I don't know of a Linux terminal emulator that is.

The last time I tried st the input latency was quite a bit more than xterm. Noticeable enough to feel the difference when opening them side by side and typing normally. xterm is really as good as it gets if you want a buttery smooth typing experience.

Kitty can match xterm's latency while having better throughput. The only drawback is the forced anti-aliasing, but that's easily patched out (in freetype.c, change the last line of get_load_flags() to "return base | FT_LOAD_MONOCHROME | FT_LOAD_TARGET_MONO;")

> Not as low-latency as Mac terminal, but then again I don't know of a Linux terminal emulator that is.

Hmm. Am I tripping? Would you mind installing Konsole on macOS via Homebrew and telling me whether latency still seems that way to you?

Which platform and version? I run 165Hz displays and the latency is pretty good.

Is it the placebo kind of "pretty good" or did you actually measure it with a >=165fps camera?

For example, when I do a selection, the selection follows my cursor on every frame. I don't have cameras that fast, but the end to end latency on a keypress seems to be mostly from my keyboard controller and the transport.

Not having smart copy is a complete dealbreaker to me https://github.com/alacritty/alacritty/issues/1919

Windows Terminal has smart copy by default now and the UX improvements of it are a huge difference. I use pantheon-terminal (i.e. the one from elementaryOS) on my linux environments, and the only reason is because it also has smart copy.

It means that on all the applications I use, Ctrl+C does _exactly_ what I expect, all the time. I don't want to have to context-switch when I go to a terminal and remember "oh yeah, I need to hold shift too" and accidentally kill the running process like a "tail -f" that I have running for logs on some server.

I understand it might be technically difficult to implement, but it means I can't switch to Alacritty without inevitable daily frustration.

I mean, with Xorg, just select and middle click. Am I missing something?

Yes. It's not like every other app that exists on my system. Context switching is a nightmare. Stop shipping bad UX.

Select+middleclick works with every app on your system.

No it doesn't, in a browser, middle-click will turn on drag to scroll, unless you click on a link in which case it will open a new tab. Which is something I use every day.

Grandparent said:

> with Xorg

The behaviour you describe only happens under windows.

Okay you're right - but on Firefox on Linux which I just tried, middle click doesn't copy. It actually just does nothing.

I mean... it pastes, not copies. Selecting copies, middle clicking pastes.

Someone has probably written a javascript widget that breaks it, but if it's a textarea or the URL bar, you can middle click to paste.

Selecting most definitely does not copy. It would be horrendous if it did.

Selecting in X absolutely does copy to the PRIMARY clipboard. Selecting then copying (e.g. with Ctrl-C) copies to the CLIPBOARD clipboard. Middle clicking pastes from the PRIMARY clipboard, and Ctrl-V pastes from the CLIPBOARD clipboard. It is incredibly useful, not horrendous.

Edit: and you yourself confusedly claimed selecting copies just an hour ago: https://news.ycombinator.com/item?id=24017588

I was talking about copy-on-select in terminals, i.e. terminals I no longer use cause I find that behaviour very frustrating.

Well there's nothing special about terminals, it should work the same everywhere you can select text. It goes into a different clipboard from where explicit copying goes (though most modern distributions have a way to turn on synchronising of the two clipboards - maybe you have that on without realising?).

It 100% does. Every app, select copies to primary.

Middle click to paste only pastes when you're clicking in a place you can type input, like a text box or the URL bar. Just places Ctrl-V will paste. Middle clicking links to open new tabs works perfectly, as do other uses of middle click, like closing browser tabs.

If the focus is not in a text field it doesn't make sense to paste.

But if the focus is in a text field (where it actually makes sense to paste) in a web browser, then middle clicking does in fact paste, just like it does in every other sane X application.

I understood the comment as middle-click would copy, not paste, because I was talking about copy behaviour primarily. Yes middle-click to paste does make sense in input fields.

It’s cognitive overhead to remember a different key for something as common as copy+paste. What if selection was holding down middle click and copying was right click? This keybind may seem easy for you but it is arbitrary and therefore hard to remember, and is non-standard. I struggle with different copy semantics across OSes and terminals all the time. It’s very frustrating.

That's your cut buffer.

Heavy/Traditional Xorg users have enjoyed + gotten used to the multiple clipboards available. [1]

Users are migrating to Linux from Windows/MacOS and are not used to it; and asking for changes. (Remember Chrome + FF changing the selection behavior on the address bar to match windows?) [2] [3]

[1] https://wiki.archlinux.org/index.php/Clipboard

[2] https://bugs.chromium.org/p/chromium/issues/detail?id=26140

[3] https://news.ycombinator.com/item?id=22832199

I don't know what a cut buffer is is, but middle click copies to primary

clipboard is the Windows style paste. I personally never really use clipboard, as using primarily is so much easier. I guess there might be using it at the same time, but I've personally never felt the need for two buffers at the same time.

I'm primarily an urxvt user: select copies & middle pastes. What terminal are you using that middle click is mapped to copy?

Sorry, i meant paste on middle click.

> I've personally never felt the need for two buffers at the same time

I find two buffers convenient when grabbing both url and title for a hyperlink.

I use both, but I admit it's a bit idiosyncratic.

When immediately pasting after copying, the primary X buffer is obviously superior as it requires fewer actions, and only one hand.

However, if I'm selecting something to keep in the buffer for a bit before pasting, I'd often screw myself by overwriting the buffer via random clicks in between.

Now I'm in the habit of using primary in the cases when I know I already have an input field or prompt ready and waiting, and the very next thing I'm going to do is paste. When there are steps left to be performed after copy but before paste, I use the clipboard.

I know it sounds overcomplicated and perhaps insane, but it's actually totally automatic at this point, and doesn't feel like it costs any mental cycles at all. For the first case, either I just readied the other program for input within the last few seconds, or at least it's visibly waiting for input on my screen. If not, then Ctrl+C it is.

For Ctrl+C, I can see how the program can be made to differentiate between which one you want by whether something is highlighted.

But how does it know what action to take on Ctrl+V?

I've literally never used Ctrl+V for anything other than paste, so I'm honestly not sure how it's implemented on Windows Terminal or pantheon-terminal. But the way they have it, it always does what I expect.

I'm also very much not a vi user because, for similar reasons, context switching is a nightmare. I use nano everywhere because it works almost exactly like everything else in my system (but honestly I should probably install micro everywhere).

Ctrl+V is for quoting a control character.

IOW: if you press Ctrl+D, it will cause EOF on the input stream. If you press Tab, it causes your shell to attempt to autocomplete. But if you press Ctrl+V Ctrl+D, or Ctrl+V Tab, it will insert ASCII code 0x04 or 0x09, respectively, into the input stream.

I use SHIFT-INSERT in Windows Terminal (and in Linux terminals too, actually, where it works great).

That requires using both hands and not only my left hand; if I'm scrolling around or clicking around, I'll have my right hand on my mouse. Ctrl+C/V is a one-handed hotkey and works in every other application. I'm not going to use a different hotkey for a single application. Like I've already said, context switching is a nightmare. I want the same basic hotkeys everywhere.

You could make Ctrl+V send SHIFT-INSERT if you wanted.

Okay sure, but that still doesn't solve anything because the fundamental issue is with the Ctrl+C in Alacritty not behaving the way I'd want it to.

Hmm.. I wonder if you could get your desired behavior by rebinding Ctrl+C in Alacritty to copy, and also using the "stty" command to change the keyboard shortcut that sends the interrupt signal from Ctrl+C to something else.

The latter may be necessary because traditionally you would interrupt programs (like say a runaway cat command or some other long-running process) with Ctrl+C, so using Ctrl+C to copy would normally conflict with that.

Though I suppose that a terminal could be implemented in such a way that Ctrl+C is used for copy if some text has been selected and when no text has been selected it could pass that Ctrl+C on to the application running in the terminal. This way Ctrl+C could remain as the shortcut for sending an interrupt signal to apps in the terminal, and you wouldn't have to mess with stty.

Remapped to control shift v which can be used with one hand

As someone who spends most of his computing time under macOS, this by far is my most frequently encountered frustration under Linux. You get so used to ⌘-C and ⌘-V doing the same thing everywhere, terminal included, and when that's gone it's maddening.

Copy on select, who needs a keyboard ;)

Copy on select is the bane of my existence. I use selection as a reading aid, to follow where I'm looking and to help me focus. I do this in the terminal all the time. If it clobbers my clipboard, this does _not_ help me.

Then don't use it? Selection doesn't overwrite the clipboard, unless your system is configured to do that specifically.

To elaborate, X11 has two clipboards by default:

PRIMARY: Copy by select, paste with middle click or shift-insert.

CLIPBOARD: Copy with explicit copy action, paste with explicit paste action (mostly ctrl-c/ctrl-v, except in terminals/vim)

I'm not sure if this is carried over into Wayland. I've seen some Mac terminals offer copy on select and there it does clobber the clipboard, unlike on Linux.

Vim exposes these as the * (PRIMARY) and " (CLIPBOARD) buffers

Wayland keeps the same behaviour

You can try mapping it to super+c/super+v, as macos does. (If apps you use don't support key rebinding, then a little xdotool|autohotkey|autokey magic can do it.)

I don't use a mac though, and no, very no, thanks. I want my terminal to have the SAME hotkey as every other app on my system, not something different. And I'm not going to relearn Ctrl+C/V with a different hotkey globally. That's too crazy an ask.

Every decent app should support copy paste with ctrl+insert/shift+insert and doesn't conflict with terminal use of control characters... The alternative is to stop using terminal emulators.

You can also set interrupt to something else than ctrl-c, using stty.

Thanks for letting me know about smart copy, I had to check which GTK terminals support it:

- Tilix supports it, just set Ctrl-C/Ctrl-V as copy/paste and it'll intelligently handle it.

- Kitty does as well, but needs to be configured manually to do so.

- Terminator has a smart copy option enabled by default.

- No support with default GNOME terminal.

EDIT: I stand corrected, GNOME terminal supports it as Tilix does: just set Ctrl-C/Ctrl-V as copy/paste. Perhaps this works with all VTE-based terminals?

I set alacritty to bind

chars: "\x03"

which is what Ctrl+C normally sends, to Ctrl+Shift+C, and copy to Ctrl+C. This is after getting used to the default behavior of VTE-based terminals (like GNOME Terminal), which set Ctrl+Shift+C to send Ctrl+C if you set copy to Ctrl+C.

(Also "\x04" (Ctrl+D) to Ctrl+W, which will close things like python if it's running or the terminal if nothing is.)

I've been using Alacritty for a while, but eventually got back to the standard Terminal.app and iTerm.

The former feels snappier (and is probably GPU-accelerated as well anyway), looks better and comes out of the box. The later has way more features.

I just tried Alacritty 0.5, and it has some weird artifacts when text color changes, which happens a lot when the shell highlights commands, or when editing text.

Anyway, it's great to have options.

For what it's worth, iTerm has been GPU-accelerated since 3.2, when it got a new Metal rendering engine: https://iterm2.com/downloads/stable/iTerm2-3_2_0.changelog

So if I'm using Ubuntu, I'm supposed to set-up a Rust toolchain and keep it updated to be able to install Alacritty?

The good news is, the rust toolchain is probably one of the easiest to install and update, of almost any programming language. https://www.rust-lang.org/tools/install

Deal-breaker. But now I know about Kitty, which is supposed to be faster.

They included a deb until this release :-/

There are packages in the Pop OS PPA[1] I am planning on using. (They haven't added 0.5 yet.). I won't add the PPA, just download and install the deb.

It looks like this release has been published to crates.io[2], which was a blocker to getting alacritty packaged in Debian[3], so hopefully soon it will be added and synced to Ubuntu.

1: https://launchpad.net/~system76/+archive/ubuntu/pop/+package...

2: https://github.com/alacritty/alacritty/issues/357#issuecomme...

3: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=851639

Version 0.5 has been added: https://launchpad.net/~system76/+archive/ubuntu/pop/+package...

I've been using urxvt for some reason.. maybe out of simplicity. It's color range is bad though, though at the same time it's colors are more accurate than if i run xfce4-terminal, for example.

I migrated from urxvt to Alacritty a little less than six months ago, here are some reflections.

Despite all the talk about performance, I find urxvt to be more responsive. However, it is really not something that bothers me during day-to-day usage and I suspect that it will improve over time as urxvt is about as dead as it gets when it comes to a code base. I also ran into some font scaling issues across monitors [1], but I suspect urxvt gets around this mostly by being completely ignorant of things that have happened over the last 20 years.

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

Some awesome parts on the side of Alacritty. The community is nice and responsive, documentation good, code modern, and configuring it is straightforward (auto reload upon file edit anyone?). Try getting fallback fonts to work properly with urxvt for example, that is what ultimately drove me away urxvt as the rendering issues I encountered with CJK fonts just drove me up the walls. The worst being somehow shifting the font size depending on whether a character was present in my Japanese font or not.

Bonus, I believe the following is sufficient to emulate the look and feel of urxvt in your `.alacritty.yml`:

    window:
        padding:
            x: 2
            y: 2
    draw_bold_text_with_bright_colors: true

I went from xterm to urxvt (which I used for many years), back to xterm, then to st to alacritty and finally settled on kitty, which I love.

kitty has TrueColor support, way more features than aclacritty (which seems to take a more minimalist approach, if I remember right, and this was one of the main reasons I switched from the latter to the former), and in my experience has been both extremely fast and extremely stable.

The only thing I really don't like about it is that it seems to copy continuously to the clipboard when I click and drag over some text, so pieces of that text end up cluttering my clipboard history (for which I use parcellite on Linux). The final selection when I finish moving my mouse and let go of my left mouse button works fine, as usual, so I'm willing to live with this... though I'd still prefer it not to copy anything to my clipboard until I've finished clicking and dragging and released my left mouse button.

All we wanted was tabs, but instead we got... tmux copy mode? Even though we already have to use tmux because... no tabs.

It's finally usable for me as well [0]

Especially for lower end machines like the pinebook pro it's nixe to have a smooth scrolling and rendering experience. The only terminal that renderd without much of a delay on it was st[1] And that I would probably have to patch [2] to get a great experience out of. (it's already good)

[0] https://github.com/alacritty/alacritty/issues/128#issuecomme...

[1] https://st.suckless.org/

[2] https://st.suckless.org/patches/

Edit: Both terminals kitty and alacritty seem to work now out of the box on my setup.No environment variablres required :)

The one issue I had with st, and it was big enough that I had to switch, was that it crashes on some emoji. It's actually not even an st issue, it's upstream in ... some X font library, I think, but that just means that I can't take my st with me from computer to computer. It sucks, really, because st's great otherwise and it's not even their fault.

Been using alacritty on Linux for about a year. After some customisation and key binding setups for tmux, it's easily the best terminal emulator I have used on Linux.

Don't know for sure, but it does feel faster and more polished than kitty.

I tried the portable install on 64-bit Windows 10 1909 Professional and it didn't work. The cursor was stuck in the upper left hand corner and I never got a command prompt.

I still have issues that the font is bigger on my laptop screen than on my external screen. This is really annoying.

I found that changing my keybinding to start alacritty with this environment variable set seems to work:

  WINIT_X11_SCALE_FACTOR=1.0 alacritty

https://github.com/alacritty/alacritty/commit/93780ef0929e08...

Thank you for putting a "what this is" paragraph in the referenced page.

Kudos, impressive release

Reply on news.ycombinator.com