I don't think Konsole is actually faster than Kitty or Alacritty. Kitty is really nice and an innovator in a lot of terminal standards. It's also non-commercial and not related to any sort of startup (not that Konsole is either). It's definitely my first choice of the bunch, followed by Alacritty.
Konsole seems to keep up with modern features as well. For instance I realized yesterday that it renders the newer progress codes that clis can emit. I am content.
There's always gonna be something that's better, faster, bigger, badder, stronger, thicker, firmer, etc., and terminals really aren't one of those things where I am interested in exhaustively testing all of them to find the truly greatest one. A terminal is also one of those things where if you find one that is perfectly adequate then there's little motivation to even bother using trying one. And there's the whole "devil you know" aspect. The only reason I rarely try a different terminal is if the stock terminal on whatever OS I'm using lacks some basic niceties that should be expected in the year 2026.
I like Ghostty because I find it both fast and configurable, and it's multi-platform without treating macOS like the red headed step child. I also appreciate how its configuration is text-based, which I prefer to someone's opinion of how a configuration GUI should behave, and I think it's good the developers aren't wasting a second of their time thinking about a configuration GUI.
I also thought like that, but you only to set some defaults and you're ready to go. If you still prefer a GUI there are online generators. Nowdays you can also vibecode them, they are very simple and any LLM will do it right
Because the old ones refuse to change or add New features. Which is fine, there are plenty of users who dislike chabge. However, it means you have to start a new project if you want to support most modern features.
If you have to see them, they aren’t defaults. It’s bad enough that Windows Terminal doesn’t expose its full configuration and forces you to edit the config by hand for more advanced stuff. Feels like a step backwards when something like iTerm 2 gives you access to all settings in a (admittedly kinda crappy) GUI. This also kinda begs the question why there’s not a /TUI/ configuration manager shipped…
Seriously, iTerm2's config GUI is so confusing and convoluted. I figured it out, but I always found it annoying trying to remember which menus to dig through to find that one setting I need.
That's what I thought at first. But all the niceness of having a settings GUI didn't pay the unwanted bloat. My first try was to find a "debloated iTerm2", and then I found out that Ghostty's settings aren't the burden that I thought they would be
The lack of a config GUI in ghostty used to bother me, but to be honest now I just describe to Claude what I want to change and it does it. It would still be nice to have one eventually but I can see the argument for deprioritizing it.
The advertised point is it needs zero config to work outside of the box. For example nerd fonts are included by default whereas you need to install them if you are using let’s say iterm2.
You could, but my answer would probably skew your opinion about as much as yours did mine. :D
To me the point of Konsole is that it works well, plus it's already there. Ghostty I need to make an effort to have it, however small it is, and I'm just trying to understand what I'd be missing if I didn't.
Konsole is not already there for me. I would have to make an effort to get Konsole, just like Ghostty. I’m struggling to see what point you are trying to make. Do you want someone to tell you Ghostty is better than Konsole to convince you to switch, or … not?
This days I don't really care about the terminal I use. It's xterm on OpenBSD, konsole on Fedora KDE, terminal.app on MacOS,... As long as I can use cli and the few TUI software I use.
Kitty is really nice, a programmable terminal that does everything I want, GPU rendering, etc. I haven't used Ghostty yet but one of its advantages is libghostty, modern terminal emulation as a library.
> libghostty: a cross-platform, minimal dependency library that exposes a C API so feature-rich, correct, and fast terminal functionality can be embedded by any application anywhere.
A couple of annoyances I've had shipping CLI apps to Konsole users:
1. By default, Konsole disables OSC8 link support. Users can enable it manually, but you need to ship fallbacks by default since otherwise the default users will have a broken experience. Ghostty, Kitty, WezTerm, etc all ship working OSC8 support out of the box.
2. No built-in Nerd Font support, so if you want to render icons, you need to tell your users to set up a patched font or else have fallbacks. Ghostty and WezTerm ship built-in Nerd Font fallbacks.
That being said Konsole is much better than most emulators. iTerm2 is not bad, although it lacks Symbols for Legacy Computing Unicode support (which all of the above have, including Konsole). The worst by far is Apple Terminal, truly the IE6 of terminal emulators.
I believe that the default behavior should be to never open a link without a confirmation from the user that this may be done.
This should be enough to avoid malicious links. I do not believe that completely disabling links is a good default, because they are very frequently useful when you read some text file in the terminal window.
Yes, I agree. Ghostty et al don't open-on-click, but on hover they'll show you the URL and there's a keyboard shortcut + click to open. This is much better UX than disabling OSC8.
"One implementation of a feature had a bug, therefore this feature should be turned off on all implementations by default" is probably not going to convince people who think the feature is good.
If you don't want to be able to have clickable hyperlinks, by all means use Konsole — no one is forcing you to use Ghostty. But if you want to know why people like Ghostty's approach vs Konsole's, it's because Ghostty pushes terminal emulator features forward and is low latency. Konsole is low latency and adopts some but not all features that other people invent. It's a noticeable difference and so people who like the feature part of the former like Ghostty/WezTerm/Kitty more than Konsole. If you don't care or dislike that part, and want a more conservative terminal (that is also low latency), Konsole and many others further on the conservative spectrum exist.
It’s not just one implementation. Browsers have been struggling to get this right for decades and now we are destined to repeat all the same problems all over again with an entirely new syntax of inlined markup.
Bugs are fine, but this wasn't really a bug. It was lack of foresight.
I haven't used Konsole, but I do like this "recent" focus on terminals and have used many of the new ones. Dailydrived st,alacritty,wezterm,ghostty,kitty,foot (probably forgot some) and I live for the regex pattern matching copy shortcuts etc.
I learned about OSC8 because my terminal (whichever it was) used one of its features and I didn't know it was possible to do that. My immediate thought was, how is the security?
And it is very disappointing to see how little effort people have spent on that. That is really one part that I expect more for modern incarnations of the old terminals where I can sort of forgive them for the lack of security posture.
I like ghostty, I really do. But this is not a good look, and to be clear it isn't just ghostty. Without looking for it I've stumbled upon several OSC8 bugs (in other software) recently.
I don’t. But the problem with OSC8 is it opens up whole new vectors for security vulnerabilities in an application that is, by intent, used for some of the most security sensitive work in our jobs.
I wouldn’t mind OSC8 so much if it had proper security auditing but it doesn’t. The whole thing was pushed by one guy on a GitHub gist who blocked anyone who dared discuss security issues.
At least with browsers, you have masses of people testing these things. But there’s no rigour to any of the tests that happen with terminal emulation. Let alone independent security audits.
And at this rate, it’ll only be a matter of time until we see “don’t cat untrusted READMEs” advice because they might contain boobytrapped escape codes. Which is an absurdly bad place to end up.
So far I can only think of 1: term vulnerabilities due to ANSI escape sequence parser bugs. And that’s exactly the reason I’m suggesting OSC8 should be off by default.
What's so bad about Apple Terminal? I've tried iTerm2 and others but never found a compelling reason to use them over the stock app. I don't live in the terminal like some do, though.
1. The Kitty keyboard protocol, which makes it impossible to distinguish e.g. Shift-Enter from Enter
2. OSC8 hyperlinks
3. It breaks on APC queries, so you need special handling to not emit them
4. Symbols for Legacy Computing Unicode support
5. The Kitty Terminal Graphics Protocol (or sixel)
6. OSC 9 notifications (or any of the later versions)
and a bunch of other stuff, this is just off the top of my head. For a long time they didn't even support 24-bit color, although they fixed that in Tahoe.
It's totally fine for basic UNIX tooling, but pretty painful if you're trying to make nice interactive TUIs.
I've always found emojis in the terminal distracting, so it's actually quite a relief to learn that Konsole is guarding me against a whole other class of glyphs and logos.
For me it's simply that iTerm2 got really fat over the years, and Ghostty was a nice and slim alternative - plus it has one of the better Kitty Graphics Protocol implementations which is fun to tinker with. e.g.: https://github.com/floooh/chipz-kitty (needs zig-0.17.0).
for terminals I personally am using kitty, but libghostty is great and powers ghostel in emacs which is amazing. Also note if you start trying to look at unicode correctness, in my experience ghostty is in general the best among all alternatives.
1) Personal preferences: different terminals come with different defaults, some people do not want to tinker with the settings, so they just stick with whatever immediately clicks.
2) Technical curiosity: some people probably started their own terminal project just for the fuck of having made their own - and they eventually gained a userbase.
3) Feature set: Most terminals implement most features these days, but at the time these projects started, you'd have a feature matrix between features and terminals because most terminals lacked some features; so people would pick whatever suited their needs.
Personally I've been using kitty for years mostly due to 3), at the time I chose my forever terminal, I evaluated like 12 different ones, and kitty was the only one that covered most of my needs without feeling like it suffers from random quirks, and I like that it has built-in terminal multiplexer (a'la tmux) and emoji picker.
For me, the main reason to use Ghostty is simply that mouse support works right out of the box. In Konsole clicking a spot to move the cursor only works if you're using Bash. While it also works with the Fish Shell on Ghostty.
Same here. ghostty + fish = just works out of the box, no plugins or dotfiles needed. Plays well with accessing remote tmux claude/codex sessions as well.
> Konsole is way faster than any of those on my computer and it has all the usual suspects I'd expect from a modern terminal emulator.
Same boat here, though I also get to enjoy some of the benefits of libghostty, via ghostel in Emacs. Ghostel is noticeably faster when there's a lot of output being dumped, but I don't often need the speed and use it only because it's integrated rather well into the rest of my Emacs.
> tmux -CC integration
If you can stomach Emacs, there are at least two packages that implement this, one via eat and another via vterm, though none via ghostel just yet. Shouldn't be difficult to port, though.
I assume that this depends on your computer/GPU/GPU driver.
I have used Konsole for many years and I have used kitty for about 2 years in 2024/2025, then I have switched to ghostty around the beginning of 2026.
At least in my computers (with NVIDIA GPUs and Gentoo Linux), kitty was many times faster than Konsole and Ghostty even faster.
Moreover, in the now somewhat distant past when I was still using Konsole, it did not have some font rendering features that I desired, but that might have been solved meanwhile.
A reason why the terminal emulator speed is important for me is that I frequently compile big software projects and I find it unacceptable for a compilation to be slowed down by the low speed at which the compiler output is displayed on the terminal window, which happened frequently with terminal emulators older than kitty and ghostty.
Because I run in parallel other programs and I want to interact with their windows, which would be much too cumbersome if I needed to switch between a virtual console and the GUI desktop forth and back any time when I want to watch the compiler output.
> A reason why the terminal emulator speed is important for me is that I frequently compile big software projects and I find it unacceptable for a compilation to be slowed down by the low speed at which the compiler output is displayed on the terminal window
I’m strongly skeptical of this as pty are character devices and buffered. Programs and terminal are very loosely connected.
Compiling any big software project produces far more text output than can be stored in any pty buffers.
There are a few big projects that redirect the compiler output and attempt to print only one line per output file, so when all goes well there is much less output text, but with those it is usually more difficult to debug failures.
> There are a few big projects that redirect the compiler output and attempt to print only one line per output file, so when all goes well there is much less output text, but with those it is usually more difficult to debug failures.
Why? If you use something like tee(1), you can get the full log in a file and then filter line according to what you want.
> Compiling any big software project produces far more text output than can be stored in any pty buffers.
The reason of my skepticism is that, according to your statement, reading a source file, then writing the compiled object file is way faster than a few printf through a kernel object in memory. Even for the terminal consuming the characters, parsing, and displaying the lines should not be a computation hog for most terminals
I was sceptical for decades as well.
But they are amazing - no more closing the xterm by mistake. I'm using those because I wanted for example a single window with THREE consoles open at once AND being able to handle some ANSI crazy theming.
I don't know Konsole, but kitty have tons of features other "plain" terminals lack. It's not just about speed (which I never got the obsession about either)
For me: it doesn't really "bring" anything more than what I expect from a terminal.
In Mac, we had the default terminal app which has some problems with TUI apps and other small issues. iTerm2 is the replacement that most users use, but it become too bloated with useless features and AI, while it was hard to keep a good config file that I could share between devices. Ghostty was a sane mid-term for me: a good and modern terminal, with a simple config file, maintained by someone that I trust (Mitchell Hashimoto) and only that.
About Linux: I don't use Ghostty in Linux because I'm comfortable with Konsole.
I don't know about the others as I used Terminal.app on mac since Panther, but Ghostty has been a pretty good upgrade, at first offering 24-bit colour which Terminal.app didn't have at the time of its release. I also like the shell integration such as easy selection of command output. I don't ask much from a terminal as evidenced by using Terminal.app for almost 2 decades, but Ghostty has not once been an issue and is 'invisible' to me.
Lots of things bother me about my terminal emulators, and it's almost always in the category of "things don't work right". It's never "I wish my terminal emulator ran faster." Ghostty seems hyper focused on speed, with the negative side effect that compatibility breaks - in practice. I get that it's following all the newest standards or whatever it's doing, but in reality it always needs custom setup to work right. And for me the net effect is that it's always creating problems, not solving them.
I can use Ghostty and use the same featureful terminal on Linux and macOS.
I also hate configuring Konsole, most KDE apps for that matter. Being able to have a plaintext configuration file I can keep in my dotfiles is way simpler.
Konsole is a fantastic and very mature terminal emulator, but it does have some real gaps that reveal its age.
The Qt toolkit that most KDE software is based on at some point introduced a next-gen toolkit-within-a-toolkit called Qt Quick, which most of our newer apps are written in. However, in its library form Konsole can only be embedded into apps that use the old gen toolkit. This is a real impediment to some efforts.
The old gen toolkit also typically doesn't use Vulkan or OpenGL for rendering, and so Konsole's terminal renderer doesn't either. Konsole's real-world performance during use is arguably just fine, but it does leave a lot of performance and battery life on the table.
libghostty also has somewhat wider support for newer stuff like Kitty protocols, even though Konsole certainly trumps it in support for older stuff (like sixels).
There's some other shortcomings to Konsole that are not inherent to the technology, like accessibility support not quite being where it should be.
And while the default UI is reasonably clean and nice, there sure is a lot of spiderwebs and spacebar heating lurking in the settings dialogs (of which there are strangely many).
Which is to say, these projects can and do have a point, especially if they provide a nice library instead of hoarding all the good to themselves.
>I still don't understand the point of Ghostty, Kitty, Wezterm...
WezTerm can run on my Mac but give me a native GUI experience of a Wezterm session on my Linux workstation. It's like tmux, but with a native GUI experience including mouse click-drag selection that doesn't pick up "window" borders.
That alone is what is keeping me on Wezterm, since I get a native experience on some terminal sessions I access remotely on my macbook but then can switch to on my 30" screen when I'm at my desk.
I tried a bunch of terminals and ended up switching back to xfce-terminal, fastest I have tried by far. (It's just the default that ships with my distro.)
Actually I think xterm was even more performant, but the eye sore wasn't worth it for me.
To add to the other good points made in sibling comments, MacOS has butchered fullscreen to the point where some of us depend on MacOS terminal emulators having the "non-native fullscreen" config option. Personally, Ghostty does the best job supporting my preferred terminal environment of non-native fullscreen with tabs that works with an auto-hiding menubar and the camera notch.
> I still don't understand the point of Ghostty, Kitty, Wezterm...
If you're genuinely not trying to be dismissive and just have a sincere question you want to have an answer to then I _strongly_ implore you to be more aware of and careful about how you express yourself.
Because as your first sentence is worded virtually all readers will assume you are hostile and not asking in good faith.
I have the same wezterm configuration on linux, macos and windows. that's the point of wezterm for me.
I now use ghostty on Linux and macOS, cuz ghostty has more out of the box and is being up to date, and doesn't require me coding functionality xD small config file does all for me.
when Windows support comes in, I will have one terminal emulator on all 3 platforms I am using
Same. It is the only cross platform terminal emulator that truly provides an identical experience for me between Mac and Linux. Was really easy for me to get it to behave more or less just like iterm2 (cmd+1..9 for tabs) with Toshi on Linux. So my muscle memory works across macos and kde. Dotfiles: https://github.com/whalesalad/dotfiles/blob/master/wezterm/w...
I'm sure mitchellh will check out this comment section at some point - any updates on the move away from Github? I don't really see anything that's changed, but maybe it's behind the scenes. I was pretty excited on your initial post about it but it's been a while.
These are Ghostty GUI release notes, but I want to take a moment to highlight the libghostty progress we've made since Ghostty 1.3.
As a reminder, libghostty is the highly portable, embeddable library that provides core terminal emulation, render state, and more. I always felt that a free, high qualty, lightweight, reusable terminal emulation core would benefit the developer world more than any single GUI application. And that is playing out!
It is and always was my true purpose with the Ghostty project (I said this in my first ever talk about Ghostty!). I've jokingly said many times that Ghostty GUI is just a glorified tech demo for libghostty. That's not fair though, because GUI is great and there are really talented people working on it.
Since I started the project, Ghostty has always gotten people saying "I don't understand why you'd start a terminal emulator today." Well, the answer is libghostty. It's truly unique and its enabling something special (imo!).
Highlights of libghostty since 6 months ago (none of the below was true 6 months ago):
- Libghostty now builds and is tested (in CI) for: Apple (macOS, iOS, visionOS), Windows (MSVC and GNU), Linux, FreeBSD, Android, WebAssembly, and freestanding (i.e. direct on hardware with no OS).
- Libghostty has bindings in pretty much every popular programming language: C, Zig, Go, Swift, Python, Rust, .NET, etc.
- Libghostty's memory requirements have dramatically shrunk to enable the portability above. There's still work to do but a single empty terminal now takes 90% less memory. And at scale I've proven 10,000 active (input/output happening) terminals on a Linux server with 4 cores and 8 GB of RAM.
- Libghostty's speed is used by Antithesis to fuzz popular terminal programs and has directly led to hundreds of bug fixes sent upstream to programs such as tmux, btop, shells, and other terminal emulators. :)
Libghostty is really successfully turning into the tide that raises all boats. As it becomes more popular, Ghostty itself gets more performant and stable, and so does everyone else. It is also a vehicle for delivering modern terminal emulation to the widest source possible.
I plan on tagging libghostty 1.0 in the next few months and declaring ABI stability at that point!
I'm super excited for you and this, but this is mostly a highlight list of who is using your library. I was kind of excited to read about the actual changes to the library but I suppose I can go read the changelog on my own.
Because of your multiple "I am tired of saying this, but this text was written by me and not an LLM" in your blog posts, I want to tell you that I read it word for word. :D I know this comment adds not much but I felt it needed to be said.
One almost forgets how easy it is to read a wall of text when it was written by a human. This was nice to read (also because you can feel it's got care behind it).
At this point I just get frustrated reading AI prose. I tried for the past few months to just shut my mouth and force myself to read AI prose, since r/singularity wasted no breath telling people how they're Luddites for not marrying an AI.
I have been reading through pharma textbooks written before AI and realized it's so relieving to follow language that has been crafted over multiple editions by humans. When I started to realize how much easier it was for me to read textbooks than the average AI-assisted text, that's when I realized we are truly cooked (at least for this chapter of AI + writing).
Can you give an example of a pharma textbook that has gotten worse during the AI-slopp-ocalypse? Bonus Internet points for sharing any especially egregious passages!
They didn't claim they've read ai pharma textbooks, just used a pharma textbook (which I guess is heavy to read) as a comparison to being easier to read than ai written text.
Amen. I'll never, ever stop writing my own articles by hand.
I don't mind if my English isn't entirely idiomatic and all my sentence constuctions aren't "by the book" correct. I want to write, and I want anyone reading my writing to know that it's the product of thinking and editing that's unique to me.
As an aside, I once saw someone cite something somewhat profound and cited Rumi as the source, and I was like "hm that doesn't sound like him but maybe I'm just uncultured."
Turns out they were quoting Rumi from K Pop Demon Hunters and I indeed am uncultured.
Although not necessarily advertised as such, I've been successfully using alacritty in several projects injecting terminals into things both serious and silly.
I wouldn’t say it’s better, because that’s very subjective, but it is more “feature complete”. Alacritty is very minimal and rejects community PRs for features often driven by their general ethos. libghostty supports a lot of features I don’t foresee making their way into Alacritty.
I use Alacritty and GNOME Terminal. I don’t have a great reason for not using or trying Ghostty other than I have a minor aversion to Zig. (Again, not a great reason and arguably a not good reason)
Agreed on the value of libghostty. I switched from vterm to ghostel recently and it's solved some refresh issues I previously had with vterm when using CLI coding agents in emacs.
I'm from the KDE project, and have been working on a new frontend built on libghostty-vt to hopefully one day ease our maintenance burden.
It's been a quite smooth experience, and I remain very excited about the lib. I believe you are successfully setting the standard. Big congrats for your 1.4.0!
It'll be a new app, but it does provide a drop-in replacement for konsolepart (along with also having a QML module API for embeds into Qt Quick-based app, closing a gap Konsole currently leaves open). I'm sure it'll be some time before it would be ready to replace Konsole as default, also because conversations like that take some time and are a community process.
Oh Konsole while great (efficient and feature-rich) is showing its age and has a bit of a widget bloat and an unwieldy configuration system. For that reason I switched to Kitty a couple of years ago when I was transitioning to neovim I'm have not looked back since.
This looks like a great opportunity for the KDE project to rethink its terminal application for the modern age. Text-based config would be amazing though not sure how it'll fit into KDE Frameworks etc.
If I don't want to use the wave of "venture backed ghostty wrappers" for remote mobile coding similar to Claude Code remote, what options do I have? Any plans for a first party remote solution that's not SSH?
If you like Paseo (I love it), keep an eye on Happier. I think they made the right choice by starting from a multi domain architecture rather than Paseo's independent domains shown on the same client approach.
I prototyped this last week. Unfortunately the apprt abstraction I used isn’t something ghostty will externally support. So a proper console port needs to be rebuilt on libghostty.
I tried to use kmscon before, and it does work nice and is much faster. But, I can only have one app that is using DRM, i.e., I cannot start console/DRM image viewer from such terminal, or mpv, etc. That is a deal breaker and issue for me.
Thank you for your work on this. When I was working on neovim core and started dealing more and more with the edge cases of libvterm and terminal emulation in general, I had the same thought "we should just have a gold standard library for this." But that was 6/7 years ago (2019) and a lot of stuff happened in that interim unrelated to engineering that demotivated me from pursuing it.
Thanks for the good work to raise all boats :)
I tend to move away from terminal emulation towards GUI when I can (and using custom remote protocols somewhat inspired by arcan), but TUI is still useful for a while. I actually had a need for a good terminal emulation library for the fallback TUI/pty attachment for non-gui programs for my supervisor, so I'll try out libghostty.
Zig is also a C compiler
Here’s an example of Zig building some C code:
hello.c
#include <stdio.h>
int main(int argc, char **argv) {
printf("Hello world\n");
return 0;
}
$ zig build-exe hello.c -lc
$ ./hello
> Hello world
I misread the comment I was replying to, thinking it was about using Zig to port something, when it was actually about porting something that uses Zig.
You’re kidding right? That’s not what the support matrix on the Zig site shows. Plenty of CPU archs in Tier 3/4. No support for Alpha, HPPA, M68K, Sparc, or SuperH.
"portable" and "has ports" mean two different things. there might be targets Zig doesn't have great support for yet but what I meant is that bootstrapping a target to Zig is a simpler endeavor than it is for C
LLVM codegen is optional, and LLVM is being turned into a runtime dependency.
Zig has its own compiler backend. With limited arch support of course. Only used in debug modes for now.
I think the most interesting part is they rely on WASM for bootstrapping so all you need to make to bootstrap Zig anywhere is a WASM interpreter (if I understand correctly).
Yeah, the definition of "portable" being used is one that is not useful for most users, the fact that it's not in Fedora and neither Debian is a sign of it. Especially considering the demand for ghostty, it's a very cool project.
Someone willing to distribute ghostty has to pull in a whole programing language stack just for it, ghostty seems to be the most important project written in zig so far.
For the definition of portable that matters to me, this is the least portable possible, if it was written in almost any other language it would have been more portable. And yes, this all goes away once zig is onboarded to all distros, then it becomes "empirically portable", but we're not there yet.
PS.: "Portable" meaning which CPU architectures are supported is not a very useful meaning of the word for me, even though it's more accurate, it says nothing about the ability to actually build and run it in different OSes.
> has to pull in a whole programing language stack just for it
That’s implying a lot more than I think is the case for Zig.
Zig itself is a very lean and independent executable. It’s just one binary. Statically linked on Linux I believe. It’s even moving toward removing LLVM dependence.
I don’t know of any other language that aims to be as portable as Zig, including C itself. Of course, not all of those goals have been realised yet, but at this stage I don’t think there’s much preventing portability from Zig’s part itself, other than more architectures supported in its own compiler backend. And I suppose a 1.0 release would make it easier to get the compiler more widely distributed.
Just wanted to say thank you for all your contributions to our industry, Mitchell. I love Ghostty and your vision here, and evangelize it whenever I can.
Any plans for Ghostty to have the history of the terminal window reloaded on restart? Like the Mac native terminal app does? I am a heavy terminal user with a lot of tabs open, and after I restart the computer for whatever reason, I would like to have my terminal(s) as I left them.
The feature you're asking for is a terminal multiplexer. You want one built in, but to suggest terminal multiplexers are a workaround to requiring a terminal multiplexer is a stretch.
It is not a terminal multiplexer feature, it is one of the terminal software itself.
I do not know if you read my initial commment, but MacOS Terminal (native app) has this feature. And it is not a terminal multiplexer like tmux or what you proposed.
Why static output history for a session/tab with reload on restart should be a multiplexer feature?
I mean, the Ghostty GUI has already multiple tabs and split terminals, aren't those multiplexer features as well? I don't follow you.
terminal emulation seems to keep playing a central role not withstanding it being an ugly prehistoric crocodile. Do you ever envision creating something modern, without the warts and with a design that incorporates half a century of lessons-learned? Something that fills this need but in a more elegant package? I'm asking because you're one of the few people that seems well-positioned to make a replacement
I personally avoid using the terminal as much as possible b/c the whole things feels very archaic/fragile/baroque - but the central idea seems great and I'd love a modern take on it
the number of gotchas involved in bash scripting indicates to me it's very hard to make robust solutions using the terminal. Trying to understand how things like colors work in the terminal makes the whole thing look very duct-taped together
problem is not the terminal, it is the Unix philosophy for CLI programs. Non-structured text piping and bash scripting being major pain points for me personally.
There is no reason why programs input/output can't be schema'ed, consumed and piped in a type-safe manner. And why there can't be a better standard than bash for simple scripts.
But it is really hard to pull this kind of thing off unless you redesign most of the common tools by scratch and do so through a committee and somehow push it down people's throat through strict platform control.
You can rewrite all of the cli utils to fit your preferences. There’s no hard standard for piping (some utility pipe binary) and bash is not a requirement either (a shell is just a program).
No need to push it to people. Do it for yourself and create your community around it.
Also no need to do it from scratch. It’s just the interface part that needs to be rewriten.
> Do you ever envision creating something modern, without the warts and with a design that incorporates half a century of lessons-learned?
Turns out that the warts are the incorporation of the lessons learned. For this reason, just before Wayland fulfills its destiny and becomes an immaculate replacement for X11, a new generation of developers will determine Wayland's codebase is too complex to comprehend and must be rewritten from scratch.
Right, this was my assumption. I think my question got misinterpreted in terms of tone (viz the downvotes). But I was nurturing a hope that Mitchell might come back and say yes then share some wisdom. :)
libghostty is brilliant and I'm very glad it exists. ghostel in Emacs is completely brilliant and so fast compared to anything else, a wonderful project fascinated by libghostty. another i might mention is zmx [ https://zmx.sh/ ] - process persister (detach, attach) with panes, tabs, hijacking the terminal. i always end up using tmux just for persistence and then am frustrated I can't remember how to copy etc. zmx has more features than some things of a similar nature and my understanding is that it's able to be taking advantage of libghostty things.
(a couple of us working on packaging libghostty and ghostty proper to for Guix at the moment )
But can you actually paste into the terminal search popup now? :D Its the dealbreaker that keeps me on iTerm2 on my home machine, and the irritation that has me considering just launching iTerm2 and going back to it on my work machine. I still see the "Update Available: 1.4.0" message but knowing it was fixed would encourage me to close all my sessions and update.
I'm still using Wezterm here due to its Windows support, and I like being able to share one configuration my company Windows and my personal Linux laptops.
I've come to like its hyperlink rules to automatically generated clickable links to Reviews/Issues/Requirements/Linter Errors/... so I haven't felt the need to switch yet to have this feature missing.
I loved Ghostty for thr first month I tried it, but got some strange behavior when SSHing into some machines. Sounds like this release may address that. Maybe I can finally ditch iTerm2, lol
It’s rude to install a terminfo on a remote machine (which you may not be the owner of). It’s a preposterous for a terminal emulator to install things on a remote machine just to make it work.
It's actually the remote machine that isn't working, but I get the frustration. What I did to fix this is to override the environment variables in your SSH config like this:
If you want to use in a terminal emulator features that do not exist in any xterm variant and the remote computer does know only xterm, there is no way to do that without installing data into the terminfo database.
Otherwise, there is no need to install anything, you should just set the environment variable TERM in the remote computer to one of the xterm variants and then modern terminal emulators like kitty or ghostty will still work fine, but of course only as long as you use the xterm-compatible subset of their features.
It's not a VAX that you're physically plugging a terminal into. The remote machine is totally capable of communicating with a newer terminal, it just needs to know how. You're being nice by giving it that information. You can also just install it locally in your home directory (~/.terminfo). (You used to be able to stuff the entire entry into the TERMCAP environment variable and not install anything.)
I presume though that the mentioned fix only installs the terming for the user, rather than system-wide. I don’t see how that’d be rude (assuming it’s some non-root user that you should reasonably be considered to have control over).
Yea unfortunately eg Ubuntu’s bashrc has a script which will make it drop colors regardless of the presence of ghostty’s terminfo. Its `screen` will also fail, so e.g. it will refuse to upgrade to a new distro release.
Every terminfo is custom, to the terminal it applies to. It's just that most entries are 20+ years old and even glacial distros have converged on some version of the database that mostly worked, until the recent resurgence of interest in actually writing new terminal software.
I have quite enjoyed using the kitty image protocol in interesting ways.
I made a Claude code skill telling it to put a little image in the corner of the console when it does a render to see how something looks. It was quite fun telling it to draw a chicken with 5 SVG D paths and watching it iterate in the terminal.
We have a bunch of interactive Kitty Graphics demos, which run embedded in browser or from terminal. This weekend I was working on watercraft simulation:
Kitty is so awesome. I'm writing (well, as much as anyone writes) a MUD that models a decent part of Tokyo at 30-60fps over SSH at reasonable resolution (that's the dream, at least). I'm shocked at how fast I can render a big complex 3d environment, in the terminal.
Hmm I wss checking for updates last night actually. I really hope they dont start adding llm junk to ghostty. I really like it, but mitchel sounded like he got bit by the llm bug a few months back.
Its honestly perfect as it is, just nerd performance tweaks imo.
Truly odd to see this comment. For me, mitchellh defines the moderate position on agents in coding, I mean that seriously: not occupies it, defines it. I’ve raised this point in discussions and others get what I mean without explanation. He’s better known for a mitigation to LLM downsides (vouch) than for making conspicuous use of them, and insists on human-only prose in issues, PRs and ‘real’ documentation (which I firmly agree with btw).
He also has a blog post and some tweets about how they can find and fix difficult bugs, and otherwise are capable of solving hard problems now. Well, they can.
I've been a laggard in switching to Ghostty because I used WezTerm and wrote a plugin to customize it to my liking. I switched to Ghostty just because I got tired of nothing happening in the WezTerm land and wanted to try something different.
Same boat here. This makes me think I’ll switch to ghostty soon
How’re you feeling after the change?
Got the Rex beta but haven’t looked at it really. I made a custom Claude code harness that is orchestrated by go CLI Claude wrote for me and that uses herdr for session management. Probably there’ll be something interesting I can do with Rex in the future as an alternative
That says a lot because I really liked WezTerm (I was sponsoring Wez on github because of it) and I still do. But, the development stopped to a crawl, Wez has other priorities (obviously) and it was time for me to find an alternative.
Ghostty is fine, but I want a scripting language for my terminal - I don't need much, but those few little things mean a lot to me. Based on the Rex docs, I will be able to make it work for me the way I used WezTerm before the switch.
> Escape codes are the new html for browsers now called terminal emulators.
Not really and that isn't a good thing in the long run.
There should not be any more complexity in a terminal emulator that will just lead attackers to craft RCEs exploits to your terminal to steal your secrets on your computer just because "Its cool" and has hundreds of escape codes.
Ghostty is so great. I am very thankful to Mitchell for dedicating so much of his time to making a terminal that is truly great. Finally, somebody really cares and has the technical abilities to materialize that care as great software.
Also, ghostel in Emacs is fantastic as well (of course in a big part thanks to libghostty) — most of my work has now shifted into Emacs as a result.
This depends on the individuals' character -- when I look around, I mostly see people who become jerks/a-holes once they get money. Especially in the tech world. Look at what Google founders do with their money (evading taxes, mostly), or at others who became outright nazis and support far-right movements across the world. In the best case scenario they just keep buying yachts and villas and stay relatively quiet.
Mitchell is a beautiful exception and it makes me happy.
I think a lot of it has to do with how people get money. Not everyone, but a lot of people get a lot of money through very exchange-oriented ways and continue to be exchange-oriented afterwards.
I've always wondered what would happen if more people got a lot of money through more communal-oriented ways.
And this disregard for non-tmux usability is why I stopped using Ghostty. First it took up until 1.3 to get search, then fixing this significant quality-of-life problem is clearly not a priority.
Glad for an update. It’s unfortunately still missing table-stakes features for people who use primarily keyboard driven workflows. I guess I’ll stick with wezterm for another year.
Faster, shader support, better support for new terminal standards. I happened to get an invite to Rex yesterday so I am also trying that. It seems quite nice but is also missing quick select.
If wezterm adopted libghostty I would have little reason to switch.
I've tried Ghostty and it's great, but Kitty's hints mode[1] is the one feature keeping me from switching from Kitty to Ghostty. There are quite a few discussions around this and similar features in the Ghosstty-org/ghostty Discussions[2] which I follow. Most of them are references from ghostty-org/ghostty/discussions/2394[3]. Maybe now that Ghostty has finished implementing Kitty graphics hints will be next .
Yeah this is what is keeping me from using ghostty. Unfortunately I think that discussion is dead and no one agrees on the design of the three or so separate parts. I maintain a fork with quick select for my own purposes but I can’t use it at work.
link = copy_to_clipboard=[0-9a-f]{7,40}
link = open=https?://[a-zA-Z0-9.]+[-a-zA-Z0-9()@:%_\\+.~#?&//=]*
keybind = ctrl+o>y=quick_select
Far from perfect. No way to bind to specific action:regex pair, so `ctrl+o` then `y` will show hints for both urls, which it'll try to open, and git hashes, which it'll copy to the clipboard.
Out of curiosity if Kitty works well for you what would be the reason to switch to Ghostty? I've never tried Kitty before but now want to see what it's like since it seems quite advanced.
I'm not the GP, but I did use Kitty, then switched to Ghostty. There were some great features (e.g. a shorcut to load the current terminal content in a text editor), some arguable points (e.g. Python is Kitty's script language and I had to use it to configure tabs to my taste) and some annoyances (I've had various crashes with Kitty's Debian package, though it did get stable in later years).
For me, the major pain was font rendering. I could not find a portable configuration that would work with any screen. And even worse, for some pixel densities, whatever configuration I tried, the result was awful. In some cases, I vaguely remember there was a legacy mode that made text legible, but it had its own problems.
I was literally just griping about how I couldn't do this. I had no idea it was possible with kitty. Now to decide whether to switch back for it...
As an aside, I love ghostty and I think it's the most responsive terminal emulator around. But kitty was what got me off Terminal.app and I think it's not given enough love around here.
My experience with terminals was like this - Alacritty -> Ghostty -> tty7. The last one implements exactly what I had in mind when I used Alacritty and Ghostty. Only it doesn't hype much (the author apparently doesn't strive for that much), maybe that's for the better.
A LLM may be fine to implement quickly an application that more or less works, but I have not seen any evidence that any of them is able to write well optimized code, whenever the application is not just a duplicate of something older.
Ghosstty and a few other newer terminal emulators are not only lightweight, but they also implement very fast GPU rendering, which is one of their important advantages.
So not only their set of features matters, but also the achieved performance.
I've reimplemented ghostty in Rust and it performed on par with ghostty.
I've also given various models access to the tools necessary to measure performance and instructions to make things faster and they do pretty well. Hill climbing on a validatable measure is reasonably easy these days.
My direct experience here directly contradicts pretty much everything you've said can't be done. I.e. the human out of the loop stuff.
The update experience in Ghostty is great. I think it takes under 5 seconds from the moment you click accept update and until the new updated terminal is running.
372 comments
[ 3.4 ms ] story [ 35.2 ms ] threadKonsole is way faster than any of those on my computer and it has all the usual suspects I'd expect from a modern terminal emulator.
The one feature I miss since moving to Linux and not having iTerm2 is tmux -CC integration. None of those offer it.
To be clear, I'm not attempting to be dismissive. I really want to understand what it is that they bring.
It wasn’t the only reason I switched, but I prefer config to be config and code to be code rather than my WezTerm config to be executable.
I like Ghostty because I find it both fast and configurable, and it's multi-platform without treating macOS like the red headed step child. I also appreciate how its configuration is text-based, which I prefer to someone's opinion of how a configuration GUI should behave, and I think it's good the developers aren't wasting a second of their time thinking about a configuration GUI.
Also the konsole context menu and default toolbar are a mess.
To me the point of Konsole is that it works well, plus it's already there. Ghostty I need to make an effort to have it, however small it is, and I'm just trying to understand what I'd be missing if I didn't.
Surely you understand Konsole is not already there for most people?
> libghostty: a cross-platform, minimal dependency library that exposes a C API so feature-rich, correct, and fast terminal functionality can be embedded by any application anywhere.
1. By default, Konsole disables OSC8 link support. Users can enable it manually, but you need to ship fallbacks by default since otherwise the default users will have a broken experience. Ghostty, Kitty, WezTerm, etc all ship working OSC8 support out of the box.
2. No built-in Nerd Font support, so if you want to render icons, you need to tell your users to set up a patched font or else have fallbacks. Ghostty and WezTerm ship built-in Nerd Font fallbacks.
That being said Konsole is much better than most emulators. iTerm2 is not bad, although it lacks Symbols for Legacy Computing Unicode support (which all of the above have, including Konsole). The worst by far is Apple Terminal, truly the IE6 of terminal emulators.
That is, in my opinion, the correct default.
This should be enough to avoid malicious links. I do not believe that completely disabling links is a good default, because they are very frequently useful when you read some text file in the terminal window.
https://github.com/ghostty-org/ghostty/security/advisories/G...
If you don't want to be able to have clickable hyperlinks, by all means use Konsole — no one is forcing you to use Ghostty. But if you want to know why people like Ghostty's approach vs Konsole's, it's because Ghostty pushes terminal emulator features forward and is low latency. Konsole is low latency and adopts some but not all features that other people invent. It's a noticeable difference and so people who like the feature part of the former like Ghostty/WezTerm/Kitty more than Konsole. If you don't care or dislike that part, and want a more conservative terminal (that is also low latency), Konsole and many others further on the conservative spectrum exist.
I haven't used Konsole, but I do like this "recent" focus on terminals and have used many of the new ones. Dailydrived st,alacritty,wezterm,ghostty,kitty,foot (probably forgot some) and I live for the regex pattern matching copy shortcuts etc.
I learned about OSC8 because my terminal (whichever it was) used one of its features and I didn't know it was possible to do that. My immediate thought was, how is the security?
And it is very disappointing to see how little effort people have spent on that. That is really one part that I expect more for modern incarnations of the old terminals where I can sort of forgive them for the lack of security posture.
I like ghostty, I really do. But this is not a good look, and to be clear it isn't just ghostty. Without looking for it I've stumbled upon several OSC8 bugs (in other software) recently.
If people want it enabled, they can enable it. It shouldn’t be the default.
Someone? Almost certainly
I wouldn’t mind OSC8 so much if it had proper security auditing but it doesn’t. The whole thing was pushed by one guy on a GitHub gist who blocked anyone who dared discuss security issues.
At least with browsers, you have masses of people testing these things. But there’s no rigour to any of the tests that happen with terminal emulation. Let alone independent security audits.
And at this rate, it’ll only be a matter of time until we see “don’t cat untrusted READMEs” advice because they might contain boobytrapped escape codes. Which is an absurdly bad place to end up.
So far I can only think of 1: term vulnerabilities due to ANSI escape sequence parser bugs. And that’s exactly the reason I’m suggesting OSC8 should be off by default.
1. The Kitty keyboard protocol, which makes it impossible to distinguish e.g. Shift-Enter from Enter
2. OSC8 hyperlinks
3. It breaks on APC queries, so you need special handling to not emit them
4. Symbols for Legacy Computing Unicode support
5. The Kitty Terminal Graphics Protocol (or sixel)
6. OSC 9 notifications (or any of the later versions)
and a bunch of other stuff, this is just off the top of my head. For a long time they didn't even support 24-bit color, although they fixed that in Tahoe.
It's totally fine for basic UNIX tooling, but pretty painful if you're trying to make nice interactive TUIs.
The latter seems always to be about aesthetics, not about UX.
This sounds like a deliberate choice from Apple TBH because they, well, like their UIs and don't want to promote TUIs necessarily :)
2) Technical curiosity: some people probably started their own terminal project just for the fuck of having made their own - and they eventually gained a userbase.
3) Feature set: Most terminals implement most features these days, but at the time these projects started, you'd have a feature matrix between features and terminals because most terminals lacked some features; so people would pick whatever suited their needs.
Personally I've been using kitty for years mostly due to 3), at the time I chose my forever terminal, I evaluated like 12 different ones, and kitty was the only one that covered most of my needs without feeling like it suffers from random quirks, and I like that it has built-in terminal multiplexer (a'la tmux) and emoji picker.
Same boat here, though I also get to enjoy some of the benefits of libghostty, via ghostel in Emacs. Ghostel is noticeably faster when there's a lot of output being dumped, but I don't often need the speed and use it only because it's integrated rather well into the rest of my Emacs.
> tmux -CC integration
If you can stomach Emacs, there are at least two packages that implement this, one via eat and another via vterm, though none via ghostel just yet. Shouldn't be difficult to port, though.
I have used Konsole for many years and I have used kitty for about 2 years in 2024/2025, then I have switched to ghostty around the beginning of 2026.
At least in my computers (with NVIDIA GPUs and Gentoo Linux), kitty was many times faster than Konsole and Ghostty even faster.
Moreover, in the now somewhat distant past when I was still using Konsole, it did not have some font rendering features that I desired, but that might have been solved meanwhile.
A reason why the terminal emulator speed is important for me is that I frequently compile big software projects and I find it unacceptable for a compilation to be slowed down by the low speed at which the compiler output is displayed on the terminal window, which happened frequently with terminal emulators older than kitty and ghostty.
I’m strongly skeptical of this as pty are character devices and buffered. Programs and terminal are very loosely connected.
There are a few big projects that redirect the compiler output and attempt to print only one line per output file, so when all goes well there is much less output text, but with those it is usually more difficult to debug failures.
Why? If you use something like tee(1), you can get the full log in a file and then filter line according to what you want.
> Compiling any big software project produces far more text output than can be stored in any pty buffers.
The reason of my skepticism is that, according to your statement, reading a source file, then writing the compiled object file is way faster than a few printf through a kernel object in memory. Even for the terminal consuming the characters, parsing, and displaying the lines should not be a computation hog for most terminals
Xterm failed me :( Tabby just works.
I've just reverted back to using that as it's faster to load and has all the features I need.
The acceleration is the primary point.
In Mac, we had the default terminal app which has some problems with TUI apps and other small issues. iTerm2 is the replacement that most users use, but it become too bloated with useless features and AI, while it was hard to keep a good config file that I could share between devices. Ghostty was a sane mid-term for me: a good and modern terminal, with a simple config file, maintained by someone that I trust (Mitchell Hashimoto) and only that.
About Linux: I don't use Ghostty in Linux because I'm comfortable with Konsole.
I also hate configuring Konsole, most KDE apps for that matter. Being able to have a plaintext configuration file I can keep in my dotfiles is way simpler.
Konsole is a fantastic and very mature terminal emulator, but it does have some real gaps that reveal its age.
The Qt toolkit that most KDE software is based on at some point introduced a next-gen toolkit-within-a-toolkit called Qt Quick, which most of our newer apps are written in. However, in its library form Konsole can only be embedded into apps that use the old gen toolkit. This is a real impediment to some efforts.
The old gen toolkit also typically doesn't use Vulkan or OpenGL for rendering, and so Konsole's terminal renderer doesn't either. Konsole's real-world performance during use is arguably just fine, but it does leave a lot of performance and battery life on the table.
libghostty also has somewhat wider support for newer stuff like Kitty protocols, even though Konsole certainly trumps it in support for older stuff (like sixels).
There's some other shortcomings to Konsole that are not inherent to the technology, like accessibility support not quite being where it should be.
And while the default UI is reasonably clean and nice, there sure is a lot of spiderwebs and spacebar heating lurking in the settings dialogs (of which there are strangely many).
Which is to say, these projects can and do have a point, especially if they provide a nice library instead of hoarding all the good to themselves.
WezTerm can run on my Mac but give me a native GUI experience of a Wezterm session on my Linux workstation. It's like tmux, but with a native GUI experience including mouse click-drag selection that doesn't pick up "window" borders.
That alone is what is keeping me on Wezterm, since I get a native experience on some terminal sessions I access remotely on my macbook but then can switch to on my 30" screen when I'm at my desk.
Actually I think xterm was even more performant, but the eye sore wasn't worth it for me.
If you're genuinely not trying to be dismissive and just have a sincere question you want to have an answer to then I _strongly_ implore you to be more aware of and careful about how you express yourself.
Because as your first sentence is worded virtually all readers will assume you are hostile and not asking in good faith.
As a reminder, libghostty is the highly portable, embeddable library that provides core terminal emulation, render state, and more. I always felt that a free, high qualty, lightweight, reusable terminal emulation core would benefit the developer world more than any single GUI application. And that is playing out!
It is and always was my true purpose with the Ghostty project (I said this in my first ever talk about Ghostty!). I've jokingly said many times that Ghostty GUI is just a glorified tech demo for libghostty. That's not fair though, because GUI is great and there are really talented people working on it.
Since I started the project, Ghostty has always gotten people saying "I don't understand why you'd start a terminal emulator today." Well, the answer is libghostty. It's truly unique and its enabling something special (imo!).
Highlights of libghostty since 6 months ago (none of the below was true 6 months ago):
- Libghostty now builds and is tested (in CI) for: Apple (macOS, iOS, visionOS), Windows (MSVC and GNU), Linux, FreeBSD, Android, WebAssembly, and freestanding (i.e. direct on hardware with no OS).
- Libghostty has bindings in pretty much every popular programming language: C, Zig, Go, Swift, Python, Rust, .NET, etc.
- Libghostty's memory requirements have dramatically shrunk to enable the portability above. There's still work to do but a single empty terminal now takes 90% less memory. And at scale I've proven 10,000 active (input/output happening) terminals on a Linux server with 4 cores and 8 GB of RAM.
- Libghostty powers all JetBrains IDE terminals, over 12.5 million active users. https://blog.jetbrains.com/platform/2026/10/jetbrains-termin...
- Libghostty is the most popular core behind the wave of venture-backed "agentic" terminals and editors, such as Herdr, cmux, and many others.
- Libghostty is being discussed and has been verbally accepted to replace the terminal core in Neovim: https://github.com/neovim/neovim/pull/39773 (work still to be done)
- Libghostty powers a really popular and powerful terminal emulator for emacs (Ghostel): https://github.com/dakra/ghostel
- Libghostty's speed is used by Antithesis to fuzz popular terminal programs and has directly led to hundreds of bug fixes sent upstream to programs such as tmux, btop, shells, and other terminal emulators. :)
- And so much more: https://github.com/Uzaaft/awesome-libghostty
Libghostty is really successfully turning into the tide that raises all boats. As it becomes more popular, Ghostty itself gets more performant and stable, and so does everyone else. It is also a vehicle for delivering modern terminal emulation to the widest source possible.
I plan on tagging libghostty 1.0 in the next few months and declaring ABI stability at that point!
That's really cool, but I'm drawing a blank; what's it used for? Embedded terminal something?
it is all open source: https://github.com/hotaisle/hotaisle-website
Wanted to add too that I can't wait for xterm to eventually support libghostty, you've been super supportive providing feedback!
https://github.com/xtermjs/xterm.js/issues/5686
But I can't do this any longer. I'm tired, boss.
Erm, this really depends on the human I think.
I don't mind if my English isn't entirely idiomatic and all my sentence constuctions aren't "by the book" correct. I want to write, and I want anyone reading my writing to know that it's the product of thinking and editing that's unique to me.
here's another:
"when i am sad, i have to remind myself that sadness i feel so as to qualify me to enjoy and feel joy."
this is not mine, it's a paraphrase of a poem verse from Mawlawi (aka Rumi in the West).
Turns out they were quoting Rumi from K Pop Demon Hunters and I indeed am uncultured.
The one I am mentioning is جلال الدین محمد بلخی رومی So the sufi saint.
Although not necessarily advertised as such, I've been successfully using alacritty in several projects injecting terminals into things both serious and silly.
I use Alacritty and GNOME Terminal. I don’t have a great reason for not using or trying Ghostty other than I have a minor aversion to Zig. (Again, not a great reason and arguably a not good reason)
It's been a quite smooth experience, and I remain very excited about the lib. I believe you are successfully setting the standard. Big congrats for your 1.4.0!
This looks like a great opportunity for the KDE project to rethink its terminal application for the modern age. Text-based config would be amazing though not sure how it'll fit into KDE Frameworks etc.
But if you run nix you could give it a whirl: https://github.com/KritR/ghostty-kms
Thanks for the good work to raise all boats :)
I tend to move away from terminal emulation towards GUI when I can (and using custom remote protocols somewhat inspired by arcan), but TUI is still useful for a while. I actually had a need for a good terminal emulation library for the fallback TUI/pty attachment for non-gui programs for my supervisor, so I'll try out libghostty.
Zig has its own compiler backend. With limited arch support of course. Only used in debug modes for now.
I think the most interesting part is they rely on WASM for bootstrapping so all you need to make to bootstrap Zig anywhere is a WASM interpreter (if I understand correctly).
* With some UB herbs and spices
Someone willing to distribute ghostty has to pull in a whole programing language stack just for it, ghostty seems to be the most important project written in zig so far.
For the definition of portable that matters to me, this is the least portable possible, if it was written in almost any other language it would have been more portable. And yes, this all goes away once zig is onboarded to all distros, then it becomes "empirically portable", but we're not there yet.
PS.: "Portable" meaning which CPU architectures are supported is not a very useful meaning of the word for me, even though it's more accurate, it says nothing about the ability to actually build and run it in different OSes.
That’s implying a lot more than I think is the case for Zig.
Zig itself is a very lean and independent executable. It’s just one binary. Statically linked on Linux I believe. It’s even moving toward removing LLVM dependence.
I don’t know of any other language that aims to be as portable as Zig, including C itself. Of course, not all of those goals have been realised yet, but at this stage I don’t think there’s much preventing portability from Zig’s part itself, other than more architectures supported in its own compiler backend. And I suppose a 1.0 release would make it easier to get the compiler more widely distributed.
It's a pleasure reading your posts.
[1] https://github.com/neurosnap/zmx
I do not know if you read my initial commment, but MacOS Terminal (native app) has this feature. And it is not a terminal multiplexer like tmux or what you proposed.
I personally avoid using the terminal as much as possible b/c the whole things feels very archaic/fragile/baroque - but the central idea seems great and I'd love a modern take on it
There is no reason why programs input/output can't be schema'ed, consumed and piped in a type-safe manner. And why there can't be a better standard than bash for simple scripts.
But it is really hard to pull this kind of thing off unless you redesign most of the common tools by scratch and do so through a committee and somehow push it down people's throat through strict platform control.
No need to push it to people. Do it for yourself and create your community around it.
Also no need to do it from scratch. It’s just the interface part that needs to be rewriten.
Turns out that the warts are the incorporation of the lessons learned. For this reason, just before Wayland fulfills its destiny and becomes an immaculate replacement for X11, a new generation of developers will determine Wayland's codebase is too complex to comprehend and must be rewritten from scratch.
When you say you've proven, are you hinting at use of formal verification?
Any interest in moving console typography past the 80's, since computers are fast now?
https://monaspace.githubnext.com/
(a couple of us working on packaging libghostty and ghostty proper to for Guix at the moment )
https://ghostty.org/docs/config/keybind/reference#toggle_qui...
I've come to like its hyperlink rules to automatically generated clickable links to Reviews/Issues/Requirements/Linter Errors/... so I haven't felt the need to switch yet to have this feature missing.
I'm eying Kitty though.
Host * SetEnv TERM=xterm-256color
Otherwise, there is no need to install anything, you should just set the environment variable TERM in the remote computer to one of the xterm variants and then modern terminal emulators like kitty or ghostty will still work fine, but of course only as long as you use the xterm-compatible subset of their features.
Lots of jank due to this custom terminfo.
I made a Claude code skill telling it to put a little image in the corner of the console when it does a render to see how something looks. It was quite fun telling it to draw a chicken with 5 SVG D paths and watching it iterate in the terminal.
https://github.com/NimbleMarkets/ds4go-apps#svgpad
We have a bunch of interactive Kitty Graphics demos, which run embedded in browser or from terminal. This weekend I was working on watercraft simulation:
https://nimbleterminal.github.io/nt3d/water/
Its honestly perfect as it is, just nerd performance tweaks imo.
He also has a blog post and some tweets about how they can find and fix difficult bugs, and otherwise are capable of solving hard problems now. Well, they can.
Is that the LLM bug to you?
Because this company, and the superlogical idea intially emphasized building the terminal multiplexer for the agentic age.
I've been a laggard in switching to Ghostty because I used WezTerm and wrote a plugin to customize it to my liking. I switched to Ghostty just because I got tired of nothing happening in the WezTerm land and wanted to try something different.
Rex will allow me to use my old workflow again.
How’re you feeling after the change?
Got the Rex beta but haven’t looked at it really. I made a custom Claude code harness that is orchestrated by go CLI Claude wrote for me and that uses herdr for session management. Probably there’ll be something interesting I can do with Rex in the future as an alternative
That says a lot because I really liked WezTerm (I was sponsoring Wez on github because of it) and I still do. But, the development stopped to a crawl, Wez has other priorities (obviously) and it was time for me to find an alternative.
Ghostty is fine, but I want a scripting language for my terminal - I don't need much, but those few little things mean a lot to me. Based on the Rex docs, I will be able to make it work for me the way I used WezTerm before the switch.
Not really and that isn't a good thing in the long run.
There should not be any more complexity in a terminal emulator that will just lead attackers to craft RCEs exploits to your terminal to steal your secrets on your computer just because "Its cool" and has hundreds of escape codes.
Also, ghostel in Emacs is fantastic as well (of course in a big part thanks to libghostty) — most of my work has now shifted into Emacs as a result.
Mitchell is a beautiful exception and it makes me happy.
I've always wondered what would happen if more people got a lot of money through more communal-oriented ways.
Why is that? It reminds me of the XFree86 times when building from source was some unstable, fancy thing that was severely frowned upon.
Does it mean that it's only viable to use the zig programming language if you can have "their team" on speed dial?
..but you can!
Nothing controversial here.
Inspect + build yourself
* vim like keybindings to select text
* URL, path, hash (or whatever else you need) selection with shortcut
The same or similar can be done with ghostty + tmux, but I prefer to use less if I can.
My config here: https://github.com/daliusd/cfg/blob/master/.config/wezterm/w...
If wezterm adopted libghostty I would have little reason to switch.
i signed up for the mailing list, do you just wait a bit?
happy to hear your thoughts while i wiggle in excitement!
[1]: https://sw.kovidgoyal.net/kitty/kittens/hints/
[2]: https://github.com/ghostty-org/ghostty/discussions
[3]: https://github.com/ghostty-org/ghostty/discussions/2394
For me, the major pain was font rendering. I could not find a portable configuration that would work with any screen. And even worse, for some pixel densities, whatever configuration I tried, the result was awful. In some cases, I vaguely remember there was a legacy mode that made text legible, but it had its own problems.
As an aside, I love ghostty and I think it's the most responsive terminal emulator around. But kitty was what got me off Terminal.app and I think it's not given enough love around here.
Unfortunately, it seems to be doing something strange - I use vi-mode with nushell and it renders every character I press - even in normal mode.
I might keep an eye on it - hopefully they improve whatever they're doing with local echo.
I should say - I currently use WezTerm for exactly the feature tty7 advertises about session support. Even remote sessions.
A LLM may be fine to implement quickly an application that more or less works, but I have not seen any evidence that any of them is able to write well optimized code, whenever the application is not just a duplicate of something older.
Ghosstty and a few other newer terminal emulators are not only lightweight, but they also implement very fast GPU rendering, which is one of their important advantages.
So not only their set of features matters, but also the achieved performance.
I've also given various models access to the tools necessary to measure performance and instructions to make things faster and they do pretty well. Hill climbing on a validatable measure is reasonably easy these days.
My direct experience here directly contradicts pretty much everything you've said can't be done. I.e. the human out of the loop stuff.
However, it is more focused on multiplexing.