wezterm VS alacritty

wezterm (Linux, Macos & Windows)

A month ago, I came across WezTerm, a new GPU-accelerated, cross-platform terminal emulator written in Rust (and I’m not a Rust fanboy, for real!). It piqued my interest, so I decided to give it a try.

Select all seems a bit risky in a terminal because it could contain way more information than you'd expect.

e.g. I want to `cat` a file to make sure i've got the right one, but I accidentally cat a full 1gb sql backup rather than the tiny 50 line script I was expecting. Sometime later, I try to select all, copy, switch application, paste for some reason but now I'm stuck waiting for 1gb to copy over

Personally I'm a bit more cautious about copying from a terminal.

Either way if that's what you really want to do, you can check the repo to see how other people scripted it into wezterm:

https://github.com/wez/wezterm/discussions/2026

I used Lua for years to configure my awesomewm desktop environment. Then, I started using it to configure my Wezterm. Since I bumped into an Emacs bug (lsp-mode bug to be fair), I switched quickly to Neovim after 20 years of Emacs, and I am using Lua to configure my Neovim. Last but not least, OpenResty gives my Nginx superpowers with Lua.

wezterm (Linux, Macos & Windows)

I started using wezterm recently and really like it. It's cross platform and supports sixel graphics.

https://github.com/wez/wezterm

While WezTerm is a great terminal with sane defaults, it doesn't provide the default key binding to open the configuration file and edit it. That is understandable, everyone may have their own preference for that. Here we will figure out the recipe that would work everywhere and abide by modern standards.

Yeah, it's only for nvim or for your own lua projects.

For WezTerm annotations, afaik there is currently only an open issue without much progress: https://github.com/wez/wezterm/issues/3132

> [...] waiting for one or more terminal emulators to get together and add some ridiculous new escape codes [...]

I'm definitely of the opinion[0] that we haven't yet reached the limits of the "terminal emulator" UX paradigm.

The past few years do seem to have seen a resurgence in terminal emulator innovation due in part to a combination of new languages, the prevalence of GPUs, and a realisation that many of the existing terminal emulators weren't interested in any innovation in certain directions.

I've particularly been interested in the possibilities provided by the Terminal Graphics Protocol (which I discuss more in the linked comment).

A couple of years ago I switched to WezTerm[2] due to a combination of its graphics support, implementation language (Rust) and that its main developer seems to be interested in a combination of both solid support for existing standards & opportunities for innovation.

WezTerm also provides opportunities for customisation both in terms of shell integrations and of the application itself[3].

> [...] new escape codes [...]

Also, on this aspect, it may not even be necessary to create new escape codes--recently I discovered the `terminfo(5)` man page actually makes a pretty interesting read[7], in part because it lists some existing escape codes that seem like they have potential for re-use/re-implementation in the current day's more graphic-based systems.

---- footnotes ----

[0] As I mentioned in a recent comment on a thread[1] here:

"Motivated by the thought that at the current point in time perhaps the 'essence' of a 'terminal' is its linear 'chronological' presentation of input/interaction/output history rather than its use of 'text'."

[1] https://news.ycombinator.com/item?id=40475538

[2] https://wezfurlong.org/wezterm/

[3] While I'm definitely not a fan of the choice of Lua as the extension language, I have now at least hit my head against the wall[4] with it enough that I can actually get more complex custom functionality working.

[4] I've started to write up some of my Lua-related[5] notes & more general WezTerm[6] notes so hopefully it'll eventually be an easier road for others. :)

[5] https://gitlab.com/RancidBacon/floss-various-contribs/-/blob...

[6] https://gitlab.com/RancidBacon/notes_public/-/blob/main/note...

[7] As one does. :) It was a fascinating/amusing time capsule in terms(!) of mentions of weird hardware terminal quirks that at one time ("before my time") needed to be worked around; interesting escape code discoveries; and, the mention of a term I had not thought of for decades but was at one time of importance: NLQ! :D

For a moment I was concerned about the terminal emulator alacritty[0], which this post, as it turns out, luckily is not about.

0. https://github.com/alacritty/alacritty

Is not mandatory but for the ones interested, I am using the Alacritty terminal, so if you're interested you can download it using the following command in your terminal:

Alacritty is a cross-platform, GPU-accelerated terminal emulator. find out more

alacritty (Linux, Macos & Windows)

The Alacrity terminal is incredibly fast and customizable. Try working with a large project in Vim using, for example, iTerm. You might be pleasantly surprised.

Wezterm gives you basic stuff like scrollbars that Alacritty refuses to do: https://github.com/alacritty/alacritty/issues/775

It's opinionated, which comes with upsides and downsides. I won't blame the maintainer to keep things focused, feature creep (even for worthy features) can kill a FOSS project.

Another example is sixel support, there's a fork where it all works but is not sufficiently "proven" (code quality just as well as sixel being the best fit for the problem)

https://github.com/alacritty/alacritty/pull/4763#issuecommen...

It may be annoying but I get the reasoning, and there are other terminals.

alacritty (Linux, Macos & Windows)

> Ligatures: ok, nice, possible in terms too (hopefully Alacritty one day)

I wouldn't hold my breath. Seems like its getting the iPad calculator treatment[0]. Which is to say rather than ship something working that can be improved, they're leaving a UX void.

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