[inickt]

I'd love to see the Alacritty terminal backend swapped out with libghostty (or more likely libghostty-rs). The work Mitchell is doing with Ghostty and the approach Zed has taken seem super aligned.

And Mitchell definitely seems to want to make Alacritty an easy target for conversion, he was just talking about being open to help support Warp with it: https://x.com/mitchellh/status/2049159764261925005

[avarun]

Looks like Mitchell said he's already on it https://x.com/mitchellh/status/2049514540505964549

[inickt]

He gave me a quick response, should have checked back before posting here

[arijun]

What is Ghostty's advantage over Alacritty?

[inickt]

I think Mitchell outlined his vision for libghostty pretty well here: https://mitchellh.com/writing/libghostty-is-coming

Alacritty is already pretty performant (relative to a lot of the other terminal emulators), but my read is Ghostty has been going hard over performance/standards/protocols (like Kitty).

[iammrpayments]

The maintainer doesn’t have bad temper.

[arijun]

I did consider that. I remember nope-ing out of alacritty in the early days after seeing the developers response to people requesting a scrollback buffer. It amounted to something like "I use tmux, and if you don't, you use the terminal wrong." It left a bad taste in my mouth.

[maxnoe]

One would be support for ligatures

[zamalek]

Ligatures are a renderer issue, so using alacritty as a lib wouldn't have this issue (it does demonstrate their hardline stance). Another example that would translate is how long it took them to support disambiguation of key combinations: https://github.com/alacritty/alacritty/issues/6378 (2019-2023). Of course, the maintainers are free to do whatever they want with the project - but such things do make alacritty-as-a-lib an exceptionally bad choice for situations where you want things to just work.

[LucasOe]

The Zed terminal already supports ligatures.