I daily drove WezTerm for a bit, and now use Ghostty. I think they’re both very similar in that they’re terminal emulators that both aim to be fast while having a lot of features, and either is very good to use if you don’t care about the details too much. The main differences IME are:
WezTerm doesn’t aim to be “truly” native and integrate with the host OS as much. My favourite example of this is that Ghostty uses macOS’s native tabs, while WezTerm draws its own tab bar.
WezTerm is configured with lua, so you can go wild and have a truly dynamic configuration. Ghostty’s config file is just key/value and doesn’t have as many knobs to turn. The flipside is that Ghostty is planning on having a GUI configurator, something I don’t think WezTerm can easily do.
That was basically what I was coming here to post. I’m a current WezTerm user, and the main advantage I see of Ghostty over it is native (GTK, for me) tabs, splits, &c, rather than the cross-platform non-native tabs and TUI menus that WezTerm has.
I’ve used both a lot. Ghostty is my daily driver now. WezTerm would be my go to if not for Ghostty, then it would be a tossup between Terminal.app and Kitty.
WezTerm has a feel like emacs or nvim-as-blogged-about-on-internet – you are kind of expected to do a lot of coding as configuration to turn it into a tool carefully crafted around the nuances of what you want. If you do that, it is great.
Ghostty is more opinionated and gives you fewer knobs, but the knobs are well chosen. Analogizes to OS X whereas WezTerm is a crunchy Linux (Arch or such).
In my personal journey, well, I declared .emacs bankruptcy a few years ago and wiped my accumulated configs from over two decades and moved to using defaults everywhere as much as I can bring myself to, as I don’t have the cycles to spend hand customizing all my tools and keeping everything up to date and so on :-/ YMMV
In terms of font weight, Wezterm renders thinner text than iTerm or Terminal.app does, enough to keep bothering me. I tried to tweak the configuration, but nothing helped enough.
To be fair, I faced the same problem with Kitty and Alacritty too.
Interesting, I just tried Cascadia Code and it looks like the rendering is the same in iterm2 and wezrerm, maybe we have different font versions or something.
Sure, here is wezterm config: https://pastebin.com/KChBQ2yW
I tested on Sonoma on MacBook Pro M2, wezterm version is ‘wezterm 20240922-151228-2b76c63b’ and the latest version of Cascadia Code (2404.23).
I think there are some global Fontconfig settings you can apply that will get you exactly the rendering you want. Unfortunately, I’m not at any of my Linux machines right now to share it here.
It’s such a small issue but makes applications unusable for me, there’s just something wrong with Linux-style rendering. It’s especially noticeable with “anything and everything” near the top of my first screenshot, the “y” is clearly rendered incorrectly.
I see. I wasn’t aware of that. So if ghostty uses CoreText instead of harfbuzz on macOS, only then its font rendering will be comparable to that of iTerm.
I had the same annoyance with WezTerm and at least IME Ghostty looks functionally identical to iTerm. I did manage to get WezTerm to behave better by using the WebGpu frontend with a medium font weight, so you can try that if you haven’t already.
It’s really good! Ironically, I’d call Wezterm vs Ghostty to be emacs vs neovim despite wezterm being the one with Lua. Wezterm is far more flexible, one of if not the only terminal who’s config is a programming language. The sky is the limit with Wezterm, letting you even customize the UI.
Ghostty on the other hand is much more streamlined. It has less potential for ricing, but feels much lighter while still keeping the important stuff. Imagine alacritty, but with a 10% speed nerf, but with 90% of the features of wezterm, and all the ones anyone could ever want.
Recently got invited to the beta, making the switch from Wezterm. I mostly use CLIs and Helix / Vim though, so I don’t know if I’m as qualified to answer as, say, a power user would be.
This is exciting, and I’m looking forward to trying it in place of iTerm.
What are the security goals and architecture? Lots of features means lots of attack surface, exposed to remote servers and files accidentally cat’d to the terminal. For spatial memory safety, does it/can it use Zig’s release-safe mode? For temporal memory safety, what allocation strategy is used? Are the internals friendly to targeted fuzzing? Are there dangerous features exposing command execution or the filesystem? Is bracketed paste supported adversarially? /cc @mitchellh
To be clear, this is not a list of gotchas, but of potential wins over other emulators that would make me particularly excited about switching.
Great questions. Ghostty 1.0 will be just as vulnerable to terminal escape security issues as basically any other terminal (as described in recent blackhat talks and so on).
We have some rudimentary protections common to other terminals (but also notably missing from many) such as an “unsafe paste warning” where we detect multi line pastes or pastes that attempt to disable bracketed paste and so on. It’s not sufficient to call a terminal secure by any means but does exist.
On Linux we have the ability to put shell processes into cgroups and currently do for memory protections but stop there. When I implemented that feature I noted I’d love to see that expanded in the future.
I think the real answer though is that this is one of my top goals for future improvements to the terminal sequence level as I noted in the future section. I’m working on a design now but I want to enable shells to drop privileges while children are running much in the same way OpenBSD has a syscall to drop privileges. For example, a shell or program should be able to say “ignore all escape sequences” (maybe except some subset) so things like tailing or catting logs are always safe.
The security framework is probably my first major goal for innovation in the future. For Ghostty 1.0, I’ve more or less inherited all the same architectural problems given by the underlying specifications of old (defacto and dejure).
If you’d like to be a part of this please email me, I have a ton of respect for your work and consider you far more of a security expert than me!
I realized I didn’t answer some of your other questions in my other response. Let me follow up with that now:
For memory safety, we currently recommend ReleaseFast. The speed impact of the safety checks on the safe build are too great and noticeably make some things not smooth. We need to do a better job of strategically implementing safety check disabling on certain hot paths to make safe builds usable, but that is something I want to do.
Our debug builds (not release safe) have extra memory integrity checks that make builds VERY slow but also VERY safe. I’d like to setup build machines that run fuzz testing on these builds 24/7 using latest main. This is not currently in place (but the integrity checks are in place).
Re: fuzzing: the internals are very friendly to fuzzing. We’ve had community members do fuzzing (usually with afl) periodically and we’ve addressed all known fuzz crashes at those times. It has been a few months since then so I’m not confident to say we’re safe right now. :)
Longer term, I’m interested in making an entire interaction sequence with Ghostty configurable in text so we can use some form of DST and fuzzing to continuously hammer Ghostty. That’s a very important goal for me.
For memory safety, we currently recommend ReleaseFast. The speed impact of the safety checks on the safe build are too great and noticeably make some things not smooth.
I’m not super familiar with the intricacies of Zig, but does it have any way to toggle individual safety checks? IME there are things like bounds checks that are basically free and massively help with safety, and then you have things like null checks that aren’t as useful for safety but are still basically free, and then you have things like checked addition that are comparatively expensive but don’t really give as much on their own. That might be something to check out?
I’ve been using Ghostty for a couple of weeks now, and all I can say is that it’s as if the best parts of iTerm2 and Kitty were combined. It’s really fast, has great native integration with the OS (e.g. uses macOS tabs instead of Kitty doing its own thing) and is packed with features that I always end up missing from iTerm, like the newly added quake terminal. I think the only thing I miss from iTerm2 is support for tmux’s control mode (on the way) and config profiles, both of which I can live without. It is genuinely shocking to me how good and uncompromising it is, and I think many will find it worthwhile to switch. Kudos to Mitchell!
It’s funny how different feature sets are key; losing configuration profiles is a dealbreaker for me, so I’m both happy for you and glad you clarified that I should not try migrating.
This sounds awesome! I’m very glad it will be open source
The libghostty API to embed terminals in other applications sounds exciting too. I’ve long said that a shell UI should have a terminal, but not be a terminal. That is, it can be a GUI with a terminal.
You need the terminal to run pip or docker or Cargo, because they all use terminal escapes
But the shell itself can be divorced from the terminal. (The usual way it works is that the shell and the child processes it spawns both write to the same file descriptor, via descriptor inheritance. And that descriptor often represents a terminal, which is a kernel data structure.)
In particular, history and completion can be a GUI like they are in the browser (hopefully without all the dark pattern shenanigans)
We have a prototype of that working here, with screenshots:
This is possible because Oils has a “headless protocol” that works via passing terminal FDs over a Unix domain socket, which works perfectly on any Unix, including Linux and OS X, which ghostty targets.
OSH is the only POSIX- and bash-compatible shell that has a headless protocol. You can’t do it with bash or zsh.
And YSH is in the same binary, with a brand new legacy-free language (not quite stable, but getting there). Also, the whole oils-for-unix binary is about 2 MB of native code now. It builds with just a C++ compiler on any Unix (no make, autotools, CMake, and no Python).
The interactive shell is still a bit of a side project for Oils – we are concentrating on the YSH language now and “Hay Ain’t YAML” – but I wanted to put that out there for anyone interested in shell GUIs.
I don’t happen to know much about terminals personally, so contributors are very welcome! Samuel and Subhav has pushed on this in the past, mentioned in the blog post linked above. At the very least, I would like to get a proof of concept published with libghostty, so other people have something to push on
(Also, I’m not sure if anything like libghostty exists in C or C++ or Rust, but if it does, I’d be interested)
I’m surprised how much criticism I received for this approach and the number of entitled people who seemed to believe that they were owed something just because I liked sharing my work and progress. At the same time, I’m thankful for the much larger number of people who have been supportive and understanding of my approach.
There is a small minority of people who are bit loud about their (sometimes bizarre, flimsy) opinions.
But also a larger number of people who are taking the time to understand the project and code, and who contribute a lot in their valuable spare time (including testing and docs, not just code). I know that is hard, and I appreciate it a lot!
I’ve looked at it briefly, but not really used it … IIRC it does some kind of bash stdin/stdout scraping/parsing, as most such tools do, including Emacs plugins and so forth.
That could involve the prompt string, e.g. setting PS1= to something magic, and then looking for that string to try to distinguish
what the shell, like bash, wrote
what the child process, like docker, wrote
That is OK for basic cases of running synchronous commands, but there are edge cases, like asynchronous commands, or unusual terminal escapes
The general problem is as mentioned - the shell and child process traditionally write to the same file descriptor. So you don’t have a good way of distinguishing their output by reading the other end of the descriptor – you’re left with ad hoc parsing.
At least the Oils project is trying to remove the ad hoc parsing / “string gobbledygook” from both the shell language and from its interfaces to the rest of the system.
So instead we do something more principled, but compatible. The headless mode is implemented with a tiny “FANOS” protocol - “file descriptors and netstrings over sockets”
So the GUI would just pass a shell command, along with a file descriptor to specify where it wants the output to go. It could be either:
a command you typed like docker, in which case you pass a terminal for the headless shell to pass through to the docker process. The shell doesn’t write there, but docker does.
a command to query the state of the shell, in which case you might use a plain pipe. For example, you can send a command to query the prompt string like echo ${PS1@P}. This generally involves running user-defined code, and then you can display the prompt outside a terminal, in a GUI.
So basically the two channels (shell vs. child process like docker) are separated. It is a tiny protocol, like 200 lines of code, shown above. Implemented in both Python and C, with a C++ wrapper.
Other shells can probably implement FANOS, because it’s small, and involves no dependencies.
I was going to say I would pay a small bounty if anyone would like to work on upstreaming such a change to dash, bash, or zsh (paid out of our Github Sponsors). Similar to this bounty here, which awarded to Ellen Potter for finding a spec bug in our JSON parser (that should have been announced on the blog, but hasn’t yet):
But I think the problem is you also have to “audit” dash/bash/zsh for terminal output, which is not straightforward. That is, you could implement FANOS in any shell, for sure. It is simple and tiny. But the rest of the shell MAY have to cooperate. Some things will “just work”, but there will probably be edge cases.
And Oils is designed to cooperate, while being bash-compatible. For example, we can give control over where the shell prints error messages and such, because you may not want to display them in the terminal. It makes sense to display shell syntax errors next to where you typed them, near the prompt, not in the terminal where say docker is running.
I should also add that anyone who is interested in building a shell GUI should feel free to contact me, or join https://oilshell.zulipchat.com/ , for help with any shell trivia
I only know a bit about terminals, but I know a lot about shells from having reimplemented many, many things
I don’t have any plans to build something like this myself (due to working on many other projects, and lacking experience in GUIs)
But I’d like to prove that it’s possible to build – with a real protocol, rather than scraping the output of bash or zsh
It should make the UI a lot nicer in practice too!
This alone should make Ghostty worth installing for anyone who develops software that runs in the terminal, even if you dislike everything else about Ghostty. This is the sort of innovation we need to modernize TUIs and make them more user-friendly.
But this is theoretical for me because I haven’t gotten into the beta yet, so I’ve never used Ghostty or the terminal inspector, and so I’m also quite excited that we’re getting a public 1.0 release in December.
@mitchellh Since you emphasized platform-nativeness, I wonder if you’ve done any work with the platform accessibility APIs for the main terminal widget. Blind users often end up using other solutions, such as Speakup on the Linux test console or a screen reader inside the terminal, but I think there are other reasons to support the accessibility APIs, such as support for fine-grained cursor tracking in screen magnifiers.
Also, forgive me if you’ve answered this elsewhere, but on Linux, are you using GTK 3 or 4?
Ghostty 1.0 likely won’t have any differentiating accessibility features, but utilizing platform-native accessibility APIs is absolutely a goal. There is a large issue on it in the [currently private] Ghostty repository which you can read once it’s public.
Based on maturity and availability, it looks like right now the focus of any accessibility work will likely be within macOS, but it’s too early to make a final decision since it’s still under discussion.
Kitty is an excellent terminal emulator. I’d love for you to give Ghostty a try if only to hear why not. That feedback is just as valuable to me as bugs.
Kitty was my main daily driver prior to starting Ghostty. In my personal opinion, the main differentiator between Ghostty and Kitty will be in the platform-native features, such as native tabs, splits, and so on. Kitty’s performance is quite good (although, in most benchmarks we do better than Kitty it’s not likely to be especially noticeable compared to say something like Terminal.app or iTerm2).
In any case, as I said, Kitty is excellent, and I’d love to hear your experience with Ghostty when the time comes.
For what it’s worth, the feature that keeps me from migrating to ghostty, which I like better in every other respect, is the ability to click on a hyperlink to open a file in vim (I think this is implemented in PR #2111, which appears to be in limbo)
I ended up going back to Kitty after a number of months with Ghostty. The biggest reason was the lack of being a public project. When I needed to troubleshoot interaction issues I struggled to work with other open source projects and felt guilty using a nonpublic terminal.
That said I’ve not felt Kitty a downgrade at all. I personally don’t care about the native tabs. The GTK tabs are too big for me on Linux, but I can admit the experience is better on MacOS.
As I returned to being a Mac user recently I reinstalled Ghostty. Unfortunately I’ve since gotten a lot of mileage out of https://github.com/mrjones2014/smart-splits.nvim and I couldn’t find how to begin a Ghostty integration, if it’s even possible, in the limited time I gave it.
I’m looking forward to it getting the release it deserves. It’s a great project, thanks for sharing it. ❤️
For me, the benefit of the switch was that Ghostty just kind of worked out of the box in a way that Kitty never did. I’ve run into nightly-release bugs maybe once, but haven’t ever had to fight to get things like tmux or vim working correctly.
Have tried wezterm, alacritty and landed on kitty due to the first two not having optimal performance on my M1 mbp. Also font rendering seemed different, I like it chunky and felt the font-weight was not right in wezterm/alacritty.
Very excited for Ghostty as well. Might just use it as an excuse to get rid of tmux as well.
Been following Ghostty since day 1. Looking forward to December. I’m on Windows, so I’m interested in contributing when the time comes. Zig has been on my list of languages to dig into, so this may be a good excuse!
I’m interested, especially if it is in fact a native app on the Mac. The real, unquestioned benefits of eg kitty et al are totally overwhelmed for me by the fact that they’re not native apps. I use and pay for Prompt, because it is first and foremost a Mac (and iOS) app.
What are the specific macOS integrations a terminal emulator should have (Asking as a new macOS and WezTerm user who doesn’t understand what is missing)?
Mostly for me is native widgets, and its performance compared to other terminal apps that use electron, qt, etc… text rendering, and resource usage is a big one for me as well.
The title suggests the release of the software, in the retrospective he talks about getting shit for artificially building hype where he didn’t want to and the piece mainly reads like a piece for getting more hype. Nothing new that isn’t in the devlogs was written and I hoped to get actual new information, but at the end it’s nothing but fluff.
I can’t test the software, I can’t read code and all I get are 2 screenshots and an old table that tells me nothing.
No one mentions Zutty ever. To me this is the xterm of the modern era. Anyone could re-implement Zutty’s ideas in way less than 2 years time. Can the same be said of Ghostty?
Zutty is a good minimal VTxxx emulator. A modern terminal emulator requires much more than pure VT emulation today (xterm itself has many non-VT-compatible extensions). I suspect that’s why it’s not talked about very much nor do I see it in practical use very much.
As for the comment on 2 years: I don’t think it’s fair to weaponize the time I’ve been working on Ghostty in any meaningful way. For the first year it was very much a side project (a few hours every couple weeks), and for the last year its been very much a part-time focus (I have a newborn at home and its not my job). The time I spent on the project is meaningless.
Does anyone on the beta here have some opinions on how it compares to WezTerm which seems to have similar goals?
I daily drove WezTerm for a bit, and now use Ghostty. I think they’re both very similar in that they’re terminal emulators that both aim to be fast while having a lot of features, and either is very good to use if you don’t care about the details too much. The main differences IME are:
Does Ghostty offer multiplexing?
Ghostty offers splits, but it doesn’t support persistence like WezTerm. I’d say you’re better of using zellij either way if you want persistence.
That was basically what I was coming here to post. I’m a current WezTerm user, and the main advantage I see of Ghostty over it is native (GTK, for me) tabs, splits, &c, rather than the cross-platform non-native tabs and TUI menus that WezTerm has.
I’ve used both a lot. Ghostty is my daily driver now. WezTerm would be my go to if not for Ghostty, then it would be a tossup between Terminal.app and Kitty.
WezTerm has a feel like emacs or nvim-as-blogged-about-on-internet – you are kind of expected to do a lot of coding as configuration to turn it into a tool carefully crafted around the nuances of what you want. If you do that, it is great.
Ghostty is more opinionated and gives you fewer knobs, but the knobs are well chosen. Analogizes to OS X whereas WezTerm is a crunchy Linux (Arch or such).
In my personal journey, well, I declared .emacs bankruptcy a few years ago and wiped my accumulated configs from over two decades and moved to using defaults everywhere as much as I can bring myself to, as I don’t have the cycles to spend hand customizing all my tools and keeping everything up to date and so on :-/ YMMV
WezTerm is easily the best terminal emulator I tried so far and it too checks all the boxes in that list:
https://mitchellh.com/_next/image?url=https%3A%2F%2Fstatic.mitchellh.com%2Fghostty%2Fzig-showtime%2Fslide-7.png&w=3840&q=75
WezTerm does not check the native UI/integration boxes.
Thanks! I configured WezTerm to show very little window decorations and totally forgot about them being not native.
What would be today’s definition of “native”?
using the platform’s gui toolkit to draw tabs, right click menus etc
In terms of font weight, Wezterm renders thinner text than iTerm or Terminal.app does, enough to keep bothering me. I tried to tweak the configuration, but nothing helped enough.
To be fair, I faced the same problem with Kitty and Alacritty too.
I will see how Ghostty fares when I can.
Wezterm has many options for font customization. For example, it’s possible to disable anti-aliasing for even thinner fonts
I don’t think I’m after anti-aliasing.
Look at this screenshot that compares rendering of Cascadia Code fonts in iTerm with that of wezterm.
You should see that the characters marked with a red circle in the WezTerm window are rendered better visibly in iTerm than in WezTerm.
I wonder how ghostty compares to these two.
For what it’s worth, the only font-related config in .wezterm.lua is:
Interesting, I just tried Cascadia Code and it looks like the rendering is the same in iterm2 and wezrerm, maybe we have different font versions or something.
https://imgur.com/a/sh7Grk0
Yeah the results are almost identical. Can you share your config? Are you running wezterm on Sonoma on MacBook Pro M1?
Sure, here is wezterm config: https://pastebin.com/KChBQ2yW I tested on Sonoma on MacBook Pro M2, wezterm version is ‘wezterm 20240922-151228-2b76c63b’ and the latest version of Cascadia Code (2404.23).
Nope. I used your config verbatim with the latest wezterm. But I still get cut-off characters, and thinner fonts than on iTerm.
Thank you for your efforts though!
I think there are some global Fontconfig settings you can apply that will get you exactly the rendering you want. Unfortunately, I’m not at any of my Linux machines right now to share it here.
Yeh, same for me: https://federate.me.uk/@jperkin/112574990612338660
It’s such a small issue but makes applications unusable for me, there’s just something wrong with Linux-style rendering. It’s especially noticeable with “anything and everything” near the top of my first screenshot, the “y” is clearly rendered incorrectly.
I haven’t tried wezterm on Linux, so can’t speak to that experience. My problem is on macOS.
In general, though, while fonts on Linux (NixOS) are less crisp than on macOS, they don’t zig-zag as your
y.Yeh, this is on macOS. What I mean by Linux-style rendering is that wezterm uses harfbuzz rather than native macOS.
I see. I wasn’t aware of that. So if ghostty uses CoreText instead of harfbuzz on macOS, only then its font rendering will be comparable to that of iTerm.
I had the same annoyance with WezTerm and at least IME Ghostty looks functionally identical to iTerm. I did manage to get WezTerm to behave better by using the WebGpu frontend with a medium font weight, so you can try that if you haven’t already.
Thank you for the tip! I’m not a terminal emulator aficionado enough to have another go at wezterm. I will just stick to iTerm for the time being.
I remember mitchellh’s posts (on Twitter?) talking about the pains he took to implement font rendering in ghostty. I appreciate the efforts.
It’s really good! Ironically, I’d call Wezterm vs Ghostty to be emacs vs neovim despite wezterm being the one with Lua. Wezterm is far more flexible, one of if not the only terminal who’s config is a programming language. The sky is the limit with Wezterm, letting you even customize the UI.
Ghostty on the other hand is much more streamlined. It has less potential for ricing, but feels much lighter while still keeping the important stuff. Imagine alacritty, but with a 10% speed nerf, but with 90% of the features of wezterm, and all the ones anyone could ever want.
Recently got invited to the beta, making the switch from Wezterm. I mostly use CLIs and Helix / Vim though, so I don’t know if I’m as qualified to answer as, say, a power user would be.
This is exciting, and I’m looking forward to trying it in place of iTerm.
What are the security goals and architecture? Lots of features means lots of attack surface, exposed to remote servers and files accidentally cat’d to the terminal. For spatial memory safety, does it/can it use Zig’s release-safe mode? For temporal memory safety, what allocation strategy is used? Are the internals friendly to targeted fuzzing? Are there dangerous features exposing command execution or the filesystem? Is bracketed paste supported adversarially? /cc @mitchellh
To be clear, this is not a list of gotchas, but of potential wins over other emulators that would make me particularly excited about switching.
Great questions. Ghostty 1.0 will be just as vulnerable to terminal escape security issues as basically any other terminal (as described in recent blackhat talks and so on).
We have some rudimentary protections common to other terminals (but also notably missing from many) such as an “unsafe paste warning” where we detect multi line pastes or pastes that attempt to disable bracketed paste and so on. It’s not sufficient to call a terminal secure by any means but does exist.
On Linux we have the ability to put shell processes into cgroups and currently do for memory protections but stop there. When I implemented that feature I noted I’d love to see that expanded in the future.
I think the real answer though is that this is one of my top goals for future improvements to the terminal sequence level as I noted in the future section. I’m working on a design now but I want to enable shells to drop privileges while children are running much in the same way OpenBSD has a syscall to drop privileges. For example, a shell or program should be able to say “ignore all escape sequences” (maybe except some subset) so things like tailing or catting logs are always safe.
The security framework is probably my first major goal for innovation in the future. For Ghostty 1.0, I’ve more or less inherited all the same architectural problems given by the underlying specifications of old (defacto and dejure).
If you’d like to be a part of this please email me, I have a ton of respect for your work and consider you far more of a security expert than me!
I realized I didn’t answer some of your other questions in my other response. Let me follow up with that now:
For memory safety, we currently recommend ReleaseFast. The speed impact of the safety checks on the safe build are too great and noticeably make some things not smooth. We need to do a better job of strategically implementing safety check disabling on certain hot paths to make safe builds usable, but that is something I want to do.
Our debug builds (not release safe) have extra memory integrity checks that make builds VERY slow but also VERY safe. I’d like to setup build machines that run fuzz testing on these builds 24/7 using latest main. This is not currently in place (but the integrity checks are in place).
Re: fuzzing: the internals are very friendly to fuzzing. We’ve had community members do fuzzing (usually with afl) periodically and we’ve addressed all known fuzz crashes at those times. It has been a few months since then so I’m not confident to say we’re safe right now. :)
Longer term, I’m interested in making an entire interaction sequence with Ghostty configurable in text so we can use some form of DST and fuzzing to continuously hammer Ghostty. That’s a very important goal for me.
I’m not super familiar with the intricacies of Zig, but does it have any way to toggle individual safety checks? IME there are things like bounds checks that are basically free and massively help with safety, and then you have things like null checks that aren’t as useful for safety but are still basically free, and then you have things like checked addition that are comparatively expensive but don’t really give as much on their own. That might be something to check out?
Great questions. Curious about this at well.
I’ve been using Ghostty for a couple of weeks now, and all I can say is that it’s as if the best parts of iTerm2 and Kitty were combined. It’s really fast, has great native integration with the OS (e.g. uses macOS tabs instead of Kitty doing its own thing) and is packed with features that I always end up missing from iTerm, like the newly added quake terminal. I think the only thing I miss from iTerm2 is support for tmux’s control mode (on the way) and config profiles, both of which I can live without. It is genuinely shocking to me how good and uncompromising it is, and I think many will find it worthwhile to switch. Kudos to Mitchell!
It’s funny how different feature sets are key; losing configuration profiles is a dealbreaker for me, so I’m both happy for you and glad you clarified that I should not try migrating.
Be still my beating heart
At this point, don’t all major terms do?
Alacritty, which I stick with because I think the font rendering is the best I’ve found on Linux, does not.
Wezterm does, for what it’s worth
This sounds awesome! I’m very glad it will be open source
The
libghosttyAPI to embed terminals in other applications sounds exciting too. I’ve long said that a shell UI should have a terminal, but not be a terminal. That is, it can be a GUI with a terminal.You need the terminal to run
pipordockerorCargo, because they all use terminal escapesBut the shell itself can be divorced from the terminal. (The usual way it works is that the shell and the child processes it spawns both write to the same file descriptor, via descriptor inheritance. And that descriptor often represents a terminal, which is a kernel data structure.)
In particular, history and completion can be a GUI like they are in the browser (hopefully without all the dark pattern shenanigans)
We have a prototype of that working here, with screenshots:
https://www.oilshell.org/blog/2023/12/screencasts.html#headless-protocol-oils-web_shell
This is possible because Oils has a “headless protocol” that works via passing terminal FDs over a Unix domain socket, which works perfectly on any Unix, including Linux and OS X, which ghostty targets.
OSH is the only POSIX- and bash-compatible shell that has a headless protocol. You can’t do it with bash or zsh.
And YSH is in the same binary, with a brand new legacy-free language (not quite stable, but getting there). Also, the whole
oils-for-unixbinary is about 2 MB of native code now. It builds with just a C++ compiler on any Unix (no make, autotools, CMake, and no Python).The interactive shell is still a bit of a side project for Oils – we are concentrating on the YSH language now and “Hay Ain’t YAML” – but I wanted to put that out there for anyone interested in shell GUIs.
I don’t happen to know much about terminals personally, so contributors are very welcome! Samuel and Subhav has pushed on this in the past, mentioned in the blog post linked above. At the very least, I would like to get a proof of concept published with libghostty, so other people have something to push on
(Also, I’m not sure if anything like libghostty exists in C or C++ or Rust, but if it does, I’d be interested)
Also I have to say I relate to this:
There is a small minority of people who are bit loud about their (sometimes bizarre, flimsy) opinions.
But also a larger number of people who are taking the time to understand the project and code, and who contribute a lot in their valuable spare time (including testing and docs, not just code). I know that is hard, and I appreciate it a lot!
Can you explain how this relates to the bash_kernel in Jupyter? It seemed to work, though not without problems.
I’ve looked at it briefly, but not really used it … IIRC it does some kind of bash stdin/stdout scraping/parsing, as most such tools do, including Emacs plugins and so forth.
That could involve the prompt string, e.g. setting
PS1=to something magic, and then looking for that string to try to distinguishdocker, wroteThat is OK for basic cases of running synchronous commands, but there are edge cases, like asynchronous commands, or unusual terminal escapes
The general problem is as mentioned - the shell and child process traditionally write to the same file descriptor. So you don’t have a good way of distinguishing their output by reading the other end of the descriptor – you’re left with ad hoc parsing.
At least the Oils project is trying to remove the ad hoc parsing / “string gobbledygook” from both the shell language and from its interfaces to the rest of the system.
So instead we do something more principled, but compatible. The headless mode is implemented with a tiny “FANOS” protocol - “file descriptors and netstrings over sockets”
https://www.oilshell.org/release/0.23.0/doc/headless.html#implement-the-fanos-protocol
So the GUI would just pass a shell command, along with a file descriptor to specify where it wants the output to go. It could be either:
docker, in which case you pass a terminal for the headless shell to pass through to thedockerprocess. The shell doesn’t write there, butdockerdoes.echo ${PS1@P}. This generally involves running user-defined code, and then you can display the prompt outside a terminal, in a GUI.So basically the two channels (shell vs. child process like docker) are separated. It is a tiny protocol, like 200 lines of code, shown above. Implemented in both Python and C, with a C++ wrapper.
Other shells can probably implement FANOS, because it’s small, and involves no dependencies.
I was going to say I would pay a small bounty if anyone would like to work on upstreaming such a change to dash, bash, or zsh (paid out of our Github Sponsors). Similar to this bounty here, which awarded to Ellen Potter for finding a spec bug in our JSON parser (that should have been announced on the blog, but hasn’t yet):
https://lobste.rs/s/1y9hjq/regular_json#c_8tvoie
But I think the problem is you also have to “audit” dash/bash/zsh for terminal output, which is not straightforward. That is, you could implement FANOS in any shell, for sure. It is simple and tiny. But the rest of the shell MAY have to cooperate. Some things will “just work”, but there will probably be edge cases.
And Oils is designed to cooperate, while being bash-compatible. For example, we can give control over where the shell prints error messages and such, because you may not want to display them in the terminal. It makes sense to display shell syntax errors next to where you typed them, near the prompt, not in the terminal where say
dockeris running.I should also add that anyone who is interested in building a shell GUI should feel free to contact me, or join https://oilshell.zulipchat.com/ , for help with any shell trivia
I only know a bit about terminals, but I know a lot about shells from having reimplemented many, many things
I don’t have any plans to build something like this myself (due to working on many other projects, and lacking experience in GUIs)
But I’d like to prove that it’s possible to build – with a real protocol, rather than scraping the output of bash or zsh
It should make the UI a lot nicer in practice too!
Interesting, thanks.
Does it support sixel graphics? What has kept me on foot has been that yazi is able to preview images in the terminal.
Ghostty uses the Kitty graphics protocol instead of sixel.
Thanks, that would be one reason for me to stick to Wezterm, as tmux supports sixel but not the Kitty protocol.
[Comment removed by author]
The “killer feature” that immediately made me excited about Ghostty is the “terminal inspector”: https://mitchellh.com/writing/ghostty-devlog-005
This alone should make Ghostty worth installing for anyone who develops software that runs in the terminal, even if you dislike everything else about Ghostty. This is the sort of innovation we need to modernize TUIs and make them more user-friendly.
But this is theoretical for me because I haven’t gotten into the beta yet, so I’ve never used Ghostty or the terminal inspector, and so I’m also quite excited that we’re getting a public 1.0 release in December.
@mitchellh Since you emphasized platform-nativeness, I wonder if you’ve done any work with the platform accessibility APIs for the main terminal widget. Blind users often end up using other solutions, such as Speakup on the Linux test console or a screen reader inside the terminal, but I think there are other reasons to support the accessibility APIs, such as support for fine-grained cursor tracking in screen magnifiers.
Also, forgive me if you’ve answered this elsewhere, but on Linux, are you using GTK 3 or 4?
Ghostty 1.0 likely won’t have any differentiating accessibility features, but utilizing platform-native accessibility APIs is absolutely a goal. There is a large issue on it in the [currently private] Ghostty repository which you can read once it’s public.
Based on maturity and availability, it looks like right now the focus of any accessibility work will likely be within macOS, but it’s too early to make a final decision since it’s still under discussion.
It’s GTK 4 with libadwaita if available.
I will have to try this. As a happy kitty users it’s really unclear what this brings new, but I better try it before I make up my mind :)
Kitty is an excellent terminal emulator. I’d love for you to give Ghostty a try if only to hear why not. That feedback is just as valuable to me as bugs.
Kitty was my main daily driver prior to starting Ghostty. In my personal opinion, the main differentiator between Ghostty and Kitty will be in the platform-native features, such as native tabs, splits, and so on. Kitty’s performance is quite good (although, in most benchmarks we do better than Kitty it’s not likely to be especially noticeable compared to say something like Terminal.app or iTerm2).
In any case, as I said, Kitty is excellent, and I’d love to hear your experience with Ghostty when the time comes.
For what it’s worth, the feature that keeps me from migrating to ghostty, which I like better in every other respect, is the ability to click on a hyperlink to open a file in vim (I think this is implemented in PR #2111, which appears to be in limbo)
I use this feature in kitty constantly
I ended up going back to Kitty after a number of months with Ghostty. The biggest reason was the lack of being a public project. When I needed to troubleshoot interaction issues I struggled to work with other open source projects and felt guilty using a nonpublic terminal.
That said I’ve not felt Kitty a downgrade at all. I personally don’t care about the native tabs. The GTK tabs are too big for me on Linux, but I can admit the experience is better on MacOS.
As I returned to being a Mac user recently I reinstalled Ghostty. Unfortunately I’ve since gotten a lot of mileage out of https://github.com/mrjones2014/smart-splits.nvim and I couldn’t find how to begin a Ghostty integration, if it’s even possible, in the limited time I gave it.
I’m looking forward to it getting the release it deserves. It’s a great project, thanks for sharing it. ❤️
For me, the benefit of the switch was that Ghostty just kind of worked out of the box in a way that Kitty never did. I’ve run into nightly-release bugs maybe once, but haven’t ever had to fight to get things like tmux or vim working correctly.
I can’t wait to use it. I’ve been using Alacritty and iTerm2 here and there, but mostly Alacritty which is a ok, but customizing it is a bit of a pita
Have tried wezterm, alacritty and landed on kitty due to the first two not having optimal performance on my M1 mbp. Also font rendering seemed different, I like it chunky and felt the font-weight was not right in wezterm/alacritty.
Very excited for Ghostty as well. Might just use it as an excuse to get rid of tmux as well.
Been following Ghostty since day 1. Looking forward to December. I’m on Windows, so I’m interested in contributing when the time comes. Zig has been on my list of languages to dig into, so this may be a good excuse!
I’m interested, especially if it is in fact a native app on the Mac. The real, unquestioned benefits of eg kitty et al are totally overwhelmed for me by the fact that they’re not native apps. I use and pay for Prompt, because it is first and foremost a Mac (and iOS) app.
What are the specific macOS integrations a terminal emulator should have (Asking as a new macOS and WezTerm user who doesn’t understand what is missing)?
The first and most important thing is how do you configure it. If you have to edit a text file, I’m sorry, that’s straight into the bin for me.
I want a text file because I can commit it to a repo. :)
This is totally reasonable! It’s not a concern for me, but my needs and preferences are, first of all, mine, not everyone’s.
ghostty is configured via a text file
I am interested in all of them, I wondering how I can improve my workflow!
It’s fair! Everybody has their own local maximum!
Mostly for me is native widgets, and its performance compared to other terminal apps that use electron, qt, etc… text rendering, and resource usage is a big one for me as well.
I’m looking forward to trying it, but also to seeing more concrete details about the Zig/Mac integration surface.
“I’m sorry for the hype. Here is not a release but a teaser for a release in one month! Again sorry for the hype. Have fun waiting for a month”
I don’t care for private betas or whatever, but this post is just hype and nothing more.
It’s a project retrospective, what’s the big deal?
The title suggests the release of the software, in the retrospective he talks about getting shit for artificially building hype where he didn’t want to and the piece mainly reads like a piece for getting more hype. Nothing new that isn’t in the devlogs was written and I hoped to get actual new information, but at the end it’s nothing but fluff.
I can’t test the software, I can’t read code and all I get are 2 screenshots and an old table that tells me nothing.
No one mentions Zutty ever. To me this is the xterm of the modern era. Anyone could re-implement Zutty’s ideas in way less than 2 years time. Can the same be said of Ghostty?
Zutty is a good minimal VTxxx emulator. A modern terminal emulator requires much more than pure VT emulation today (xterm itself has many non-VT-compatible extensions). I suspect that’s why it’s not talked about very much nor do I see it in practical use very much.
As for the comment on 2 years: I don’t think it’s fair to weaponize the time I’ve been working on Ghostty in any meaningful way. For the first year it was very much a side project (a few hours every couple weeks), and for the last year its been very much a part-time focus (I have a newborn at home and its not my job). The time I spent on the project is meaningless.