Ghostty 1.0(ghostty.org) |
Ghostty 1.0(ghostty.org) |
I've been using Kitty since just about the beginning and didn't know it did that!
Edit. Oh I see it's a really recent addition. I'll definitely be taking that for a spin.
A lot of people are claiming that ghostty is "faster." I watched the lightning talk where the author claims that catting files and binaries is faster.
I tried this against ghostty itself after building with zig build -Doptimize=ReleaseFast, using: time cat ghostty.
In GNOME terminal, it took 3.340s. In ghostty, it took 16.947s. I must be doing something wrong?
- "Seamless" cut & paste with paste on "2 X right click" + "Trim trailing LF"
- Quadruple click "Smart selection"
- Brillant search with highlighting in text and scrollbar
- Support for OSC-1 "icon titles" in tabs, as opposed to OSC-0 "header title"
Why choose a non-default anything? It feels like deeper down, you’re asking why anyone chooses anything.
These terminal emulators all behave slightly differently and have different strengths and weaknesses. Some are configurable. Some are programmable. Some feel “right”. Others can be made to feel “right”. Etc.
Why use any non-default application? Same answer for terminal emulators.
That's the point. Different browsers or word processors behave completely differently. They were asking what differences there are between this and other TEs.
[1] https://github.com/ghostty-org/ghostty/blob/main/TODO.md
Anyways this is a great piece of software. I've never been this hyped for a software ever before. Great work team.
The only thing I’m eagerly waiting for now is the implementation of search [1], but otherwise, it’s absolutely stellar.!
I set Ghostty as my default terminal emulator now.
I’ve been using Ghostty for a day now and it simply works. Smooth, seamless and perfectly integrated to the point where this should just be the default terminal in macOS.
P.S.: If you want to port your iterm color scheme, set:
window-colorspace = display-p3
for the colors to match.
(And bold-is-bright = true if you set this option in iterm)
i'd rather use a nice-looking and well designed (UX) terminal than have to use a clunky ai native one.
Every HN thread about it that I've seen has been full of comments that boil down to "this seems cool but I refuse to use a terminal emulator that's full of telemetry and requires sign-in."
And of course the VC-funded terminal emulator has AI shoehorned in now. I shouldn't be so surprised.
tldr: you're setting a low bar
Congrats on 1.0! It's been a joy to use I wish everyone can enjoy this wonderful piece of software as much as I have!
Given all the time and hype, I'd have hoped that wrinkles like this would've been ironed out by launch time.
Back to Wezterm for now, but I'll certainly be checking back in at some point.
I really appreciate the levelheadedness of your responses regarding Ghostty, and how clear you are to be speaking positively for your thing instead of negatively about anyone else's.
Going to build it at lunch today and give it a shot :)
There is a ghostty-git AUR repo for tracking the main branch: https://aur.archlinux.org/packages/ghostty-git
This is why I love HN. I had already installed from source, but this makes updating easier after all.
I did not realize it would be THAT much faster. I guess I should have started using better terminals earlier
The fact it does its own window decoration is a bit of a turn-off, but:
A quick test of speed against wezterm and gnome-terminal show ghostty (on my laptop) to be around 3 times faster than both of the other.
Will definitely try it for a couple of weeks.
also (from the docs):
> Ghostty supports the Kitty graphics protocol, light/dark mode notifications, hyperlinks, and more. This lets terminal applications like Neovim, Zellij, and others do more than they could in other terminal emulators.
Application features are higher-level features that are useful for interacting with the terminal emulator itself. For example, Ghostty supports native tabs, splits, a drop-down terminal on macOS, theme switching on system dark/light mode, etc.
I've had zero issues with standard macos terminal ( once I realized how to speed up key repeat in system settings that is), so I assume I don't need this.
Switched from WezTerm which was working cross platform but not quite as good.
Both are low latency and written in Rust.
also how to set color\name to the particular tab?
gtk-adwaita = falseAny particular/strong reason for choosing Zig for this?
https://mitchellh.com/writing/ghostty-and-useful-zig-pattern...
Speed.
> error(gtk): unable to get current color scheme: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.portal.Desktop was not provided by any .service files
This Portal is something from flatpak btw, no other terminal depends on it.
This is likely some cancer from GTK that metastasized, anything using GTK has to lock it down tight to rely on the absolute minimum of "features".
- faster
- no AI bloat
- no telemetry
- no obnoxious warning banner if you run without admin access
- no VCs that will enshittify the app in a few years
- doesn't require an internet connection and an account to access motherfucking bash on your local machine
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!
I'm sorry what?
- 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
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
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
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.
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.
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.
- picture or gif is worth a thousand word
- it mentioned its cross-platform but I don't see support for Windows or Android - its better make it explicit it's only for macOS and Linux. Yesterday was looking for some nicer terminal on Android and was hoping ghostty could work.
- I like simple landing pages but this... is too simple and not much useful (only 2 buttons and ASCII image. Why even bother with such landing page and not just stick with github README?
- it doesn't provide me any fast information how to compares to different terminals and why I should switch from Warp
I like the product as well, however, I need to use it for a week to comment.
I am sold thanks to the author's authenticity, but if I had not seen this, I wouldn't know what I'm looking at. So I think it would be very helpful if there were more info on the landing page.
- Alacritty (https://github.com/jwilm/alacritty)
- waveterminal (https://github.com/wavetermdev/waveterm)
- Hyber (https://github.com/zeit/hyper)
- Kitty (https://github.com/kovidgoyal/kitty)
- Rio (https://github.com/raphamorim/rio)
- Tabby (https://github.com/Eugeny/tabby)
- Wezterm(https://github.com/wez/wezterm)
- Contour (https://contour-terminal.org)
- Extraterm (https://github.com/sedwards2009/extraterm)
- Warp (https://www.warp.dev/)
I didn't like that Warp is VC product as I don't like essential tool like a terminal in my workflow to be dependent on proprietary VC product.
https://terminaltrove.com/terminals/ghostty/
You can find all terminals for comparison below and also the list of terminals (including Ghostty)
If there are any other features you look for in a terminal not on the comparison table please let us know!
https://terminaltrove.com/categories/ (1)
Or any other category on the page? (2)
We can change (1) alphabetically if that is what you mean.
As a terminal emulator, running and building it from source in Wayland as a passive process that exists in the shell, while being a method of input-output system call management.
Having my terminal session available on a hotkey has become a critical part of my workflow
Doesn't have a binary for Windows so it's not "cross-platform" yet.
This motivation is pretty clearly stated in the article.
Some people use "fancy TUIs" (the famous editors vim and emacs surely count) and if you don't, feel free to ignore this new option.
The homepage is cool but on mobile it isn’t at all obvious this is software, let alone a terminal emulator. If this HN post didn’t already have like 1000 votes I probably wouldn’t have even bothered with testing the link. I would have said “cool ghost” and moved on with my day.
That being said, I am looking forward to trying this as an iterm2 replacement. Iterm2 has been my default terminal on Mac since forever… it was probably the first hit for “putty for mac” or something, and I probably installed it and never even considered trying something else. It’s always “just worked”.
https://news.ycombinator.com/newsguidelines.html
[1] https://hn.algolia.com/?dateRange=all&page=0&prefix=true&sor...
Edit: I just saw https://news.ycombinator.com/item?id=42519739, which means you already covered the point, but I'll leave this up pour encourager les autres.
(The first sentence in the docs page does explain what it is but if that's too much for you, it's all good.)
> Ghostty is a fast, feature-rich, and cross-platform terminal emulator that uses platform-native UI and GPU acceleration.
Now after reading it, the name makes so much sense as well. GhosTTY. My first thought was alternative to ghost.org or something.
I think you misunderstood the OP. The criticism was about the landing page, not the project.
And fwiw, it's not unwarranted. Putting the words "terminal emulator" somewhere on the page would make less people bounce off. You may be fine with them bouncing off, but still, I think it was meant as constructive criticism.
I'll admit, I almost didn't click past the animation either. I did, and the doc quickly answered "what is it?", but why not just put that sentence on the landing page? I don't get the unnecessary obscurity either.
I enjoy personal projects and if you're saying that this is your personal - all the best! Given high praise count it's likely very good.
> Documentation? Reading a manual for an unknown thing?
Well. Yes? Maybe I'm assuming too much, but I feel like the target audience here (terminal emulator 'enthusiasts') either know about this already or are totally willing to go over to the manual to read what it is. The very first section upon opening the documentation explains it succinctly: Ghostty is a fast, feature-rich, and cross-platform terminal emulator that uses platform-native UI and GPU acceleration.
I'll give it a spin later, looks interesting.
midjourney still has the same thing on their homepage and i dig it
quick-terminal-position=top quick-terminal-screen=main quick-terminal-autohide=false keybind=f9=toggle_quick_terminal
Edit: Joined the discord, turns out this feature is MacOS only :/
I found it confusing to look for a category among the unsorted boxes. It would help if they were sorted.
It works for https://www.midjourney.com/home and apparently this project too with its 1100+ upvotes.
It's especially not okay to be so rude on HN. "Please don't post shallow dismissals"
Not clicking on a documentation link on a technical project is the definition of a shallow dismissal in my opinion.
Meanwhile, dr_ketyn's comment was both rude and not constructive in the slightest (here's a tip: starting feedback with "I hate this" isn't constructive or kind).
There are people who have been watching this for a few months waiting for it to go 1.0 — and, at least on day 1, "if you know, you know."
You know how you could find out how long it's going to take? By clicking the button. It's free. It's easy. Hell, it would've taken you less time to click that single button and read the first sentence than it would have taken you to post this comment.
You didn't even bother to spend half a second actually opening the documentation page and then you come here complaining about how you don't know whats in the documentation. This is entirely a problem of your own creation. What gives?
I think the discussion here would be different if the tone was more moderated. Seems like you’re dying on a hill for the right to be abrasive without consequence.
A few things that keep me from switching to it full time:
- Missing search scrollback (cmd+f). This appears to be coming soon: https://github.com/ghostty-org/ghostty/issues/189
- More of a nitpick than anything, but the only way to disable cursor blinking is to disable shell integration. Unfortunately, this means taking away things like native scrolling and likely some other things I don't know about. I see there is a discussion here to possibly address this: https://github.com/ghostty-org/ghostty/discussions/2812
I feel like this would be a no-brainer switch for me once the above are addressed.
Ghostty feels like a Mac app like iTerm2 while being fast and having fewer features. Wezterm feels more like an app ported from Linux, but has a much richer config system and features like build-in multiplexing which means it's replaced tmux for me - while keeping all my tmux keybinds.
I can understand being frustrated about latency on older Macs — I used to run Alacritty for certain tasks on my Intel Macs for that reason. But on newer Macs like a new M4 Pro I’m back to 100% iTerm 2 again. I can’t fathom having latency problems with iTerm 2 on a new Mac you just unboxed.
With both Ghostty and iTerm2 now freely available, there's really no reason to use Terminal.app.
[1]: https://mitchellh.com/writing/grapheme-clusters-in-terminals
[2]: https://github.com/neovim/neovim/issues/26093
- “Kitty Keyboard Protocol” means that a TUI app can detect all keybindings. For example, if you install kkp.el in Emacs, then Emacs running in a terminal will pick up ctrl+shift keys, super keys, etc. on par with a GUI app. I believe NeoVim supports this out of the box now as well, so if you ever felt like binding Cmd+S to :w<cr> you now can. - “Kitty Graphics Protocol” means that I can let e.g. Matplotlib show images inside a terminal, even over SSH connections. If you’re annoyed at pop-up GUI windows, or struggling with viewing remote images often, this is a nice workaround. There are even attempts at making terminal PDF viewers (like termpdf.py); IMO that’s a game changer, even though the app itself is still in a “proof of concept” stage IMO. - Terminal splits. If you work a lot in a terminal, it’s nice to be able to full-screen a terminal and view many different shells or processes side-by-side. Last I checked, Terminal.app just doesn’t have this feature. Sure, you could use multiple windows or a multiplexer like tmux, but that comes with different trade-offs; for example, a native terminal offers smooth scrolling with a trackpad whereas tmux doesn’t. Personally, I use tmux remotely, but stopped using it locally. - I see a lot of people mention 24-bit colors as a main reason to not use Terminal.app. For me, I’m actually pretending that I have a 16-color terminal, because I’m tired of having to theme every command-line utility individually, I’d rather they all just respect my 16 chosen colors instead. The only exception is my editor, just because there are unfortunately few good 16-color themes these days, so I instead change my terminal program to be consistent with my editor theme and then let every other TUI utility believe the terminal only supports 16 colors to match.
Sure, if you're clicking tabs... A fairer comparison would be between the keyboard shortcut to switch windows in tmux and the native keyboard shortcut to switch tabs.
I tried using their toggle_visibility keybind but it's a bit wonky since it doesn't return focus back to another window when you toggle away.
- some visual artifacts with the gtk menu
- sometimes prompt got clear when openning 2nd / 3rd windows
- cant get keybinding quick toggle to work
You need a compositor. picom works.
For a proper "native i3 experience" I recommend setting gtk-titlebar=false and unbinding tab/pane management keybinds. I already have a window manager, I don't need a second one.
I also had to disable adwaita because when it's enabled closing a shell with ^D closes all open windows, sometimes it leaves an empty window instead.
> - xterm still feel faster to me.
lxterminal also launches 6 times faster, I guess on a slow laptop without a dedicated GPU these terminals are not the most efficient option.
The only things I miss are (1) right click to copy paste selection (akin to Putty), and (2) profiles (I work with different shells depending on my projects and use Profiles frequently on iTerm2)
I was hoping 1.0 would mean CMD+F search would work, but looks like that was pushed back to a later release unfortunately.
https://github.com/ghostty-org/ghostty/issues/189#issuecomme...
I installed on linux inside WSL, then launched it, and it looks/works great. Clipboard also works.
https://github.com/microsoft/wslg/issues/1008 https://github.com/microsoft/wslg/issues/633
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!
[0] e.g. `keybind = alt+f=esc:f`
[1] Which affects both option keys, sadly.
There's never a time when I wouldn't want this to work, may as well enable it everywhere.
Edit: It looks like I misunderstood what that setting in iTerm does. But hey if you do want left option to send Esc by itself, that's how to get it.
iTerm2 isn't instant either, but they feel about the same[0], although with iTerm2 the full screen Quake-mode (Quick Terminal equivalent) hides the MacOS menu bar, and Ghostty doesn't.
For my taste, I want a full screen terminal, with no menu bar, no delay, and no animations, which I can toggle with a global hotkey.
[0]: Actually, scratch that. I tested again, and iTerm2 opens more quickly.
https://ghostty.org/docs/config/reference#macos-non-native-f...
Unfortunately the "tabs not working in non-native fullscreen" thing is a dealbreaker for me, so I will be switching back to iTerm 2.
But Ghostty as a whole looks promising. I like zig, zig-objc, MIT license, libghostty, config via text file. I will check back every month or so because I really want to use this. But my hate for macOS native fullscreen outweighs everything else.
Edit: Ok here we go, this is why it's not implemented: https://github.com/ghostty-org/ghostty/issues/392#issuecomme...
There's more than one workaround which is superior in my opinion: https://i.imgur.com/iWoqrM0.png
IIRC you can even use AppKit to remove the close/minimize/fullscreen buttons, so it would just be a blank bar.
You could go a step further and use private APIs / objc runtime voodoo to set the height of the titlebar to 0. That might outside your design philosophy though.
Also, FYI, clicking the green fullscreen button still uses macOS native fullscreen, so you definitely want to disable that button (which is a public AppKit API) when you have that option enabled
$ brew install ghostty
Launch it, don't configure anything, in the new terminal window then enter:
$ lazydocker
Response: 2024/12/28 09:04:42 An error occurred! Please create an issue at https://github.com/jesseduffield/lazydocker/issues
*exec.ExitError exit status 1 /home/runner/work/lazydocker/lazydocker/main.go:96 (0x9397d7) /opt/hostedtoolcache/go/1.21.13/x64/src/runtime/internal/atomic/types.go:194 (0x43bc1b) /opt/hostedtoolcache/go/1.21.13/x64/src/runtime/asm_amd64.s:1650 (0x46b9e1)
Which does not happen with fresh out of the box Mac Terminals, iTerm.
Probably it would be good to have less specific default options for people who just want to try it out before starting to configure it.
Maybe contribute to https://github.com/jesseduffield/lazydocker/issues/610 ?
Anyway, not my problem, I will just wait until it's fixed and if not, then I'll use one of the gazillion other ones that work 100%.
I'm on Linux, and first impression is ghostty is really good. Speed in particular is impressive.
info: ghostty version=1.0.1-main+a8e5eef1
info: ghostty build optimize=ReleaseFast
info: runtime=apprt.Runtime.gtk
info: font_backend=font.main.Backend.fontconfig_freetype
info: dependency harfbuzz=8.4.0
info: dependency fontconfig=21402
info: renderer=renderer.OpenGL
info: libxev backend=main.Backend.io_uring
info(os): setlocale from env result=en_US.utf8
info(gtk): GTK version build=4.6.9 runtime=4.6.9
info: optional config file not found, not loading path=/home/xxxx/.config/ghostty/config
info(config): default shell source=env value=/usr/bin/bash
"vulkan-disable" is only available when building GTK with G_ENABLE_DEBUG. See GDK_DEBUG=help
info(gtk): libadwaita version build=1.1.7 runtime=1.1.7
(process:164888): Adwaita-WARNING **: 19:33:13.357: Using GtkSettings:gtk-application-prefer-dark-theme with libadwaita is unsupported. Please use AdwStyleManager:color-scheme instead.
error(gtk): unable to get current color scheme: GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod: No such method “ReadOne”
info(grid): loaded OpenGL 3.2
warning(grid): OpenGL version is too old. Ghostty requires OpenGL 3.3
error(gtk_surface): surface failed to realize: error.OpenGLOutdated
info(sentry): sentry envelope does not contain crash, discarding
OS: Pop!_OS 22.04 LTS x86_64
Host: 20QVCTO1WW ThinkPad X1 Extreme 2nd
Kernel: 6.9.3-76060903-generic
Uptime: 2 hours, 20 mins
Packages: 5314 (dpkg), 22 (flatpak)
Shell: bash 5.1.16
Resolution: 3840x2160
DE: Plasma 5.25.5
WM: KWin
WM Theme: Breeze
Theme: [Plasma], Adwaita-dark [GTK2/3]
Icons: Papirus-Dark [Plasma], Papirus-Dark [GTK2/3]
Terminal: konsole
Terminal Font: JetBrains Mono 11
CPU: Intel i7-9750H (12) @ 4.500GHz
GPU: NVIDIA GeForce GTX 1650 Mobile / Max-Q
GPU: Intel CoffeeLake-H GT2 [UHD Graphics 630]
Memory: 6307MiB / 31738MiBProblem is that this application uses OpenGL ES for which 3.3 was only recently even finalized as a standard and most GPUs like nvidia don’t support.
But my main point here would be that the lack of explorable configuration, and the docs not having any search, make it quite challenging search for this.
Slightly more CPU heavy than Kitty.
in MacOS yabai tiling manager has problems dealing with native tabs, that's gonna annoy me like with Finder.
also in MacOS try pressing "Cmd + Shift + \", also works in Finder, it's there, it's cool, but I never use it.
I mostly appreciate Alacritty's simplicity and use tmux to manage multiple windows/panes.
Note: I don’t think GTK4 is bad. One of the best parts of the Linux ecosystem is that we have a lot of great DEs that have gradually differentiated themselves by UX. GTK4 not playing well with others is in part due to how different GNOME’s UX is. The toolkit is meant to serve one DE paradigm now and that’s led to higher quality on that DE. The drawback to that diversification is that there is no easy way to support all DEs. Your toolkit drives what you support (unless you go out of your way to fix things that GTK4 isn’t fixing - which is why I put that bit about seeing how KDE issues would be addressed). The word “Linux”, now more than ever before, describes an ecosystem (or kernel) rather than an operating system.
Qt-based desktop environments: KDE, LXQt
Iced-based desktop environments: COSMIC
By going GTK, you support 5 desktop environments. If you really don't like GTK, just build a Qt app runtime with libghostty. Lots of people want a Qt version.
KDE is standard on what, Steam deck? Every enterprise-y distro ditched it some time ago...
I styled Wezterm's tabs to look just like my tmux tab bar too, there's no visual difference for me between a Wezterm window with Wezterm tabs, and a Wezterm window with tmux tabs. If you're more of a terminal native than a Mac native, I think you'd enjoy it.
My wezterm config: https://github.com/justjake/Dotfiles/blob/new/config/wezterm...
I tried a few searches ('line height', 'vertical spacing') on the GH issues for the project [1], but didn't see anything. I'm sure it's a simple config option or something with my font, but it works out-of-the-box on Alacritty + xterm and others.
I might file an issue if I can nail it down a bit more.
I haven’t used it yet, and it requires you install Wezterm on the remote. Ideally Wezterm could push a mux server executable to the remote host if needed.
Wezterm moves instantly.
I keep using a lot of fresh tabs all the time and iTerm resizes instantly via Rectangle for me.
Ghostty was a bit more sluggish in resizing on an Intel Mac than iTerm in the current latest versions.
Isn’t this just a long about way of saying “no”? Very few frameworks let you flip a switch and build against Qt OR Gtk.
I’ll repeat that that is what I find disingenuous with the marketing and about page explanation. I have no problem debating whether or not QT-based desktops are a consequential portion of all Linux users. But if you agree that those users account for a sizable percentage of Linux users, then I think my take is a fair one.
It's one of those things that you don't realize how poor the performance is until you experience something better.
Mentioned from his blog: https://mitchellh.com/writing/ghostty-is-coming
No, it’s one of those things I’ve tested myself extensively and arrived at my own conclusion. Which I already mentioned in the comment you responded to.
But in practice 24-bit was an easy lift for terminals under active development ages ago, and in turn made it trivial to have everyone across any platform specify exact colors more easily without any end user customization or arguments about "not quite what I wanted" in an 8-bit palette or whatever. Thus a lot of the ecosystem now makes use of it. Being able to replicate anything yourself, or get close enough, in a smaller colorspace is still extra grunt work for no particularly valuable reason, and could actually add up to be fairly significant work if one has a lot of more complex code coloring themes and such.
Also, I thought opensuse (or whatever new name they’re using) was KDE default but with a choice (like Debian)? At least that’s what DE I got last time distro hopped to it. Which is why I don’t consider either as an example of why GNOME would be the “de-facto standard.”
Also, I'd wager Gnome is absolutely used by 90% or more of Linux users.
> Also, I thought opensuse (or whatever new name they’re using) was KDE default but with a choice (like Debian)? At least that’s what DE I got last time distro hopped to it.
Depends "which" openSuse. OpenSuse Leap is going away since Suse (the corporation) is doing away with non-immutable distros. Whether it keeps KDE remains to be seen as MicroOS has lots of issues with KDE. Tumbleweed has KDE as the first choice still, but it's basically hobbyist-only from this point since there's no equivalent Suse distro. Aeon is Gnome-only.
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
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`...
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”.
Out of curiosity, what GPU accelerated terminal does this.
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.
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?
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 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!
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.
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?
“… exploring not-for-profit structures to help ensure the long-term sustainability of Ghostty.”
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!).
I'm extremely excited to give Ghostty a whirl.
> macOS
> Quick Terminal: Lightweight terminal that animates down below the menu bar for instant access without interrupting work.
I was looking on the website to try and understand this more but couldn’t find any information. Perhaps I missed it?
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’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!
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?
On the cross-platform library, I wonder why "libGhostty" and not libTerminal. Which seems like a more appropriate in term of library?
Congrats for the release and happy new year.
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.
EDIT: WOOOW, for me this is going to be a game changer. I was just working at Redis stuff outputting a ton of debugging info and results, and normally the terminal was the bottleneck, and here instead it printed half million of results in the blink of an eye. And then I could go back in the history without any performance degradation. I love this: for development of systems it makes a big difference.
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:
keybind = global:cmd+space=toggle_quick_terminal
quick-terminal-animation-duration = 0.1
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)
I'm not going to learn more configuration languages or type 30 characters (or paste them from the browser) to toggle a binary setting.
edit: alas, it doesn't support bitmap fonts..
A commenter in this thread mentioned sifting through log / debug output… but why wouldn‘t you pipe it to a file instead?
1. Create a file with 1 million lines:
for i in {1..1000000}; do echo "Line $i: This is a test of terminal performance."; done > bigfile.txt
time cat bigfile.txt
- iterm2: 3.5s
- Default macOS terminal: 2.3s
- Ghostty: 1.8s
Rendering huge stdout/stderr can be a bottleneck. Try running a program that writes half a million lines of text to stdout without file redirects and a lot of terminal emulators will struggle to keep up.
Together with Bun I believe that is two high profile open source software made with Zig.
I'm very new to Ghostty and went looking for my favorite theme "Solarized Light"; it's listed as "iTerm2 Solarized Light" -- in contrast (heh) to "Solarized Dark"
$ ghostty +list-themes
/solari
<... lists 7 options ...>
theme = dark:Builtin Solarized Dark,light:Builtin Solarized Light missing or unsuitable terminal: xterm-ghostty
Connection to xxx.xxx.xxx.xxx closed.
It turned out that this is associated with how I automatically run tmux by having the following kind of config for how I connect to that server.
Host server3000
IdentityFile ~/.ssh/host_specific/foo/bar/server3000/id_ed25519_baz
RequestTTY yes
RemoteCommand /usr/bin/env tmux new-session -A -s '%L'
env | grep ^TERM=
TERM=xterm-256color
And if I run tmux, then inside of it from
env | grep ^TERM=
TERM=tmux-256color
SetEnv TERM=xterm-256color
Took a bit of tinkering to set a theme and my favourite Pragmata Pro, but what ultimately annoys me is the lack of 'turnkey' selecting for text.
When I run `Cmd + A`, I want my terminal to make a full text selection of an entered command, not of the screen content. Or when I run `Option + Shift + Arrow left/right`, I want to select words from an entered command, not to type '4D;4C;4D;4C'.
I'm not a vimer or emacser, I want to have normal macos experience. For this reason alone I thought it's too early to switch and Warp is still great for me.
You could try:
- Ctrl+A: Move to the beginning of the line.
- Ctrl+E: Move to the end of the line.
- Ctrl+K: Cut the command from the cursor position to the end.
- Ctrl+U: Cut the command from the cursor to the beginning of the line.
- Ctrl+Y: Paste the text back.
This should work in all terminals.
By normal macos experience I mean key bindings for regular text fields, not regular terminal (whatever they're supposed to be). Afaik, Warp was the first one ever to treat terminal input as a regular text field input.
I like where we're headed with tools like this and Ladybird[0] for hope of a subscriptionless future.
Thank you, Mitchell!
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).
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.
These days, I actually just use the terminal that's built-in to VSCode for everything...
See this other user's comment: https://news.ycombinator.com/item?id=42518033
I don’t like the “feel” of the new Windows Terminal “app” but it is more “modern” and “capable” (running a newer conhost under the hood).
But if you’re willing to use non-standard software then WezTerm, Alacritty, and Kitty (WSL with an XServer) are all good options.
This really does aim to be the terminal for all.
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...
Thanks for this. After 7 years of using iterm2 I still don't know what will happen with the ambiguous "Split Horizontally | Split Vertically". I know the issue is I'm thinking about it and should just learn it, but it would be more helpful if it was named "Split A | Split B".
(might be a non-native language problem)
$ cd ghostty
$ zig build -Doptimize=ReleaseFast
$ ./zig-out/bin/ghostty
Anyways, I eventually learned this was about a terminal emulator (which is awesome), but the ghost on the front page really inspired my imagination. I think it would be a good thing to have some kind of companion like that, when it's me, by myself, constantly surrounded by terminals all day. Is the choice of having the ghost be rendered in a text-mode terminal important? I think it is for me.
So what I am asking, if you are making a GPU-based rendering toolkit, please write also SIMD software fallback without shaders. Remember how fast Windows 95 was and make it a little bit faster.
Why would you not ssh?
WezTerm has tabs but they're not native UI elements.
Konsole also has easy resizing of text and supports images in the console, you might like it.
Looking forward to checking out Ghostty.
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.
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...
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)
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...
keybind = global:ctrl+grave_accent=toggle_quick_terminal
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.
It may not work for you, of course.
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.
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
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].
Very disappointing. Not sure why people are trying to kill off bitmap support in everything these days. Will stick with foot.
*edit - oh, no Windows support for now (my hands are tied at work).
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.
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.
At the same time, Yakuake seems to be in maintenance mode, and you should be happy when it works with new KDE versions.
It doesn't, especially on average DPI monitors. Oh, you mean the OTF trick.
Thus far I have not been able to get my italic bold font (Cartograph CF) working on Ghostty, but this is a minor issue.
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.
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”.
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
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.
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
sudo apt install libgtk-4-dev libadwaita-1-dev git
error: unable to spawn glib-compile-resources: FileNotFound
Build Summary: 78/83 steps succeeded; 2 failed (disable with --summary none)
install transitive failure
└─ install ghostty transitive failure
└─ zig build-exe ghostty ReleaseFast native transitive failure
├─ run glib-compile-resources (ghostty_resources.c) failure
└─ run glib-compile-resources (ghostty_resources.h) failure
error: the following build command failed with exit code 1:
/home/tlhunter/Downloads/ghosttty/ghostty/.zig-cache/o/57acb02f2b1ccf1b03b9597a8c5f2d09/build /home/tlhunter/Downloads/ghosttty/zig-linux-x86_64-0.13.0/zig /home/tlhunter/Downloads/ghosttty/ghostty /home/tlhunter/Downloads/ghosttty/ghostty/.zig-cache /home/tlhunter/.cache/zig --seed 0xb4306e7d -Z11426c6f3a70c8b9 -Doptimize=ReleaseFastI'm quite surprised they don't provide a .deb package as that checks off 90% of Linux users.
- 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...
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.
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.
As I said in another thread, this ain't a AAA game. Shading a text grid is basically free on the GPU lol.
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.
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.
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.
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.
mkdir -p ~/.config/ghostty
ghostty +show-config --default --docs >> ~/.config/ghostty/configUninstalled it right away, I'll keep using the default MacOS Terminal app.
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 :(
> On macOS, the GUI is written in Swift and uses AppKit and SwiftUI.
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.
For anyone else curious about how to configure these, check out the docs: https://ghostty.org/docs/config/reference#custom-shader
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.
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.
I just find myself on the other side of the line for Alacritty.
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.
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?
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.
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.
window-theme = system
gtk-titlebar = false
gtk-wide-tabs = false
gtk-adwaita = false
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.
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.