Terminal Trove Talks with Mitchell Hashimoto

Mitchell: “Thank you for your interest in sharing Ghostty with your readers. 😄

The origin story is rather boring at first: I have built CLI applications for most of my career, but realized my knowledge of how all the layers work together (terminal, pty, shell, etc.) was muddy. At the same time, I was interested in finding a project to play around with Zig and I was also interested in getting into some graphics programming after having spent a better part of a decade writing Go and infrastructure software. All of this culminated in me starting Ghostty. I assumed I would work on Ghostty for a few months, learn some things, then abandon it though. I didn’t expect to ever release it!

I can’t pinpoint an exact moment, but at some point while working on Ghostty and learning, I started to feel I could build a better terminal for what I wanted. The way I describe what I wanted is something that is fast, feature rich, and platform native. As I dove more into the depths of terminal emulators, I realized everything out there was making me choose at most two of those properties, and I wanted all three and saw no technical boundary to get there. This pushed me to continue working on Ghostty; I thought maybe others might also be interested in this type of terminal.

The name Ghostty isn’t anything particularly deep. I think it’s cute, has a good mascot, integrates the terminal history with “tty” in it, and it kind of alludes to the “ghost in the machine” nature of terminals.”

Mitchell: “Definitely! My primary goal with Ghostty was to enable fast, feature rich, and platform native together. Individually, I looked to what I considered best-in-class examples to provide the blueprint for what I would do within that category.

For fast, I looked to Alacritty and Kitty specifically. These are both very fast terminals. When I say “looked to,” I mean that they provided the benchmark results that I knew I wanted to at the very least get close to. Our implementations are different enough I didn’t look at the source code.

For feature-rich, I looked at a confluence of terminals, but focused on the most popular terminals such as iTerm2, Gnome Console, etc. to see what features a “mainstream” terminal needed to be successful. For terminal features, I looked at the innovators such as Kitty for things such as the modern keyboard protocol, image protocol, etc.

For platform-native, I looked at the system default terminals as well as other popular non-terminal applications on the systems in order to best understand what defines “idiomatic platform behavior” as best as possible. This was particularly important on Linux which has no official “native” definition, so it falls back to most popular idioms that a user is most likely to feel comfortable and familiar with.”

Mitchell: “I hope no one takes this the wrong way, because I love terminals, but I think my biggest takeaway from years of working on a terminal emulator is that terminal emulators are all built on a shaky historical foundation that we need to probably find a way to throw away.

I think continuing to build innovations on top of in-band signaling and carrying forward all existing legacy escape sequences hurts the possible capability, performance, and security of terminal emulators.

I don’t have any firm opinion of how to move beyond these legacy technologies, but the realization of their obsolescence is probably the most impactful perspective I’ve gained from working on a terminal emulator.”

Mitchell: “Thanks! Yes, I was a junior web developer when “Firebug” first emerged and I remember how overnight web development completely changed. It felt like thanks to Firebug, more developers could confidently take on building more challenging capabilities in web applications and as such the web become better.

Today, “Firebug” lives on through official “Dev Tools” within each of the major browsers. It is a more or less official part of the web.

I think in order to enable developers to build the next generation of highly capable, stable terminal programs, similar development tools need to emerge. The Ghostty terminal inspector in its current state is more of a tech demo than a very useful development tool, but I think it shows the foundations of what is possible and I hope to continue to improve that feature.”

Mitchell: “I think Zig has been fantastic for cross-platform work. The lazy analysis feature of the compiler lets you mix platform-specific code directly within your logic. For example, one function can call a macOS-only API and a Linux-only API and still compile for both since the compiler will only choose to semantically analyze codepaths that are reachable. That’s super useful compared to splitting platform logic by files, using ugly preprocessor macros, etc.

A challenge I found at higher levels is that a lot of what makes a platform “native” (particular on macOS) dictates a certain tech stack. It’s very hard to build a truly native application on macOS for example without using Swift. On Windows, it’s looking very hard to build a modern native application without C++ or C# (due to the modern GUI toolkits).

Given this constraint, I landed on an architecture where Zig complies into a C-ABI compatible library, and the platform-native GUIs are implemented in their native languages (e.g. Swift for macOS) and link to this library.

Building out the foundations for this architecture was challenging, but it has stood the test of time so far and I’m extremely proud of this work. Most importantly, it is enabling us to build “libghostty” (the C library) as a standalone artifact that I think will enable much more terminal impact than the Ghostty applications on their own.”

Mitchell: “I’ll mention two, both I think are underestimated.

The first is font rendering. From determining what font to use, figuring out how fonts impact grid size, rasterizing fonts crisply, handling colors properly, emoji, and more, font rendering is a beast of a challenge. I sometimes joke that Ghostty is 70% a font rendering engine and 30% a terminal emulator.

The second is keyboard input and encoding. Handling all the worlds possible keyboard layouts and then determining their proper encodings to the running shell application is a nightmare mix of complexity and legacy baggage.

In both of these areas, I think Ghostty does very well, but still has improvements to make. I think we do much better than average though. For example, Ghostty is the only terminal emulator that works out of the box with the most popular Japanese input methods on macOS (macSKK/aquaSKK).”

Mitchell: “Yes! I think libghostty is the actual goal of the project. I like to say that the macOS and Linux applications are just flagship tech demos for libghostty, but libghostty is the real project.

For the most part, most major terminal emulators out there reimplement all of the core terminal emulation logic: Terminal.app, iTerm2, Kitty, WezTerm, Alacritty, Foot, Gnome Console, Windows Terminal, tmux, etc. and of course Ghostty.

I view this mostly as a major waste of time. The core terminal emulation logic is in some ways the least interesting and least diverse. The way terminal emulators become truly different is their GUI functionality. For example, tmux isn’t interesting because it is a terminal emulator, it’s interesting because of its ability to save/restore sessions. Additionally, iTerm2 isn’t interesting because it’s a terminal emulator, it’s interesting because it has functionality like a password manager, tab colors, etc.

Beyond being a waste of time, it leads to major fragmentation: different terminals support different core terminal emulation functionality (image protocols, input protocols, desktop notifications, colors, underlines, etc.). Building on top of a common terminal library would provide consistency.

Libghostty is my attempt at making the core terminal emulator functionality a cross-platform, reusable component. It is a C library because that is — for better and worse — the most portable format for this kind of thing. This isn’t unique, the Linux/GTK ecosystem has “libvte” which has been very successful; libghostty aims to do that at a broader scale.

With that, I envision a healthy ecosystem of terminal emulators that emulate terminal functionality consistently while providing unique features targeted at what their users care about.”

Mitchell: “Read the source for terminal emulators! There are so many out there that cross-comparing how they do things is an excellent way to learn how things work. Eventually, all terminal emulators will lead you to libc or system APIs such as makepty, fork/exec, poll, kqueue, etc. and you can use your system man pages to learn more.”

Mitchell: “The immediate goals are to continue striving towards being the “best existing terminal emulator” (my stated goal for 1.0 and 1.x). When I say “best,” I don’t literally mean it as objectively the best. I mean “best” as an ideal to strive for with the practical goal of Ghostty being inarguably “good” for something like 9 out of 10 terminal users.

What that means is we need to implement functionality such as search, scrollbars, GUI-based configuration, and other improvements that were missing in the initial 1.0 release but that we know are important.

Once we get that done, then we can start looking into some of the more interesting work: shipping libghostty as a standalone thing, experimenting with new terminal protocols, experimenting with new GUI interactions, etc.”

Mitchell: “I’m ironically not too interesting here. I live in the terminal but I mostly use the “old guard” tooling. The two tools I use the most are Neovim and Jujutsu.”