Ghostty 1.3.0
98 points by BD103
98 points by BD103
SO happy to see this. "Scrollback search" was one of those no-brainer features that I saw a lot of people bounce off of Ghostty because of.
Also, I never realized how much I had normalized word-jumping shortcuts and never realized how much i wanted the click-to-move-cursor.
Very excited. Updated and enjoying immediately. Congrats to the Ghostty devs!
In addition to those, as a macOS user, AppleScript support and 'Split Drag and Drop' are unexpectedly handy QoL improvements! https://ghostty.org/docs/install/release-notes/1-3-0#split-drag-and-drop-(macos)
I loved scrollback search in kitty. Regularly used it for stepping through logfiles.
Moved to Ghostty because shiny new thing (plus the folks behind it) and this was my missing feature. Excited to try it on a massive buffer of content in the coming days :-)
At a time when many aspects of computing and the Internet are making me question if I still love what I used to love, there are a few projects keeping the flame allive. Ghostty is one of those.
Thank you Mitchell for not just creating an excellent application, but also for the way you're leading the project. It's inspring to see that you still love software and the potential of open source communities when you could easily be sitting on a beach with cocktails being delivered and never touching a computer again!
Previously the only way to differentiate between active and inactive panes was color dimming. Now 1.3.0 lets us write focus-aware custom shaders! Here's an example I adapted from one of the tickets to draw a rectangular selection around the active pane.
Of course, the rectangle is there even when there's only a single pane in the window. But it's pretty neat that this sort of customization is possible at all.
I really appreciate the human-written changelog. It was a pleasure to read!
I'm a Kitty user. Has anyone here tried both? I'd like to understand the differences. I feel good using Kitty, but I'm open to switching if it makes sense.
I hope others can chime in, but I did Kitty -> foot -> Ghostty. I moved to foot because I was playing around with Wayland and used tmux. I then just switched to Ghostty during the closed beta due to hype and I was moving to a Mac.
Performance from both Kitty and Ghostty is good and I don't think one is noticeably better than the other. I do use Ghostty for GLSL shaders for custom cursor trails, but I realized Kitty was actually the first one to implement cursor trails (It didn't exist when I moved away). One thing I liked was also color scheme switching based on system theme, but it looks like Kitty also has it too (Also didn't exist when I moved away).
My OOTB experience with Ghostty was better and I think fonts look semi-better, though I'm unsure and not an expert. I think Kitty has more features, but I didn't take advantage of most of them.
I really prefer Ghostty's native elements. Kitty's tabs were always an eyesore to me. I know they are configurable, but the GTK tabs feel much better and fit in with the rest of the desktop. Ghostty also provides native looking client side decorations. As for actual terminal functionality, not just looks, they are pretty similar.
Kitty > ghostty simply because I can click on a terminal URL and open it in vim, it is an incredible feature that I use constantly
I am trying to understand what I am missing out on with just using the terminal emulator my desktop environment of choice comes with: xfceterm
People mention speed, but don't really understand. What would I need to do to experience the terminal emulator being the bottleneck?
So power users of ghostty can you enlighten me?
cat a very long file and see it not take seconds ;)
More seriously, there seem to people for whom this is a big thing and for most people (including me) it's just not.
If you never thought: man, this terminal I am using is slow - then you won't notice a difference.
I'm using it on my work mac only but I also wouldn't call it revolutionary - I use xfce4-terminal on some linux boxes and I don't have a problem with it. If I would value uniformity I guess the cross-platform aspect would be nice, but for me it's just a nice mac terminal that's a bit better than the built-in and WezTerm. (or at least has better defaults)
Honestly the biggest pros to ghostty are not speed, foot is faster. The benefits are correctly handling Unicode and modern terminal features like images
Mitchell talks about this a bunch but the “real” ghostty is libghostty, the terminal app is just a really impressive reference implementation.
For me the most important feature are images. I depend a lot on them with pi. When the agent makes a screenshot I can see it right away.
I'm curious too. Ghostty takes a good ~5 seconds to cold start on my machine which is kind of rough for a terminal.
I'm no power user, but with that said: when people talk about Ghostty being "fast", they're mostly talking about the latency between pressing a key and seeing a character appear on the screen. See here for more discussion on that: https://danluu.com/input-lag/ and https://danluu.com/term-latency/
Congratulations on the release! From the pre-release blogposts to the release notes, the communication from the this project is a great example on how to do communication, which is imo a hard thing to do!
And I don't use Ghostty just yet, every time I try it, the lack of scripting or programmatic access kind of limits me, but AppleScript looks like a fun rabbit hole.
I wonder, just out of curiosity, are there/have there been any musings on what the terminal could look like in the future from a Ghostty perspective? E.g. the scroll back buffer being a text buffer or more easily/ergonomically pipe text around. So basically, would the Ghostty maintainers like to see a focus on text/data or on more elaborate OSC codes.
Praying that we'll eventually get https://github.com/ghostty-org/ghostty/discussions/8131 because that's something I can't live without (command + number to switch to a specific window and no, tabs are not an option.)
Not to sound dismissive, but I read the feature request there and it would seem like anyone with that problem (lots of windows, want to switch between them efficiently) would benefit tremendously by using a window manager that works for them - it's in the name. It seems like an odd responsibility for the application to handle how to switch between windows.
using a window manager that works for them
There's not an awful lot of choice on macOS when it comes to window managers.[0]
It seems like an odd responsibility for the application to handle how to switch between windows.
It's a convenience - Terminal, iTerm2, and Kitty all provide it; macOS provides a whole variety of ways to switch between windows within an application but not anything for "go directly to window 1". Probably never came up as a way to switch between application windows until they wanted to capture Linux refugees or something.
[0] Which is fine for me; I did decades in the X11 window manager mines and I have no desire to return.
I'm curious why tabs aren't an option?
Because they don't work the same way when you're going to a window without a direct command+[0-9] binding - for full windows, that'd be command-backtick to cycle through (a globally supported key binding for macOS); "next tab" doesn't really have a defined global binding that I'm aware of (but seems to be coalescing around ctrl-tab even though that's already taken by "Move to the next control when a text field is selected." in the official documentation.)
Add to that slight weirdness decades of muscle memory for moving between windows and tabs are just ... brain sludge that stops me getting anything done.
(Also just to clarify - I explicitly mean tabs aren't an option =for me in this situation=; I think most people can probably cope with them just fine.)
Has anyone developed a TUI against it? Is there a good guide for learning TUI development in general (with these new APIs)?
Note that Ghostty doesn't have any Ghostty-specific escape sequences at the moment. We have very rich (relative) support for all sorts of "modern" sequences like Kitty's keyboard and graphics protocol, ConEmu's progress bar sequence, systemd's context signaling protocol (https://uapi-group.org/specifications/specs/osc_context/), multiple Contour terminal extensions (https://contour-terminal.org/vt-extensions/), etc.
So, a Ghostty-specific TUI isn't really a thing. It's really more of a modern TUI app utilizing various other protocols we've adopted. Ghostty's goal is really to support as many of the most modern terminal sequences as possible (in addition to a good foundation of the legacy sequences, of course).
Do you feel the current graphics protocols are sufficient, or is there also a plan to eventually try improve on what's possible / easy to do?
Piggy-backing on this question: is anyone looking at doing proportionally-spaced fonts in a terminal? Not for everything, but just for text between a pair of control characters.
I spend a lot of time reading text from Claude Code in the terminal these days, and it'd be great for its paragraph-long responses to be set more nicely.
There are a few apps that seem to be using LibGhostty, but nothing much that interests me: