Ghostty 1.2.0 - Release Notes
145 points by watbe
145 points by watbe
The SSH Improvements bring me joy. I do not enjoy having to fix the xterm to use backspace lol.
To be fair it’s a (nice) ugly hack. The proper fix is adding the terminfo.
I disagree. I’m not shipping embedded Linux devices to customers with Ghostty terminfo just because it’s useful whenever I need to SSH into one of them. Nor will I install Ghostty terminfo to production servers just because it’d avoid the slight annoyance of having to run TERM=xterm ssh ....
I don’t mind installing the terminfo on most of my servers. For the ones where I do mind, having SetEnv TERM=xterm in ~/.ssh/config is a very slight amount of work to avoid that slight annoyance.
most of my servers
That’s the thing: I’m not just talking about my servers. Would you install Ghostty terminfo on servers managed by a team of people at a company, where you’re the only Ghostty user at that company?
In most cases, yes. We don’t use shared user accounts, so my home directory doesn’t impact other users, and I have tic write into $HOME/.terminfo.
But like I said, for the other cases, I’m absolutely happy to have SetEnv TERM=xterm in my workstation’s ~/.ssh/config.
Since ghostty’s terminfo is in upstream ncurses, as that gets picked up, this is becoming moot even for embedded things. But I’m happy with either ~/.terminfo or xterm emulation + an environment variable to communicate that until then.
Finally I can stop doing things like this: TERM=xterm ssh -i id_rsa.pem root@192.168.122.236
Mitchellh and team, thank you for doing solid engineering work. It’s weird to enjoy reading detailed release notes but in an era where everything has been overmarketed to made up personas divorced from users on the ground, it’s a breath of fresh air to read a long list of interesting technical changes.
Reading these release notes is like my open source Bob Ross relaxation.
Bob Ross is such a good way to put it. My other favorite release notes are Bevy’s and I’m not even a game dev: https://bevy.org/news/bevy-0-16/
Woah, very nice to see cursor shaders!
Now it needs to do partial rendering / damage tracking (when no effects are applied) to be as efficient as VTE :)
Also would be great to see container-awareness (like Ptyxis) finally happen…
On the CPU side of things, we already do damage tracking (we call it “dirty” internally) so that only changed cells are updated. We track this by row and not by individual cell as an efficiency tradeoff, plus that granularity typically makes sense because text runs for font shaping happen at a row level.
On the GPU side, we always redraw the full frame buffer for any change. But this isn’t any kind of bottleneck. Our GPU data transfer and frame draw times are on the order of microseconds so it isn’t a place we should be directing any sort of optimization work. The CPU data update is where all the time is spent and we already have the damage tracking there, as noted.
The renderer also only issues a GPU command when there are changes or the underlying GUI framework requests it for whatever reason. And on both platforms, we only issue a GPU command at most once every vsync by default (can be disabled if you want). So even if there is a flurry of rapid screen changes, it gets coalesced into a single update + GPU call.
On macOS, we also adhere to “Adaptive Sync” requests (basically: variable refresh rates) so when macOS’s power scheduler decides to down clock us, we respect that. On macOS, we also stop rendering completely when the window is fully obscured (i.e. covered by something so it isn’t visible). In that regards, we should be more efficient than even pure CPU renderers because I haven’t seen any pure CPU renderers do this (though, they certainly could!). GTK doesn’t give us this information so that is macOS only. Same with variable refresh rates.
So perhaps I’m misunderstanding something, but is there something specific I’m missing with regards to this topic that makes us less efficient? I’m not asking this in any sort of defensive way, I’m genuinely curious and want to improve our rendering stack.
On the GPU side, we always redraw the full frame buffer for any change. But this isn’t any kind of bottleneck
It’s not a performance bottleneck, but rather it’s a waste of energy that can affect battery life. Powering up the GPU and doing memory transfers (twice, because both app and compositor need to render, unless the latter happens to do hardware plane offload for your window/subsurface) for the entire area of a full screen HiDPI window vs. only for a tiny rectangle on every update really does add up! According to Mozilla Gfx team,
A screen worth of pixels takes up around 28MB at the default scaled retina resolution (1680×1050@2x). This is usually too big for the L3 cache [..] We believe that the GPU runs at full frequency while it waits for memory. So you can estimate the power usage by checking how long the GPU runs each frame.
(Due to that article I’ve contributed EGL integration for both reporting damage to the compositor (EGL_KHR_swap_buffers_with_damage) and reusing previous buffer contents internally (EGL_EXT_buffer_age) to Firefox.)
I do expect the difference to be slightly less dramatic on a simple terminal vs. a web browser, and the latest GPUs might sip a bit less power than 2019 era Intel iGPUs when just waiting for memory, but it is still wasteful to rerender big unchanged areas.
P.S. to visually see the damage reported to the compositor in GNOME: Alt+F2, lg, Enter, “Flags”, PAINT_DAMAGE_REGION. You can see how optimized Firefox and GTK (and VTE) are.
Thanks! That’s helpful.
But note we still only draw when there’s actually a frame to draw. So if you’re, for example, sitting in a Neovim buffer, we’re only drawing one frame whenever text changes or you move your cursor, unless you have some part of the screen that is constantly animating, but I haven’t found that to be the norm.
Similar logic for when you’re sitting on a shell. Maybe you have a flashing cursor, but that’s still only ~2 frames per second. And a lot of people in terminals don’t use flashing cursors.
So, I think the power draw here would be almost nothing compared to something like a web browser where change is a lot more frequent. Still, your comments are helpful and I’ll take a look!
GTK doesn’t give us this information so that is macOS only.
I thought that gtk_widget_add_tick_callback is supposed to slow down / suspend on Wayland for occluded windows.
That’s correct - the wayland next frame callbacks are only dispatched when the compositor decides to, the wayland book bit on this mentions that obscured/offscreen applications can have their frame tick hints throttled. it’s just something that ghostty shouldn’t have to consider on their implementation.
Okay neat. We use a GtkGlArea and render on the render signal. I wonder if we get this for free in that case then on Wayland. It’d make sense for gtk to ALWAYS do this for the Gl widget but I’ve never actually tested to verify.
(On macOS we don’t actually use a MtlView but setup our own display link render loop so we have to manage it all ourselves)
The undo/redo is magical. Just tried it. On MacOs feels like dark sorcery to close a window/tab and then instantly bring it back with Cmd+Z. Immediately tried it with a few other apps (eg vscode) and none supported even tab close undo.
The built in rendering for circle segments is interesting, but limited. The rendering of twelfth circle segments from New Unicode Symbols for Legacy Computing Supplement is disappointing because they are designed for 1:1 character aspect ratio and are thus are only useful for making ovals of specific size on normal terminals. Just spitballing here, it would be cool if 2 or more of the same circle segments could be combined to form an arc of the same degree across the two characters.
PS. Mitchell’s tweet about the customer renderer is what inspired me to make the ASCII moon. It didn’t end up using the new characters, but it still looks great in Ghostty via curl.
I think you meant to link to https://ghostty.org/docs/install/release-notes/1-2-0#macos:-undoredo-close for your first link.
config: env can be used to specify environment variables to set in the terminal environment.
This is such an underrated feature for macOS which by itself does not allow setting environment variables on startup. It should make configuring nushell a breeze now. Thanks!
Though I haven’t tested it in a long time, I believe you want ~/.MacOSX/environment.plist.
It does not work reliably when ghostty is configured to open on startup, because in that case launchd may execute those instructions after ghostty has started. On the other hand, setting up those variables in the ghostty config ensures they are set before any shell initiation.
I tried it and wrote about it.
I deleted it again.
It does not follow the CUA UI standards – for instance, there’s no menu bar, and it doesn’t understand standard keystrokes – and frankly I don’t care about the performance of my terminal emulator. It’s much more important to me that my terminal emulator integrates well with my desktop (say, Unity or Xfce) than if it’s fast or not. Terminals are faster than GUIs anyway. If I’m in the terminal then it’s quick enough, so the UI matters 10x more than the performance to me.
Thanks, no problem, that’s the beauty of choice and the rich ecosystem of terminals that exist. :)
for instance, there’s no menu bar
We do set a menu bar on both macOS and GTK. Just note that modern Gnome styling usually hides it in a hamburger menu in the titlebar. This is the desired look of Gnome HIG adherent programs (and GTK in general). You can force a menubar with GTK but it is not idiomatic and would not match officially distributed Gnome applications. If this is a dealbreaker for you then I think other terminals are a great option!
macOS has a standard menu bar as expected.
it doesn’t understand standard keystrokes
Could you elaborate which ones we’re missing? We do our best to match standard keystrokes on both platforms by default and would love to know where we’re falling short.
Thank you!
Thanks very much for the reply! I am touched.
Yes, I noted the GNOME style. Unfortunately for me, I really do not like GNOME – it feels like using a phone interface to control a computer; it’s crippled, it’s like trying to type with 1 finger – so for me that’s not a win. That applies to all Gtk4 apps.
I can’t remember what didn’t work, but of course, standard keyboard navigation of menus does not work when there’s no menu bar. I presume GNOME developers and enthusiasts just don’t know how to navigate menus with their keyboards, so they don’t miss it.
I wrote about Ghostty 1.0 on The Register but the moderator will not allow me to link to it. You will have to Google it for yourself. Sorry – out of my hands.
Nice release!
A few nits:
I got caught by the theme name changes. It would be really nice if hitting the copy_to_clipboard shortcut from the theme browser would place the name of the selected theme on the clipboard. I went to the github discussion and said as much. Normally, I’d like to include a patch with such a comment, but the need for beta Xcode is too much ceremony for today. Fortunately, by looking at the source, I learned that hitting c in the theme browser would do the same job. And that I could have discovered that shortcut by hitting ? in the theme browser.
It was hard for me to figure out how to use the ssh-terminfo feature. A link to the documentation would have been very useful. Once I figured out that it was in the shell-integration-features section of the manual, it was easy to set up and worked very nicely against a remote machine where I hadn’t yet gotten around to fixing the terminfo myself.
In the aforementioned section of the manual, it doesn’t say what the default value is for any of the options.
The ssh-terminfo integration absolutely made my day, and everything else about the release has been really smooth. Thanks for all the work @mitchellh!
Still no search in scroll buffer, even though it’s the top requested feature, by a huge margin.
It’s mentioned in the Roadmap section of the release notes:
Ghostty 1.3 will continue the focus of making Ghostty the “best existing terminal emulator” by shipping the last remaining major missing features to achieve parity with other popular terminal emulators. Namely, we plan on shipping scrollback search and scrollbars for 1.3, at a minimum.
This is the one thing that frustrates me when using ghostty, everything else about it is my favourite terminal emulator :)
Funny. It took me a month of usage before I noticed that is missing (through liberal use of tmux and vim :terminal, both of which provide their own search). I agree it should be high priority though.
First macOS terminal gets support for 24bit colours and powerline fonts, now a new Ghostty release. Good day!
Ohh, quick terminal support for Wayland is awesome!! I can finally drop the terrible window rule hacks in my Sway config to get a similar feature :D
Really well written changelogs too, I haven’t seen may projects give this much care to their release notes. Amazing work all around!
Maybe one day I’ll be able to package Ghostty in Fedora :(
What’s holding this back?
Based on this issue it seems people just stopped working on it, along with there being some (sadly typical) pedantry surrounding packaging of dependencies.
I can assure you its still being worked on by other people but that specific effort stalled due to 0.14 being released in Fedora and now the same is gonna happen with 0.15
Kind of off-topic, but where can I find the wallpaper you used for the GTK screenshots, @mitchellh?
Edit: if anyone else is interested, it’s a painting by Alfred Sisley, Wiesen von Veneux-Nadon.
I very much do not like non-native software on my Mac, but Ghostty is so good that I make an exception. Thanks!
What is non-native about Ghostty? It’s a Swift written, AppKit/SwiftUI using, Xcode built Mac app. What more do you want? lol. (Again, not trying to be defensive, genuinely curious why it doesn’t cross the line for you)
The core of course is Zig but that’s no different from linking to a C lib. I think you mean the GUI, which has zero non native bits as far as I understand it to be defined.
I do appreciate you still using it though. ❤️
A text file for configuration.
Ah! That makes sense. That won’t be true for long. :) it’s been an accepted and planned roadmap item for quite awhile to have GUI config (in addition to text).
I know, and don’t think I don’t appreciate y’alls hard work. It is really good software, but I’m Weird Like That. My habits and muscle memory are too deeply ingrained.
This comment confuses me. Isn’t part of the reason for Ghostty to be a Mac native interface?
I have tried ghostty 3 times but the second I ssh into another mac the back spacing doesn’t work and I retreat back to MacOS’s default terminal. This release is the same but will be looking forward to the next! Everything else seems to work great but need that terminal emulation to work to make a switch.
The SSH Improvements should hopefully help with that, either by setting up the proper terminfo on the machine you’re connected to or dropping down to xterm compat. I’d give that a try and see if it fixes up the backspace issues.
Every time I hear about a new release, I give it another try—only to find that step resizing still doesn’t work. How do you all manage to use terminal windows with arbitrary padding all around?