> I like where we're headed with tools like this and Ladybird[0] for hope of a subscriptionless future.
That's a weird statement. I've been running a free, open-source and subscription-less browser (firefox) and terminal emulator (many) for close to 20 years.
Actually I like what ladybird is doing in the browser space, given firefox is quite dependent on google cash. But this is just yet another terminal emulator in a sea of them. The only two distinguishing features I can see are hype and native UI (which mac users care about for some reason -- my native UI is a borderless rectangle in tiling WM).
What is native UI in this context? My terminal emulator is also always basically a full-screen black textarea with white letters. No window borders, no tabs, no buttons, no menus, nothing else. Is there anything native UI would give me in this case (and what is a native UI, I can't find it defined anywhere)?
> The big picture of "native" is that Ghostty is designed to look, feel, and behave like you expect an application to behave in your desktop environment.
> On macOS, the GUI is written in Swift and uses AppKit and SwiftUI.
I'm using Linux with Xfce, but it seems to be locked into a Gnome-like look and feel, with header bars and CSDs that can't be disabled in favor of standard title bars and menus, so it's actually very inconsistent with the rest of my desktop environment.
After testing Ghostty out for a while, though, I've realized that input lag is higher than xfce4-terminal, font rendering is blurrier with equivalent settings, the UI is still less consistent with my desktop, and it has three to four times the memory footprint on top of all that. Since xfce4-terminal is already using native GTK, so there's nothing gained on that front.
Disabling the UI cruft just turns it into a less performant version of Xterm, so unfortunately, this is going to be an uninstall for me.
> This also means that native features like pressing Shift+⌘+\ open the tab overview, just as in other applications.
Ah, so this is a macos thing and not just Safari. Can anyone help me select a tab using a keyboard? I use the shortcut, type in the search box and...have to use the mouse :(
I don’t recall where, and don’t have my laptop handy, but there is a macOS system option to enable tabbing through all controls (not just inputs), that _should_ do it
Your rebuttal is not mutually exclusive to the parent comment. They say it’s the first _new_ such thing in a while, not that there aren’t any in existence.
It does where it says they give hope for a wunsciptionless future. We've always had subscriptionless, and the software that was subscriptionless is still around.
Can't edit my post anymore so replying to myself with an addendum:
I wrote the comment in a rush last night and I think it sounds like I'm dumping on ghostty. That is not my intention, it looks very well made and a true passion project which I have lot of respect for.
I just took issue with GP adding yet more hype to this.
It's uncommon for upstream to provide .deb packages. That's not really how it's supposed to work. The Debian community creates Debian packages. Upstream's job is only to avoid making the Debian community's job more difficult than necessary. Unfortunately due to the decisions made by various popular Linux projects (mainly an obscene obsession with dynamic linking), it's not really feasible for upstreams to provide GUI applications on Linux. I hope someday this can change, but realistically there's not enough effort being put towards this goal.
well you'll have to get a DD on board to do the work and zig isn't even in debian so that'd have to get there first and the person wanting the terminal probably doesn't want to maintain the programming language as well. So that probably means 2 DDs. Again, there is a non-normal distance here.
Perhaps if one was inclined, Nix can provide immediate resolution, since it can be installed and used on Debian and ghostty project provides convenient flake.
Granted I'm on NixOS, but took me grand total of 60 seconds to update config and 8 minutes of actually building on a slow machine.
I've grown so sick of tools/TUIs that output unreadable text (like Debian's ls that defaults to dark-blue-on-black for directories). I look forward to never manually theming a terminal app again!
Another goodie is selection-foreground and selection-background config to set the colour for highlight selection, makes a massive difference when it's something you can choose rather than the translucent crap on mac, or the defaults on Windows/Linux.
So I will see how well it works on FreeBSD, but I love the development model, keeping it "closed" for the 1.0 (focus and polish), I have not tested it yet, but it already "feels" like professional engineering work.
I've been using Ghostty for several months now (used Alacritty before that). Ghostty is really, really good. It's fast, it gets the text rendering right (many cross-platform terminals struggle with this), and it has all the features I need.
It's also some very well-written Zig code. We use some of the code for graphemes in Bun for `Bun.stringWidth`.
Likewise coming from alacritty myself. This out of the box gives me everything I really want and does it well. Not to mention the development process was quite refreshing to see. Decision making process for sane defaults and to allow customization quite easily.
There isn't an option to set the default height of the "quick terminal" window that I'm aware of but you can drag the bottom of the window after it opens and it will persist between toggles.
Comes from video games where you usually can hit ~ (tilde) or other character to make a in-game console appear, usually sliding down from above or at least in the top half/third/quarter of the screen. Popularized by Quake and games from that heritage (like Source engine) I suppose.
Desktop equivalent is that you have a terminal available at a short-cut/button-press that will always show it but not fully hide the rest, no matter what other context you're in. Pretty handy.
> a terminal available at a short-cut/button-press that will always show it but not fully hide the rest, no matter what other context you're in
I cant be the only person who uses Quake-style terminals at fullscreen. The second part of your sentence is the crucial bit: the ability to instantly conjure a persistent terminal regardless of whatever else I have on screen.
Can you then detach it to make it "non-quick", if you want to keep working on that separate context thing?
What I find annoying with my workflow (linux) is that starting a terminal and shell takes a lot of time. I wonder if it's possible to have a terminal always loaded so that my keybinding for creating a terminal would actually: move terminal in current workspace, focus it, then spawn another invisible terminal in the background.
Yakuake supports invoking the terminal in windowed-mode, if that's the profile you choose for it. I don't follow the purpose served by spawning an invisible background terminal; that doesn't seem to be common workflow, but I suspect you could wrangle it in your shell startup file so that the terminal self-invokes in hidden mode - but having 2 running copies (invisible and windowed) may result in both appearing when you press your global shortcut.
I kind of use tmux for this, to have a persistent session. Even if my desktop manager (Gnome3) crashes, which happens sometimes when I run a bazillion VMs and run out of memory, my tmux session still survives and I can `tmux attach` once logged in again.
So the idea would be that you start tmux somehow/somewhere, then in your new shell you can do `tmux attach` to get into that session from anywhere, and if you close this new shell, you can still do `tmux attach` to get back to where you were.
> I wonder if it's possible to have a terminal always loaded so that my keybinding for creating a terminal would actually: move terminal in current workspace, focus it, then spawn another invisible terminal in the background.
Use rxvt-unicode or another terminal that has a client/server mode. Start up a server in the background on boot or login (e.g. as a systemd user service), and make your keybind launch a new client process. Should be pretty much instant.
Yeah I have been using quake-style terminals (guake on linux, iterm2 on mac) for _years_. I never met another dev in person who also uses it.
I am a single massive monitor kind of person. Quake-style terminal + all apps in maximized window + multiple desktops (with a shortcut to switch between them) is so good. Pull up the same terminal no matter which desktop you are on.
And you can reload the config with Cmd+Shft+, so Cmd+, to open the config (standard mac shortcut) and then the same with Shift to reload it, it's genius.
Let's hope it will become available for Linux, too. I have been using Yakuake for over a decade now, mostly because I love how I can access the terminal everywhere with one button press.
At the same time, Yakuake seems to be in maintenance mode, and you should be happy when it works with new KDE versions.
Unfortunately no tab support yet in the quick terminal, and it does not work on top of fullscreen applications.
Would be great if these things would work at some point.
Currently I am using Wezterm and iTerm2 for the quake style terminal, but using two different terminals is quite annoying.
I really miss Visor and TotalTerminal.
GP means creating a new tab with CMD+T, which works in the normal ghostty terminal. iTerm2 does support tabs in its hotkey windows (~= ghostty's quick terminal).
I initially scoffed when I read "platform-native UI" as I've found programs made in Electron typically proclaim something similar when they are anything but native, so when I saw it used GTK for Linux (SwiftUI for MacOS) my interests were piqued. Always fun to mess around with new terminal emulators.
IMO the main reason is high DPI screens. On macs it's essentially the default, and it'll probably become the default in the future for everything. Since bitmap fonts make much more sense with low pixel density I think it's not going to be a priority for any newly developed apps.
Bitmap fonts can be scaled by integer factors without losing any crispness, and most high-DPI displays in common use today would look just fine with a 2x or 3x font upscale.
You can get pixel perfect bitmap fonts by using their TrueType conversions and using fractional point font sizes. There are dozens of bitmap enthusiasts that were in the beta and they're totally convinced because well... it's pixel identical.
I've noted before in issues I'm open to supporting bitmap fonts if someone contributes it, but not interested in adding it myself. The workaround above is very good.
When using the original Terminus font failed, I tried the TTF version (Terminess) which in VSCode at specific point sizes is crisp and sharp. But with Ghostty, it was blurry and hard to read. At that point I gave up trying.
The reason might be that you need to have an "anti-aliasing" checkbox to untick on MacOS (generally in the font selection menu). I switched from Terminal to iTerm for that reason, on my work MBP.
Looks like a very nice project overall. I was initially interested in the "native" UI but after trying Ghostty I think I've realised that in a terminal app I actually want all the UI to be terminal/TUI based within the terminal itself. This is a personal preference I've discovered rather than a criticism of Ghostty.
It seems fast and really nice otherwise, so I'll keep fiddling with it, but so far I still prefer, for example, the "non-fancy" tabs in WezTerm (where the tabs are just rendered as line of terminal cells at the top or bottom of the window rather than GUI elements), and the way that modals ("Really quit WezTerm?" etc.) are also rendered within the terminal.
I'd also struggle to live without quick select mode[0].
Aren't plaintext configuration files standard? It's how I configure most applications (and how I like it, because it makes the configuration shareable).
As a DSL, it's key-value pairs. It doesn't get much simpler than that.
It's a desktop/GUI application. It's definitely not a standard for those, no.
I share the OPs frustation that I don't even know what I can configure and have to search web to be able to change something. And while the documentation is nice, it's not exactly great for this.
Also, having an explorable and searchable UI doesn't mean it's not saved in the same shareable and readable file.
The ultimate end format for the config stored on disc is completely irrelevant to how the config is created. Simple doesn’t mean easy to experiment with, simple to understand, fast to write and so on.
No one is confused as to how the ghostty config works. Key value pairs. Sure. A window full of GUI controls and system color pickers can create that config file, or I can manually by hand. I’d prefer the former.
Same here. I was curious, so I installed it. First thing I tried to do was to change the text color, and saw there was no settings UI. This is a bit baffling to be honest.
Uninstalled it right away, I'll keep using the default MacOS Terminal app.
kitty has a nicely formatted config which lists all settings along with their default values and a very detailed description of each one. It's pretty much the same as having a GUI. Maybe Ghostty can adopt this?
Interesting take. Settings are typically something I setup once and move on. A GUI is nice (I'm sure there will be one), but not required in a v1. One of Ghostty's stated goals is sane defaults that mostly work out the box. I just checked my settings file and I changed 3 things. I think they did a pretty good job with defaults.
Finally, somewhere else in this thread someone linked a web tool that will generate the settings if you absolutely can't look up the couple you need to change.
> For example, on macOS, Ghostty supports Quick Look, force touch, the macOS secure input API, built-in window state recovery on restart, etc. These are all native APIs provided by macOS that don't have equivalents in Linux desktop environments.
I believe window state recovery has some approximate equivalent in GNOME and KDE, but maybe not exactly the same (and I don't know how easy it is to integrate with).
This has been a passion project of his for the past 2-years and he’s completely MIT open sourced it. He’s spent a lot of time thinking and ensuring this project can persist in the future even without him.
Many people have tremendous respect for Mitchell’s technical abilities, as well as hugely respect how he operates (genuinely nice person and thinks about things long-term and does the hard work for sustainability).
It doesn't work in Windows so how is it cross platform?
Also, I've been using terminals since DOS in 1990 and never once have I had to say, "I wish this terminal had more performance", so I'm not sure that performance is really relevant here. If I write a command to build my project which takes 10 mins to build, does it matter whether the terminal command ran in 10 milliseconds vs 1 millisecond?
In the linked speed demo one command was 8 milliseconds faster than another. Ok?
Is a terminal written in Zig better than one made in C++ or Rust? Again, unsure why its relavant at all.
If you use something like tmux you will notice higher latencies. Clearly, if you've been using terminals since DOS in 90s and the issue does not bother you, then you are likely happy with whatever it is you are using. If you want to look into the issue and read on methodology used before I recommend Dan Luu's from 2017 [1]
Ghostty, Mitchell, and the community around Ghostty, are all really amazing and pleasant to work with. I've had a lot of fun hanging out in the Discord, and sending in a couple of PR's. Everyone is really kind and accommodating. It's a pretty great example of how to run a community and open-source project, even this early on.
Does it support Ctrl+Scroll to zoom? Somehow I got used to this years ago and unfortunately not a lot of software supports it. Have been using Wezterm until now, which does.
I think it’s both fair to say Linux and Mac make something cross platform, but it’s also very reasonable to expect Windows as well given its massive install base size.
But defining it by total users isn't very useful either - in this case, "total users who regularly use a terminal" would be a far more relevant factor. I think the only reasonable, useful, general definition of "cross-platform" is "runs on at least 2 of the 3 main desktop platforms".
I’ve been very disappointed with Alacritty (no support for split term in favor of tmux) and WezTerm (insane config format, config has no business using a full fledged programming language) feature wise, so I have high hopes regarding Ghostty, can’t wait to try it!
Config being a programming language has insane advantages. Not only can I error check my config in vim or Visual Code, I can do insane things with logic that just don't work in other config file approaches. My laptop is connected to a 32" 4k monitor at work, standalone while traveling, and to a 27" 2k at home. WezTerm "knows" that, and sets things such as font size and line height automagically.
Even more, I can have split logic based on window size, window titles that show me who also checked out a file while I am inside an editor, even per-window color and font schemes.
All apps should use something like Lua for their config.
It's great that you (and many others) find it useful, but I genuinely have no idea what this is about. I switch my iTerm from my 13" MBP, 32" monitor, and iPad all the time, and I don't need any config to make it work. Maybe I just don't care enough about this stuff but I don't see what I would even configure this way.
Anyway, this is the reason I love the new wave of terminals, they bring new stuff on the table and anyone can find one they love. I just installed Ghostty and it works as I expect out of the box, with even less config (0) than I have on iTerm. And it's fast. Now I just hope they'll add a config UI some day (one of the reasons I prefer static config files: you can't really get a UI with a programming language) and I'll be in terminal heaven
If you don't care about this stuff you'll just as easily configure in a static key=value table whatever you like, lua doesn't limit you here. It's benefits are all optional
I've used wezterm for years and have never done anything fancy with the config, but this sounds awesome. I'd really appreciate it if you could link your config or a similar resource.
I just started using wezterm, my config isn't as mature or fancy, but I already found a spot where lua config is making me happy. I added a feature so I can command-click on Github PR numbers in Wezterm to take me to that PR on Github.com. Here's a permalink to the code: https://github.com/justjake/Dotfiles/blob/030c5d2b43e944df55...
The way this works in Wezterm is you can add regexes that match text in the terminal and format that text as links. So, I turn #(\d+) into "GITHUB_PR:$1" and then add a "on link clicked" callback to handle that special URL form by shelling out to `gh pr view --web $1` in the same working directory as the clicked pane.
This is what I love about wezterm. I have a whole system that detects lightness and changes themes automatically, and also sends commands down to any open nvim instances to switch colourschemes there.
The only downside is that there is no going back for me haha.
Lua is also simple enough that if you want to have a static config, you can have a single table that is very json-like.
<3 This has been a work of passion for the past two years of my life (off and on). I hope anyone who uses this can feel the love and care I put into this, and subsequently the amazing private beta community (all ~5,000 strong!) that helped improve and polish this into a better release than I ever could alone.
Ghostty got a lot of hype (I cover this in my reflection below), but I want to make sure I call out that there is a good group of EXCELLENT terminals out there, and I'm not claiming Ghostty is strictly better than any of them. Ghostty has different design goals and tradeoffs and if it's right for you great, but if not, you have so many good choices.
Shout out to Kitty, WezTerm, Foot in particular. iTerm2 gets some hate for being relatively slow but nothing comes close to touching it in terms of feature count. Rio is a super cool newer terminal, too. The world of terminals is great.
I’ve posted a personal reflection here, which has a bit more history on why I started this, what’s next, and some of the takeaways from the past two years. https://mitchellh.com/writing/ghostty-1-0-reflection
Looks really awesome. I'm going to sound like I don't belong in the hipster terminal club, but the reason I shied away from some of the other terminals is the lack of tabs, which looks like yours has when I did a quick Google question/search. (if wezterm and the like have them, I must have missed it or it wasn't obviously apparent in the settings how to achieve them).
I know everyone will say but tmux and/or native multiplexing bla, but I'm kind of old school and only do screen remotely if needed, and I just like a lot of terminal tabs in my workflow with a quick mod left/right arrow to navigate between (and if native multiplexing in Ghostty is simple and easy I'd probably do some of that too).
Perhaps this is why I've never left iterm2.
WezTerm has emulated tabs, not OS-native tabs. Some people will find that to be enough to suit their needs. Others will want 'real tabs'.
For example, I can select a tab in Ghostty, pull it out into its own window, and then stick it into another window. This doesn't work in WezTerm, nor can you drag them around to rearrange them (keyboard shortcuts allow this however).
I'm honestly not sure what a OS native tab is supposed to be, on Linux. And I do not see why "emulated tabs" of WezTerm couldn't just do the actions that you describe. The Firefox tabs do after all, and they do not look like they are built according to some (GTK?) tab standard (GTK.Notebook?). I'm pretty sure that X11 does not have native tabs, while some window manager do. Is there a linux standard I'm just not aware of that you are referencing here?
Maybe it does not matter, the difference in functionality should count. Just highlighting that this messaging might not be understandable for linux users. I guess you are talking about some macOS thingie that's irrelevant to us.
I agree with the philosophy of no tabs, but I simultaneously live in an intermediate desktop environment situation where I don't have access to the "right" solution yet. So I'm happy to have terminal emulator tabs, browser tabs and IDE tabs for lack of a more integrated solution.
Wezterm has tabs right out of the box and they are fully customizable, though I prefer tmux since I prefer to not have my data extinguished if I accidentally close the terminal :D
WezTerm shines in ease and breadth of configurability due to using lua, so it's simple to have the theme change between light/dark depending on host OS theme.
Interestingly there’s another comment ITT complaining that they need to use a programming language for configuring wezterm :)
As a wezterm user I’ll admit that configuring it was mildly annoying to start, but ended up feeling like an accomplishment. A few years in, it’s just another annoying program I have to re-remember how to use when i update twice a year.
I don't know Lua either but c'mon now. It's just some config. Copy and paste from the docs and tweak the values as needed. If you really want to write something funky in there, ChatGPT knows Lua. It's not that bad.
Yeah. I could get by with the default Linux terminal and tmux really. Tmux is just the best. Second to vim it’s the single most useful thing I’ve ever used.
I also use tmux, but I love the native tabs of Konsole in KDE. I have Shift-Arrow configured to move between them, it is far more comfortable than the dual shortcuts needed by tmux, Ctrl-B to call tmux's attention then l (if I remember correctly) to get to the last tab.
Konsole also has easy resizing of text and supports images in the console, you might like it.
jj or qq can also be used. As I once started with GNU Screen ages ago, I like prefix to ctrl+a but it interferes with going to front of command in bash mode. For that, I use vi keybind mode in my shell (fish or bash) which feel very natural to me. For zellij, I use default prefix so that it does not interfere with remote (yes I am aware remote requires double prefix; I prefer using tmux remotely and zellij locally).
How are you configuring jj without interfering with using the key regularly? I used to have jj bound to ESC in VIM, loved it, but I've since trimmed back my config as I SSH into to many foreign systems to depend upon nonstandard behaviour. But I'd love to have it in Tmux.
The obvious `set -g prefix jj` throws an error that the key j is a bad key. Various experimenting with bind and unbind have not resulted in success, and I can't seem to find an example .tmux.conf with that config to copy.
I second this. I wouldn't have been able to make tmux such an integral part of my daily workflow if it weren't for this binding that I came across in someone's starter tmux conf many years ago.
As a longtime KDE fan I've used Konsole for years and it is seriously underrated. However, after I discovered Kitty a few months ago, I fully converted and cannot be happier. You can also move between tabs using keyboard shortcuts as well as move the tabs themselves. What I like about Kitty more is its straightforward text file based approach for configuration and absence of any gui elements. Konsole's GUI and configuration menus are overwhelming and I think are in need of a deep redesign.
I've been a beta tester from very early on. I came for the performance but stayed for the stability. I've only had a rare few crashes and all but one was a duplicate in the bug tracker.
I thought I needed search but as Mitchell put it, not a 1.0 feature. Ripgrep was always the answer.
Very happy to share the ghostty experience with the world!
I noticed a keybinding for write_scrollback_file (defaults to super+shift+j) which does this. So you can use `grep something <super+shift+j>` to search for things. It's a nice workaround until search is implemented.
Thank you for building this! I’ve loved using this over the last two months or so and really appreciate the work you’ve put into it.
I’ve been a very happy iTerm2 user and support the dev on GitHub Sponsors (and I’ll continue to do that), but I love your commitment to making a fast, native app (and cross platform, no less) and really appreciate this very obvious labor of love that has also been really interesting to watch from afar as the development has progressed!
I think you've done an excellent job running the community for Ghostty and it is a prime example of how to do it right. From the Discord to Github repos you've been a class act all the way through and have pushed folks to be good, civil internet denizens. Much respect.
If anyone cares to search through Github, they will see loads and loads of Issues and PRs created by Mitchell in many of the related Open Source projects that Ghostty uses/references. From zig to kitty to supporting libraries, Mitchell has been trying to get the terminal community working together and have some sort of standards. A lot of them are like "X does this, Y does that, why are you doing it this way? Can we all do it this way?" and then having Ghostty follow the most reasonable solution (or supporting several!).
Just make sure not to get caught in the pitfall that is maximum render speed, which can lead to missing out on efficiency during slow and partial rendering.
Missing damage tracking, always painting everything (even when the window is a full 4k monitor), etc. kills performance and input latency when dealing with realistic redraw workloads like text editing, blinking cursors and progress bars. Much too often to terminals worry only about the performance of `cat /dev/urandom`...
He mentions input latency[1] as one of 4 aspects of being fast that were considered during development. I’m not aware of how that was tested, but would trust that it outperforms Iterm2 in that regard.
I gave up on alacritty because it was always using the dedicated graphics card of my MacBook and there was no reasonably way to use the integrated graphics card because it was “low performance”.
- Ghostty does vsync by default and supports variable refresh rates (DisplayLink). If you're on battery and macOS wants to slow Ghostty down, it can and we respect it.
- Ghostty picks your integrated GPU over dedicated/external
- Ghostty sets non-focused rendering threads as QoS background to go onto E-cores
- Ghostty slows down rendering significantly if the window is obscured completely (not visible)
No idea if Alacritty does this, I'm not commenting about that. They might! I'm just talking from the Ghostty side.
I, a person who don't care about battery performance one iota (because my computer has no battery), love this answer and approach. Not every software is for everyone, and authors drawing a line in the sand like that works out better for everyone in the long-term, instead of software that kind of works OK for everything.
In some cases yes. In this case, in my opinion it can be strictly wrong.
The GPU requirements of a terminal are _minuscule_ even under heavy load. We're not building AAA games here, we're building a thing that draws a text grid. There is no integrated GPU on the planet that wouldn't be able to keep a terminal going at an associated monitor's refresh rate.
From a technical standpoint, there is zero downside whatsoever to always using the integrated GPU (the stance Ghostty takes) and plenty of upside.
Because _my_ computer has no battery. There is a plethora of computers out there with batteries who can run Linux, Windows, and macOS. These computers can, on paper, run Alacritty.
Cherry on top is me being a former user of a MBP 2010 who'd crash when using discrete GPU (it was _the_ reason Apple went with AMD later on). And some apps insisted on using it, even when I disabled it.
I like Rust applications but I don't like this response. The dev sounds worn out; whereas the dev of Ghostty seems to be a pleasure to deal with.
> - Ghostty sets non-focused rendering threads as QoS background to go onto E-cores
Assuming you're referring to Apple Silicon chips, how does Ghostty explicitly pin a thread to an E-core? IIRC there isn't an explicit way to do it, but I may be misremembering.
> - Ghostty slows down rendering significantly if the window is obscured completely (not visible)
About this. For whatever reason, I often end up with foreground windows (e.g. Chrome) covering the background window entirely, except for a sliver a few pixels wide.
Would Ghostty handle this case? I don't believe there's any point in full-speed rendering if less than a single line of text is shown, but the window isn't technically obscured completely.
But maybe to add a little bit of context, "damage tracking" means for example, that if there is any ongoing animation (like a spinner), then only a small part of the screen will be re-rendered (with proper vertex-time scissors, so only relevant pixels will be computed). I am not sure if it makes sense in the context of a terminal emulator, but it's certainly a big issue for any non-toy GUI toolkits.
GPUs are incredibly fast parallel computers, so you will likely not observe any perf difference (unless you need order-dependent transparency which you don't), but it might improve your battery life significantly.
No, damage tracking is important as it about reporting that you only updated that spinner, which means that your display server also knows to only redraw and repaint that area, and in turn that your GPU knows during scanout that only that area changed.
Without, even if you only redrew your spinner, your display server ends up having to redraw what might be a full screen 4k window, as well as every intersecting window above and below until an opaque surfaces are hit to stop blending.
Well it sounds like ghostty is like all the other major GPU terminal emulators (unless you know of a counterexample) and does full redraw, though it appears to have some optimizations about how often that occurs.
The power issue might be true in some cases, but even as foot’s own benchmarks against alacritty demonstrate, it’s hyperbolic to say it “kills performance”.
We do a full redraw but do damage tracking ("dirty tracking" for us) on the cell state so we only rebuild the GPU state that changed. The CPU time to rebuild a frame is way more expensive than the mostly non-existent GPU time to render a frame since our render pipeline is so cheap.
As I said in another thread, this ain't a AAA game. Shading a text grid is basically free on the GPU lol.
Perhaps that came across wrong, no shade intended, what was meant was that ghostty seems to be like all the other mature GPU based emulators. Which means there's no damage reporting to a display server or anything like that. I don't think it's quite the deal breaker the GGP implies.
It's actually not at all free, even if you're barely using the shading capacity. The issue is that you keep the power-hungry shader units on, whereas when truly idle their power is cut. Battery life is all about letting hardware turn off entirely.
Also, if you do damage tracking, make sure to report it to the display server so they can avoid doing more expensive work blending several sources together, and in case of certain GPUs and certain scanout modes, also more efficient scanout. Depending on your choice of APIs, that would be something like eglSwapBuffersWithDamage, wl_surface_damage_buffer, and so forth.
> The issue is that you keep the power-hungry shader units on, whereas when truly idle their power is cut.
Even in the most perverse scenario of a single cell update the load for a terminal is still bursty enough that it's not like the GPU doesn't enter some power saving states. Running intel_gpu_top in kytty with a 100ms update is at least suggestive, it never drops below 90% RC6 (even at 50ms, which is a completely uselessly fast update rate we're still in the high 80s). If you're updating faster than 100ms legitimately, it's probably video or animation that is updating a large percentage of the display area anyway. The overall time my terminal is doing some animation while on battery is low enough that in practice it just doesn't matter.
The problem you're up against is that, maybe if this was optimized most people would get 2 or 3 (or even 10) more minutes on a 12 hour battery life or something. No one really cares. Maybe they should, but they don't. And there's plenty of other suck in their power budget.
You make it sound like a binary power saving scenario, but it tends to be more nuanced in practice.
Most people run their terminal opaque, most display systems optimize this common case.
> Also, if you do damage tracking, make sure to report it to the display server
I'm not unsympathetic to your point of view. But I am skeptical that the power savings for most use cases ends up being much of a big deal in practice for most people (even accepting there may be some annoying edge cases that annoy some). I am interested in this topic, but I am still awaiting an example of a GPU accelerated terminal emulator that works this way to even make a real world comparison.
It is very nuanced, but it's important to realize how small the power budget is and how just tens of milliwatt here and there make a huge difference.
To get over 12 hours of battery life out of a 60 Wh battery - which isn't impressive nowadays with laptops rocking 20+ hours - you need to stay below 5 watts of battery draw on average, and considering that the machine will likely do some actual computation occasionally, you'll need to idle closer to 2-3 watts at the battery including the monitor and any conversion losses.
The really big gains in battery life are from cutting tens to hundreds of mW off things at the bottom by keeping hardware off and using fixed function hardware like e.g. avoiding rendering and doing direct scanout and using partial panel self refresh. Execution units do not turn on and off instantly so pinging them even briefly is bad, and the entire system needs to be aligned with the goal of only using them when necessary for them to stay off.
Efforts like libliftoff to do efficient plane offload to avoid render steps in the display server can save in the area of half a watt or more, but it's not a whole lot of help if applications don't do their part.
Bigger GPUs than your iGPU (or even just later iGPUs) will also likely see even bigger impacts, as their bigger shader units are likely much hungrier.
(As an aside, I am not a fan of kitty - they have really weird frame management and terrible recommendations on their wiki. Foot, alacritty or if ghostty turns out good, maybe even that would be better suggestions. Note that comparing to foot can give a wrong image, as CPU-based rendering pushes work to the display server and gives the illusion of being faster and more efficient than it really is.)
Well I would be very interested in some of this, but it all seems theoretical and mythical. Seriously, what terminal is giving 20% better battery life (or whatever number that people will notice) than kitty.
How can I observe any of these claims in practice?
You’ve put some down some bold claims about how things should be done but no way to verify or validate them at all.
Put up with some real power benchmarks or this is just crack pot.
> To get over 12 hours of battery life out of a 60 Wh battery - which isn't impressive nowadays with laptops rocking 20+ hours
I used 12 hours to be nice. The sell of getting another 10 minutes or so out of 20 hours is even more stark.
The cases where you push a line and scroll, you're repainting most of it anyway. The cases where you're not are end up being infrequent enough that optimizing them in the ways suggested makes an unnoticeable impact.
Build it and they will come maybe?
> Bigger GPUs than your iGPU (or even just later iGPUs) will also likely see even bigger impacts.
In most cases people can get by with an iGPU for a battery laptop cases. If you're in a must pull down more graphical power case, you're often plugged in and few care about 10s of milliwatts then.
> (As an aside, I am not a fan of kitty - they have really weird frame management and terrible recommendations on their wiki. Foot, alacritty or if ghostty turns out good, maybe even that would be better suggestions. Note that comparing to foot can give a wrong image, as CPU-based rendering pushes work to the display server and gives the illusion of being faster and more efficient than it really is.)
Once again, what is the exemplar of an efficient terminal then.
We've already established ghostty doesn't operate the way you think it should so how can it turn out good?
Shoutout to you sir for
Shouting out the other terminals. It’d be easy for someone of your fame and talent and history to ride the hype to the GOAT of all terminals. But you stayed humble. Props.
Alacritty on macOS and Linux user here (Windows Terminal on Windows due to easily different shells available, formerly used iTerm2 on macOS). I make up for lack of tabs with zellij locally (tmux remotely). Also allows me to relog or close/update Alacritty. I will give Ghostty a whirl but why no shout out to Alacritty? Which features am I missing out on?
Thanks. I'm interested in seeing examples (of Alacritty community not being nice). I'm aware of one now [1] but I have not been involved with the Alacritty community much. I read/write a few bug reports when the project was born; after that it has served me very well (compared to iTerm2 and Terminal.app). IIRC there was something with ligatures but I don't remember.
Thus far I have not been able to get my italic bold font (Cartograph CF) working on Ghostty, but this is a minor issue.
Yikes, that ramblerman who was all over that HN thread still posts today. The distance by which he missed the point is shocking. How does one get that far off without doing it deliberately?
I'm a fan of your work! I'm curious about how you decided to work on building a terminal for your next project among your other ideas. If you have time later, could you share your main motivation with us or link to an existing post if you already mentioned it elsewhere?
Just built this from source on Fedora and I have to say the experience even for building-from-source is flawless. Immediately replaced Kitty for me; it feels smoother and faster. Amazing work.
Just downloaded it because of the animation on the site. How did you make that? it's cute.
The terminal is good. I don't have any issues with the stock mac os terminal app but I'll give yours a go for a bit. I can't tell exactly how, but it does feel faster - I'm not sure exactly how it is but it looks like it renders text faster.
I haven't heard of Ghostty before today. I'm reading the docs; but what are the main selling points?
Personally, I've used Terminal.app (for a bit), iTerm (for a long while), Konsole (in the past, on Linux) and more recently I standardized on Alacritty (macOS) and Kitty (Linux). GPU acceleration puts it in the same general bin as my current toolchain, but your comment alludes to it pulling in some concepts from iTerm, possibly -- is that the case?
Looks great. Switching from wezterm and kitty before that, and the native feel on macOS is indeed better than those emulated tabs. Also it is really quite zero config where to me it seems only one line of color theme is needed, together with setting TERM for ssh. (Default font happens to be mine.) Bundling so much color theme felt a bit waste of space, but it is nice that I don’t need to define them myself which also makes switching theme tedious. I also love to see it lands at 1.0 where features, documentation, and promotional materials seem polished already.
Chances are, it will become my default terminal in 2025!
The only nitpicking is the doc does not seem to have a search function. It would be great if I can search color or ssh and find the relevant page address that immediately, without navigating the tree or relying on external search engines.
kitty has been my default for a few years now— highly superficial, but my designer side landed on kitty as it was one of the few that supports ligatures by default, specifically for the fira code font for my bias.
not only does it support them, but the default font provides them. although it splits the ligature in half if your cursor is in the middle of it which feels a little weird to me
How do you plan on sustaining the project? Do you have enough committers so you’ll not burn out? Will you need support? Is there a way to donate? I guess what I’m getting at is what is the long term sustainability work around this?
what was the motivation to start this project? it got so many points here, hence I assume there must be something really useful about it - but I so far fail to see it.
I'm not sure why they couldn't put that on the front page. Or at least on the front page of the documentation.
As it stands now, the front page is pretty useless if you never heard of ghostty. It's a ghost in a terminal? And there's tty in the name.... so is it a program to show ghosts in your terminal?
I'd never heard of it before today, so yeah, my first thought was exactly what you postulated. "Cool? Maybe it's a tool for generating animations in the terminal?"
*edit - oh, no Windows support for now (my hands are tied at work).
On mobile I thought this thing was some ascii art game for a hot minute before I tried clicking on the download link. Seems silly to admit that but there you have it.
Absolutely agree, even if it was just the tagline on the first page of the documentation - "Ghostty is a fast, feature-rich, and cross-platform terminal emulator that uses platform-native UI and GPU acceleration." - underneath the "screenshot" and above the buttons on the homepage.
Congrats on your 1.0 release! Building a term from scratch is no small task. And it looks like after 2 years you already have something I'm seriously considering switching to. That's seriously impressive. And though I'm mostly a Linux supremacist, I genuinely appreciate and respect your dedication to providing native applications on all major platforms. I see too many projects do one of two things: only support one platform at first, with some vague promise of doing others in the future left unfulfilled for years. Or going the easy route of using electron or some other cross-platform toolkit, getting cross-platform support at the cost of a significantly worse experience. There is no substitute for doing the extra work, at the end of the day, and you're already well on your way there at such an early point. Again, I'm impressed!
Now, the one thing I've coveted for years is a linux term with tmux control mode support, ever since I used iterm2 during my short tenure as a Mac user. I can see from your github issues that this is in the works(https://github.com/ghostty-org/ghostty/issues/1935), which is great. It looks like a lot of the necessary UI elements are already in place, as well as partial support for the control mode protocol. Do you have any idea how far off this is from being completed? I don't wanna make demands or anything, I know this is a passion project with lots of things still to work on. As far as I know(and I look around quite often) control mode support is still something no existing term for linux supports. Being the first could drive a lot of adoption! I'd also like to offer my help in pushing it over the goal line. I haven't touched Zig, but I'm a polyglot with plenty C experience and Im highly motivated to bring this feature to my Linux systems. Some guidance on things I might do to help would be welcome. The final 3 points of the checklist don't have much detail provided.
Again, no pressure, thanks for all your amazing work, and good luck with continued development!
Given the remote-first container-based world we're heading towards, decoupling UI (terminal emulator) from its "backend" (tmux, code-server) is a great design decision, which I think will ultimately define what the "next generation" of terminal emulators is. Imagine being able to open tabs directly on remote host, reconnect without losing state, etc, all while using native UI (so Cmd+T to open new tab, Cmd+F to search, etc). Productivity game changer, which currently only the iTerm2 users can fully enjoy.
Ptyxis (putting its backend in running containers), WezTerm (native handling of ssh sessions) and VSCode's terminal (starting a proprietary code-server binary and connecting to its TCP port) have reached some of this functionality, but in their design they need some out-of-band mechanisms to handle the connections, ultimately limiting the scenarios they can handle.
Meanwhile tmux -CC [0] and ht [1] are sending both their control channel and data channel over the opened terminal itself (in-band), making them flexible enough to support any configuration. Something complex like `ssh jumpbox -- ssh prod -- podman exec -it prod /bin/bash -- tmux -CC` should just work, as if everything was running on your local machine.
> Given the remote-first container-based world we're heading towards
You might want to expand on who "we" are here, because to me it seems to be a very small section of developers who want a "remote-first" experience and most (if not everyone) I speak with want software and tools that work local/offline-first, including our dear development environment.
If a tool requires a internet connection to work (so this "remote-first container-based world" you mention), I don't think either me nor many of the developers I know would even give it a try, because we need to be able to use our tools regardless if we have a working internet connection and/or the service-provider has downtime.
In fact, the only ones I know who are using a "remote-first" environment are developers who are forced to do so by their employer, and it's not a short-list of complaints about it when we meet over beers.
Not very small; most corporate non-Windows development uses containers, I'd bet on the ratio above 90%.
Not that developers want remote-first experience, but they face it. Containers in this regard behave like remote systems, even when run locally. A tool that helps juggle multiple remote contexts in a sane way may be very helpful. Say, tmux does a lot to help, but more is of course possible.
Calling it libTerminal might be confusing. There are other terminal emulation libraries—for example libvterm[1], notably used to power the embedded terminal in Neovim.[2]
How you've managed to communicate effectively with so many people who were using the beta version to craft the final release is beyond me!
I downloaded it last night, wrote one line of theme configuration (I picked the batman theme). and For me it just works fine and faster than any other terminal emulator I've ever worked with.
Also great with 'less' and 'tmux'.
I just switched to 'Ghostty'! so thank you.
718 comments
[ 2.1 ms ] story [ 548 ms ] threadhttps://gpanders.com/blog/ghostty-is-native-so-what/
I like where we're headed with tools like this and Ladybird[0] for hope of a subscriptionless future.
Thank you, Mitchell!
[0] https://ladybird.org/
That's a weird statement. I've been running a free, open-source and subscription-less browser (firefox) and terminal emulator (many) for close to 20 years.
Actually I like what ladybird is doing in the browser space, given firefox is quite dependent on google cash. But this is just yet another terminal emulator in a sea of them. The only two distinguishing features I can see are hype and native UI (which mac users care about for some reason -- my native UI is a borderless rectangle in tiling WM).
> On macOS, the GUI is written in Swift and uses AppKit and SwiftUI.
(https://ghostty.org/docs/about#native)
After testing Ghostty out for a while, though, I've realized that input lag is higher than xfce4-terminal, font rendering is blurrier with equivalent settings, the UI is still less consistent with my desktop, and it has three to four times the memory footprint on top of all that. Since xfce4-terminal is already using native GTK, so there's nothing gained on that front.
Disabling the UI cruft just turns it into a less performant version of Xterm, so unfortunately, this is going to be an uninstall for me.
Ah, so this is a macos thing and not just Safari. Can anyone help me select a tab using a keyboard? I use the shortcut, type in the search box and...have to use the mouse :(
I wrote the comment in a rush last night and I think it sounds like I'm dumping on ghostty. That is not my intention, it looks very well made and a true passion project which I have lot of respect for.
I just took issue with GP adding yet more hype to this.
That feels like an exaggregation. L High quality open source software is uploaded daily to GitHub.
https://mitchellh.com/ghostty
$ cd ghostty
$ zig build -Doptimize=ReleaseFast
$ ./zig-out/bin/ghostty
https://github.com/ghostty-org/ghostty/blob/4b4d4062dfed7b37...
The full script is pretty much:
$ wget https://ziglang.org/download/0.13.0/zig-linux-x86_64-0.13.0....
$ tar xvf zig-linux-x86_64-0.13.0.tar.xz
$ git clone git@github.com:ghostty-org/ghostty.git
$ cd ghostty
$ ../zig-linux-x86_64-0.13.0/zig build -Doptimize=ReleaseFast
$ ./zig-out/bin/ghostty
I'm quite surprised they don't provide a .deb package as that checks off 90% of Linux users.
Perhaps if one was inclined, Nix can provide immediate resolution, since it can be installed and used on Debian and ghostty project provides convenient flake.
Granted I'm on NixOS, but took me grand total of 60 seconds to update config and 8 minutes of actually building on a slow machine.
https://mentors.debian.net/intro-maintainers/ https://bugs.debian.org/995670
I've grown so sick of tools/TUIs that output unreadable text (like Debian's ls that defaults to dark-blue-on-black for directories). I look forward to never manually theming a terminal app again!
https://github.com/ghostty-org/ghostty/security/advisories/G...
It's also some very well-written Zig code. We use some of the code for graphemes in Bun for `Bun.stringWidth`.
Nicely done.
During the beta I had it configured like this on macOS:
There isn't an option to set the default height of the "quick terminal" window that I'm aware of but you can drag the bottom of the window after it opens and it will persist between toggles.Desktop equivalent is that you have a terminal available at a short-cut/button-press that will always show it but not fully hide the rest, no matter what other context you're in. Pretty handy.
I cant be the only person who uses Quake-style terminals at fullscreen. The second part of your sentence is the crucial bit: the ability to instantly conjure a persistent terminal regardless of whatever else I have on screen.
What I find annoying with my workflow (linux) is that starting a terminal and shell takes a lot of time. I wonder if it's possible to have a terminal always loaded so that my keybinding for creating a terminal would actually: move terminal in current workspace, focus it, then spawn another invisible terminal in the background.
So the idea would be that you start tmux somehow/somewhere, then in your new shell you can do `tmux attach` to get into that session from anywhere, and if you close this new shell, you can still do `tmux attach` to get back to where you were.
Use rxvt-unicode or another terminal that has a client/server mode. Start up a server in the background on boot or login (e.g. as a systemd user service), and make your keybind launch a new client process. Should be pretty much instant.
I am a single massive monitor kind of person. Quake-style terminal + all apps in maximized window + multiple desktops (with a shortcut to switch between them) is so good. Pull up the same terminal no matter which desktop you are on.
On macOS, pressing ⌘+comma with Ghostty in focus opens the config file.
Quit and reopen Ghostty to load the updated config (or bind another key to the reload_config action: https://ghostty.org/docs/config/keybind/reference#reload_con... ).
Keybinds are explained here: https://ghostty.org/docs/config/reference#keybind
Thank you!
Imma try out ghostty, WezTerm, and Rio thanks to this thread. And why not use them all. For terminal minded folks we are surely spoiled.
Ghostty is nice. Haven’t had much time with WezTerm.
It may not work for you, of course.
In yakuake they have to register the Open/Retract shortcut with KGlobalAccel [1] and I don't think global shortcuts are implemented otherwise
[1] https://github.com/KDE/yakuake/blob/164d24b8bad1175199260c62...
At the same time, Yakuake seems to be in maintenance mode, and you should be happy when it works with new KDE versions.
Currently I am using Wezterm and iTerm2 for the quake style terminal, but using two different terminals is quite annoying. I really miss Visor and TotalTerminal.
That seems to work for me (macOS 15.2 here)
Also, why cmd+space? That's the MacOS spotlight search binding.
You could try another keybind:
https://ghostty.org/docs/config/reference#keybind
Also be sure to quit and reopen Ghostty or use the reload configuration option from the Ghostty menu.
Setting the initial height of the quick terminal is under development: https://github.com/ghostty-org/ghostty/issues/2384
Lack of tab support in the quick terminal is a bummer, but it should come eventually: https://github.com/ghostty-org/ghostty/issues/2329#issuecomm...
For now, splits are the way to go in the quick terminal.
edit: alas, it doesn't support bitmap fonts..
It doesn't, especially on average DPI monitors. Oh, you mean the OTF trick.
Very disappointing. Not sure why people are trying to kill off bitmap support in everything these days. Will stick with foot.
I've noted before in issues I'm open to supporting bitmap fonts if someone contributes it, but not interested in adding it myself. The workaround above is very good.
It seems fast and really nice otherwise, so I'll keep fiddling with it, but so far I still prefer, for example, the "non-fancy" tabs in WezTerm (where the tabs are just rendered as line of terminal cells at the top or bottom of the window rather than GUI elements), and the way that modals ("Really quit WezTerm?" etc.) are also rendered within the terminal.
I'd also struggle to live without quick select mode[0].
[0] https://wezfurlong.org/wezterm/quickselect.html
I'm not going to learn more configuration languages or type 30 characters (or paste them from the browser) to toggle a binary setting.
As a DSL, it's key-value pairs. It doesn't get much simpler than that.
Also, having an explorable and searchable UI doesn't mean it's not saved in the same shareable and readable file.
No one is confused as to how the ghostty config works. Key value pairs. Sure. A window full of GUI controls and system color pickers can create that config file, or I can manually by hand. I’d prefer the former.
Uninstalled it right away, I'll keep using the default MacOS Terminal app.
Finally, somewhere else in this thread someone linked a web tool that will generate the settings if you absolutely can't look up the couple you need to change.
I believe window state recovery has some approximate equivalent in GNOME and KDE, but maybe not exactly the same (and I don't know how easy it is to integrate with).
There's an ongoing standardization effort to provide equivalent functionality for Wayland: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/m...
KDE Plasma provides a "fake session restore" for the time being: https://invent.kde.org/plasma/plasma-workspace/-/merge_reque...
Together with Bun I believe that is two high profile open source software made with Zig.
[1] https://news.ycombinator.com/item?id=1175901
- created by Mitchell (founder of HashiCorp)
- it’s developed in Zig (and Mitchell recently pledge $300k to Zig foundation)
- uses native UI (which is super rare for cross platform app)
- amazingly performant. e.g. https://hachyderm.io/@mitchellh/111919642467789362
- has lots of amazing small details like below
https://hachyderm.io/@mitchellh/113330304084905500
https://hachyderm.io/@mitchellh/113443002518588524
https://hachyderm.io/@mitchellh/113166930440000852
This has been a passion project of his for the past 2-years and he’s completely MIT open sourced it. He’s spent a lot of time thinking and ensuring this project can persist in the future even without him.
Many people have tremendous respect for Mitchell’s technical abilities, as well as hugely respect how he operates (genuinely nice person and thinks about things long-term and does the hard work for sustainability).
Lots more to read at: https://mitchellh.com/writing/ghostty-is-coming
Also, I've been using terminals since DOS in 1990 and never once have I had to say, "I wish this terminal had more performance", so I'm not sure that performance is really relevant here. If I write a command to build my project which takes 10 mins to build, does it matter whether the terminal command ran in 10 milliseconds vs 1 millisecond?
In the linked speed demo one command was 8 milliseconds faster than another. Ok?
Is a terminal written in Zig better than one made in C++ or Rust? Again, unsure why its relavant at all.
Linux and macOS are different platforms. Would calling it multi-platform make you happier?
> Also, I've been using terminals since DOS in 1990 and never once have I had to say, "I wish this terminal had more performance",
I remember the Windows terminal being unbearably slow in the past and wishing it had better performance.
Maybe this just isn’t for you.
[1] https://danluu.com/term-latency/
For day to day, ls'ing files that speed up won't matter too much. It is when you are tailing logs or working with multi-gig files that it matters.
[0] But that one is still Linux.
Our pony tails are long, grey, and maybe metaphorical.
Even more, I can have split logic based on window size, window titles that show me who also checked out a file while I am inside an editor, even per-window color and font schemes.
All apps should use something like Lua for their config.
Anyway, this is the reason I love the new wave of terminals, they bring new stuff on the table and anyone can find one they love. I just installed Ghostty and it works as I expect out of the box, with even less config (0) than I have on iTerm. And it's fast. Now I just hope they'll add a config UI some day (one of the reasons I prefer static config files: you can't really get a UI with a programming language) and I'll be in terminal heaven
The way this works in Wezterm is you can add regexes that match text in the terminal and format that text as links. So, I turn #(\d+) into "GITHUB_PR:$1" and then add a "on link clicked" callback to handle that special URL form by shelling out to `gh pr view --web $1` in the same working directory as the clicked pane.
Lua is also simple enough that if you want to have a static config, you can have a single table that is very json-like.
Insanely good ;)
Being able to quickly script minor functionality into my terminal emulator is my favorite thing about WezTerm
A terminal is so dear to us software engineers, and this seems like such a love declaration to the terminal.
Time to spend hours tuning my config!
Ghostty got a lot of hype (I cover this in my reflection below), but I want to make sure I call out that there is a good group of EXCELLENT terminals out there, and I'm not claiming Ghostty is strictly better than any of them. Ghostty has different design goals and tradeoffs and if it's right for you great, but if not, you have so many good choices.
Shout out to Kitty, WezTerm, Foot in particular. iTerm2 gets some hate for being relatively slow but nothing comes close to touching it in terms of feature count. Rio is a super cool newer terminal, too. The world of terminals is great.
I’ve posted a personal reflection here, which has a bit more history on why I started this, what’s next, and some of the takeaways from the past two years. https://mitchellh.com/writing/ghostty-1-0-reflection
I know everyone will say but tmux and/or native multiplexing bla, but I'm kind of old school and only do screen remotely if needed, and I just like a lot of terminal tabs in my workflow with a quick mod left/right arrow to navigate between (and if native multiplexing in Ghostty is simple and easy I'd probably do some of that too). Perhaps this is why I've never left iterm2.
See https://wezfurlong.org/wezterm/config/lua/keyassignment/Spaw... for a starting point in the config.
For example, I can select a tab in Ghostty, pull it out into its own window, and then stick it into another window. This doesn't work in WezTerm, nor can you drag them around to rearrange them (keyboard shortcuts allow this however).
Maybe it does not matter, the difference in functionality should count. Just highlighting that this messaging might not be understandable for linux users. I guess you are talking about some macOS thingie that's irrelevant to us.
AppKit/SwiftUI on macOS and GTK/Qt on Linux.
Looking forward to checking out Ghostty.
I agree with the philosophy of no tabs, but I simultaneously live in an intermediate desktop environment situation where I don't have access to the "right" solution yet. So I'm happy to have terminal emulator tabs, browser tabs and IDE tabs for lack of a more integrated solution.
WezTerm has tabs but they're not native UI elements.
WezTerm shines in ease and breadth of configurability due to using lua, so it's simple to have the theme change between light/dark depending on host OS theme.
As a wezterm user I’ll admit that configuring it was mildly annoying to start, but ended up feeling like an accomplishment. A few years in, it’s just another annoying program I have to re-remember how to use when i update twice a year.
Konsole also has easy resizing of text and supports images in the console, you might like it.
Then as a ritual (and a bit of OCD), I quickly cycle through all the tabs with Shift-Right Arrow once.
The obvious `set -g prefix jj` throws an error that the key j is a bad key. Various experimenting with bind and unbind have not resulted in success, and I can't seem to find an example .tmux.conf with that config to copy.
I thought I needed search but as Mitchell put it, not a 1.0 feature. Ripgrep was always the answer.
Very happy to share the ghostty experience with the world!
[1]: https://changelog.com/podcast/622
I’ve been a very happy iTerm2 user and support the dev on GitHub Sponsors (and I’ll continue to do that), but I love your commitment to making a fast, native app (and cross platform, no less) and really appreciate this very obvious labor of love that has also been really interesting to watch from afar as the development has progressed!
I'm just having a bit of fun, but it is a fun terminal every once in a while. https://github.com/Swordfish90/cool-retro-term
https://github.com/m-ahdal/ghostty-shaders/blob/main/crt.gls...
For anyone else curious about how to configure these, check out the docs: https://ghostty.org/docs/config/reference#custom-shader
If anyone cares to search through Github, they will see loads and loads of Issues and PRs created by Mitchell in many of the related Open Source projects that Ghostty uses/references. From zig to kitty to supporting libraries, Mitchell has been trying to get the terminal community working together and have some sort of standards. A lot of them are like "X does this, Y does that, why are you doing it this way? Can we all do it this way?" and then having Ghostty follow the most reasonable solution (or supporting several!).
Missing damage tracking, always painting everything (even when the window is a full 4k monitor), etc. kills performance and input latency when dealing with realistic redraw workloads like text editing, blinking cursors and progress bars. Much too often to terminals worry only about the performance of `cat /dev/urandom`...
[1] https://www.youtube.com/watch?v=cPaGkEesw20&t=3015s
And battery.
I gave up on alacritty because it was always using the dedicated graphics card of my MacBook and there was no reasonably way to use the integrated graphics card because it was “low performance”.
- Ghostty picks your integrated GPU over dedicated/external
- Ghostty sets non-focused rendering threads as QoS background to go onto E-cores
- Ghostty slows down rendering significantly if the window is obscured completely (not visible)
No idea if Alacritty does this, I'm not commenting about that. They might! I'm just talking from the Ghostty side.
Not sure on the current state of Alacritty, but a few years back the suggested solution for users interested in battery performance was to switch to a different terminal emulator: https://github.com/alacritty/alacritty/issues/3473#issuecomm...
The GPU requirements of a terminal are _minuscule_ even under heavy load. We're not building AAA games here, we're building a thing that draws a text grid. There is no integrated GPU on the planet that wouldn't be able to keep a terminal going at an associated monitor's refresh rate.
From a technical standpoint, there is zero downside whatsoever to always using the integrated GPU (the stance Ghostty takes) and plenty of upside.
I just find myself on the other side of the line for Alacritty.
Cherry on top is me being a former user of a MBP 2010 who'd crash when using discrete GPU (it was _the_ reason Apple went with AMD later on). And some apps insisted on using it, even when I disabled it.
I like Rust applications but I don't like this response. The dev sounds worn out; whereas the dev of Ghostty seems to be a pleasure to deal with.
Assuming you're referring to Apple Silicon chips, how does Ghostty explicitly pin a thread to an E-core? IIRC there isn't an explicit way to do it, but I may be misremembering.
About this. For whatever reason, I often end up with foreground windows (e.g. Chrome) covering the background window entirely, except for a sliver a few pixels wide.
Would Ghostty handle this case? I don't believe there's any point in full-speed rendering if less than a single line of text is shown, but the window isn't technically obscured completely.
Out of curiosity, what GPU accelerated terminal does this.
But maybe to add a little bit of context, "damage tracking" means for example, that if there is any ongoing animation (like a spinner), then only a small part of the screen will be re-rendered (with proper vertex-time scissors, so only relevant pixels will be computed). I am not sure if it makes sense in the context of a terminal emulator, but it's certainly a big issue for any non-toy GUI toolkits.
GPUs are incredibly fast parallel computers, so you will likely not observe any perf difference (unless you need order-dependent transparency which you don't), but it might improve your battery life significantly.
Without, even if you only redrew your spinner, your display server ends up having to redraw what might be a full screen 4k window, as well as every intersecting window above and below until an opaque surfaces are hit to stop blending.
The power issue might be true in some cases, but even as foot’s own benchmarks against alacritty demonstrate, it’s hyperbolic to say it “kills performance”.
As I said in another thread, this ain't a AAA game. Shading a text grid is basically free on the GPU lol.
Also, if you do damage tracking, make sure to report it to the display server so they can avoid doing more expensive work blending several sources together, and in case of certain GPUs and certain scanout modes, also more efficient scanout. Depending on your choice of APIs, that would be something like eglSwapBuffersWithDamage, wl_surface_damage_buffer, and so forth.
Even in the most perverse scenario of a single cell update the load for a terminal is still bursty enough that it's not like the GPU doesn't enter some power saving states. Running intel_gpu_top in kytty with a 100ms update is at least suggestive, it never drops below 90% RC6 (even at 50ms, which is a completely uselessly fast update rate we're still in the high 80s). If you're updating faster than 100ms legitimately, it's probably video or animation that is updating a large percentage of the display area anyway. The overall time my terminal is doing some animation while on battery is low enough that in practice it just doesn't matter.
https://en.wikipedia.org/wiki/Amdahl%27s_law
The problem you're up against is that, maybe if this was optimized most people would get 2 or 3 (or even 10) more minutes on a 12 hour battery life or something. No one really cares. Maybe they should, but they don't. And there's plenty of other suck in their power budget.
You make it sound like a binary power saving scenario, but it tends to be more nuanced in practice.
Most people run their terminal opaque, most display systems optimize this common case.
> Also, if you do damage tracking, make sure to report it to the display server
I'm not unsympathetic to your point of view. But I am skeptical that the power savings for most use cases ends up being much of a big deal in practice for most people (even accepting there may be some annoying edge cases that annoy some). I am interested in this topic, but I am still awaiting an example of a GPU accelerated terminal emulator that works this way to even make a real world comparison.
To get over 12 hours of battery life out of a 60 Wh battery - which isn't impressive nowadays with laptops rocking 20+ hours - you need to stay below 5 watts of battery draw on average, and considering that the machine will likely do some actual computation occasionally, you'll need to idle closer to 2-3 watts at the battery including the monitor and any conversion losses.
The really big gains in battery life are from cutting tens to hundreds of mW off things at the bottom by keeping hardware off and using fixed function hardware like e.g. avoiding rendering and doing direct scanout and using partial panel self refresh. Execution units do not turn on and off instantly so pinging them even briefly is bad, and the entire system needs to be aligned with the goal of only using them when necessary for them to stay off.
Efforts like libliftoff to do efficient plane offload to avoid render steps in the display server can save in the area of half a watt or more, but it's not a whole lot of help if applications don't do their part.
Bigger GPUs than your iGPU (or even just later iGPUs) will also likely see even bigger impacts, as their bigger shader units are likely much hungrier.
(As an aside, I am not a fan of kitty - they have really weird frame management and terrible recommendations on their wiki. Foot, alacritty or if ghostty turns out good, maybe even that would be better suggestions. Note that comparing to foot can give a wrong image, as CPU-based rendering pushes work to the display server and gives the illusion of being faster and more efficient than it really is.)
How can I observe any of these claims in practice? You’ve put some down some bold claims about how things should be done but no way to verify or validate them at all. Put up with some real power benchmarks or this is just crack pot.
> To get over 12 hours of battery life out of a 60 Wh battery - which isn't impressive nowadays with laptops rocking 20+ hours
I used 12 hours to be nice. The sell of getting another 10 minutes or so out of 20 hours is even more stark.
The cases where you push a line and scroll, you're repainting most of it anyway. The cases where you're not are end up being infrequent enough that optimizing them in the ways suggested makes an unnoticeable impact. Build it and they will come maybe?
> Bigger GPUs than your iGPU (or even just later iGPUs) will also likely see even bigger impacts.
In most cases people can get by with an iGPU for a battery laptop cases. If you're in a must pull down more graphical power case, you're often plugged in and few care about 10s of milliwatts then.
> (As an aside, I am not a fan of kitty - they have really weird frame management and terrible recommendations on their wiki. Foot, alacritty or if ghostty turns out good, maybe even that would be better suggestions. Note that comparing to foot can give a wrong image, as CPU-based rendering pushes work to the display server and gives the illusion of being faster and more efficient than it really is.)
Once again, what is the exemplar of an efficient terminal then. We've already established ghostty doesn't operate the way you think it should so how can it turn out good?
https://mitchellh.com/writing/ghostty-is-coming
Thus far I have not been able to get my italic bold font (Cartograph CF) working on Ghostty, but this is a minor issue.
[1] https://news.ycombinator.com/item?id=42532762
And then another where one of their maintainers had a meltdown and his fellow dev jumped in to protect him from... a bug report on the color green https://github.com/alacritty/alacritty/issues/1561
This was a few years ago so maybe they grew up since then.
Does it have a way to do tabs, and split terminal vertical and horizontal? Those are the only features keeping me on Terminator.
I've tried Tmux, but it isn't the same, so please commenters, avoid from the suggestion.
I was looking on the website to try and understand this more but couldn’t find any information. Perhaps I missed it?
> macOS
> Quick Terminal: Lightweight terminal that animates down below the menu bar for instant access without interrupting work.
The terminal is good. I don't have any issues with the stock mac os terminal app but I'll give yours a go for a bit. I can't tell exactly how, but it does feel faster - I'm not sure exactly how it is but it looks like it renders text faster.
Personally, I've used Terminal.app (for a bit), iTerm (for a long while), Konsole (in the past, on Linux) and more recently I standardized on Alacritty (macOS) and Kitty (Linux). GPU acceleration puts it in the same general bin as my current toolchain, but your comment alludes to it pulling in some concepts from iTerm, possibly -- is that the case?
I'm extremely excited to give Ghostty a whirl.
Chances are, it will become my default terminal in 2025!
The only nitpicking is the doc does not seem to have a search function. It would be great if I can search color or ssh and find the relevant page address that immediately, without navigating the tree or relying on external search engines.
kitty has been my default for a few years now— highly superficial, but my designer side landed on kitty as it was one of the few that supports ligatures by default, specifically for the fira code font for my bias.
does ghostty support ligatures?
“… exploring not-for-profit structures to help ensure the long-term sustainability of Ghostty.”
https://mitchellh.com/writing/ghostty-is-coming
https://ghostty.org/docs/about
Clear, friendly, modest, respectful and with the right balance of detail vs overview.
Congratulations on your launch.
As it stands now, the front page is pretty useless if you never heard of ghostty. It's a ghost in a terminal? And there's tty in the name.... so is it a program to show ghosts in your terminal?
*edit - oh, no Windows support for now (my hands are tied at work).
Now, the one thing I've coveted for years is a linux term with tmux control mode support, ever since I used iterm2 during my short tenure as a Mac user. I can see from your github issues that this is in the works(https://github.com/ghostty-org/ghostty/issues/1935), which is great. It looks like a lot of the necessary UI elements are already in place, as well as partial support for the control mode protocol. Do you have any idea how far off this is from being completed? I don't wanna make demands or anything, I know this is a passion project with lots of things still to work on. As far as I know(and I look around quite often) control mode support is still something no existing term for linux supports. Being the first could drive a lot of adoption! I'd also like to offer my help in pushing it over the goal line. I haven't touched Zig, but I'm a polyglot with plenty C experience and Im highly motivated to bring this feature to my Linux systems. Some guidance on things I might do to help would be welcome. The final 3 points of the checklist don't have much detail provided.
Again, no pressure, thanks for all your amazing work, and good luck with continued development!
Given the remote-first container-based world we're heading towards, decoupling UI (terminal emulator) from its "backend" (tmux, code-server) is a great design decision, which I think will ultimately define what the "next generation" of terminal emulators is. Imagine being able to open tabs directly on remote host, reconnect without losing state, etc, all while using native UI (so Cmd+T to open new tab, Cmd+F to search, etc). Productivity game changer, which currently only the iTerm2 users can fully enjoy.
Ptyxis (putting its backend in running containers), WezTerm (native handling of ssh sessions) and VSCode's terminal (starting a proprietary code-server binary and connecting to its TCP port) have reached some of this functionality, but in their design they need some out-of-band mechanisms to handle the connections, ultimately limiting the scenarios they can handle.
Meanwhile tmux -CC [0] and ht [1] are sending both their control channel and data channel over the opened terminal itself (in-band), making them flexible enough to support any configuration. Something complex like `ssh jumpbox -- ssh prod -- podman exec -it prod /bin/bash -- tmux -CC` should just work, as if everything was running on your local machine.
[0] https://github.com/tmux/tmux/wiki/Control-Mode
[1] https://github.com/andyk/ht
You might want to expand on who "we" are here, because to me it seems to be a very small section of developers who want a "remote-first" experience and most (if not everyone) I speak with want software and tools that work local/offline-first, including our dear development environment.
If a tool requires a internet connection to work (so this "remote-first container-based world" you mention), I don't think either me nor many of the developers I know would even give it a try, because we need to be able to use our tools regardless if we have a working internet connection and/or the service-provider has downtime.
In fact, the only ones I know who are using a "remote-first" environment are developers who are forced to do so by their employer, and it's not a short-list of complaints about it when we meet over beers.
- Connecting from Windows/macOS host to a local VM
- Connecting to a build server over LAN (I have a beefy PC but prefer to work from my couch)
Both work offline just fine, but from tooling perspective you are connecting to remote host over the network
Not that developers want remote-first experience, but they face it. Containers in this regard behave like remote systems, even when run locally. A tool that helps juggle multiple remote contexts in a sane way may be very helpful. Say, tmux does a lot to help, but more is of course possible.
Congrats for the release and happy new year.
On the cross-platform library, I wonder why "libGhostty" and not libTerminal. Which seems like a more appropriate in term of library?
[1] https://www.leonerd.org.uk/code/libvterm/
[2] https://neovim.io/doc/user/terminal.html
Ghostty 1.0 Is Coming - https://news.ycombinator.com/item?id=41914025 - Oct 2024 (32 comments)
Ghostty Devlog 004 - https://news.ycombinator.com/item?id=37709113 - Sept 2023 (2 comments)
Talk: Ghostty and Some Useful Zig Patterns - https://news.ycombinator.com/item?id=37491031 - Sept 2023 (2 comments)
Mitchell Hashimoto's Ghostty Devlog - https://news.ycombinator.com/item?id=36736686 - July 2023 (1 comment)