Libghostty Is Coming
Posted3 months agoActive3 months ago
mitchellh.comTechstoryHigh profile
excitedpositive
Debate
20/100
Terminal EmulatorsLibghosttyZig Programming Language
Key topics
Terminal Emulators
Libghostty
Zig Programming Language
The announcement of libghostty, a library behind the Ghostty terminal emulator, generates excitement and discussion among HN users about its potential applications and features.
Snapshot generated from the HN discussion
Discussion Activity
Very active discussionFirst comment
3h
Peak period
63
0-6h
Avg / period
14.5
Comment distribution160 data points
Loading chart...
Based on 160 loaded comments
Key moments
- 01Story posted
Sep 23, 2025 at 9:56 AM EDT
3 months ago
Step 01 - 02First comment
Sep 23, 2025 at 1:16 PM EDT
3h after posting
Step 02 - 03Peak activity
63 comments in 0-6h
Hottest window of the conversation
Step 03 - 04Latest activity
Sep 26, 2025 at 9:48 AM EDT
3 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
ID: 45347117Type: storyLast synced: 11/22/2025, 11:17:55 PM
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
1. https://github.com/neovim/neovim/issues/33155
I tried a while back to invert my workflow (from tmux driving neovim to neovim driving terminals) because I thought it might be easier to only ever have one buffer open for a given file, instead of attempting to open a file in a given pane only to realize that it's already open in a different neovim instance in a different pane.
When I was testing that stuff out I don't think I noticed particular issues with text reflow that would benefit from being solved by swapping to libghostty, rather my pain points were just about how to adjust to the different paradigm. I'd be curious to hear more about someone who is all in on Neovim embedded terminals (and possibly how libghostty might make it better).
> I thought it might be easier to only ever have one buffer open for a given file, instead of attempting to open a file in a given pane only to realize that it's already open in a different neovim instance
This is not a problem in my config:
Since `'autoread'` is by default `on` in Neovim, this seamlessly reloads the buffer if the underlying file has been updated on disk.- Session management. I've written custom scripts for myself around this (zoxide + fzf). If you want to see how this can be used, look at ThePrimagen's workflow. I don't use his scripts but he has a good demo of how he harnesses sessions.
- Unified scrollback management - easily search the scrollback, yank it, etc. My favorite thing to do is to yank part of the scrollback, then `Prefix+B,=` to list everything I've yanked (think of this like a "clipboard manager" specific to tmux), select an entry, and press `e` to edit it in `$EDITOR`.
- This one might be a stretch, but I tend to try and use only terminal tools (without being utterly insane) because then tmux can be my "tiling window manager" no matter what OS I'm on. Oh, I have to use Windows for work? Not to worry, tmux runs in WSL2, as do most of my preferred tools, so I feel mostly at home even though I normally really dislike Windows.
- It's scriptable. Read `man tmux` and use your imagination!
Notwithstanding any of that, there are cons, the most apparent one being that I am limited to text-based tools this way. An example of this: getting images to work in tmux, though many modern terminal emulators support them, is a huge pane, so I haven't bothered.
https://www.reddit.com/r/tmux/comments/1ch9tqp/primeagen_tmu...
Also not sure how ghostty would help, haven't noticed text reflowing issues.
It's not bad, a little awkward getting used to:
- you might want a plugin to give you a "persistent" terminal across all tabs
- I still haven't found a way to clear scroll back while a command is running
- I had to set up mappings for easier exiting terminal mode (c-\ c-n really sucks)
- I had to set up events so whenever a terminal buffer is focused it immediately enters insert mode. While I love vim, I've never wanted modal editing in a terminal
Micro is a truly goated software. I mean, it can genuinely replace vscode for small scale editing in the context of shopify that the parent comment was referring to.
https://micro-editor.github.io/
It also helped me in physics when I had to remember the units like 10^-6 being micro, 10^-9 being nano etc. and the funny thing is that I used to remember it in the start by seeing I am not sure if it was on micro's github or something but it was a comment on how micro has more features than nano and thus it's name.
So like for some time I definitely felt like I was thinking of micro software, then nano and making the feature comparison to find micro to be larger than nano.
Might seem kinda niche but I ABSOLUTELY LOVE MICRO. Its the one software that I install everywhere, even on my android phone by using UserLand[1] with alpine linux.
I tried writing python code on my phone and it was definitely pleasant thanks to micro.
[1]:https://github.com/CypherpunkArmory/UserLAnd
Aside: I didn't realize Ghostty was written in Zig, wow. The first Zig-thing I'm aware of using on a regular basis. It's amusing the repository structure looks exactly like a Golang layout, haha.
https://github.com/ghostty-org/ghostty
Hopefully libghostty will be much more permissive. No dependencies (not even libC) is a good sign that will be true.
(written on a 2018 macbook pro running macOS 10.14.6, which still works great in every way)
and p.s., way to take a neutrally stated, perfectly reasonable preference of system usage and make it personal. The perfect example of the type of person I'd pay money never to encounter.
You can do whatever you want, I left my true thoughts out, and kept it as impersonal as possible. As someone who ships and supports products and has to deal with curmudgeons like you, I would literally pay to not have you as a customer or user. People like you are a constant drain on attention, time, and focus. You know, like you basically expecting folks to bend over backwards, in this very thread, to support you, when there's a perfectly viable supported solution.
> perfectly reasonable preference
Whatever you say, friend.
Mitchell raised the issue himself two years ago: https://github.com/ghostty-org/ghostty/issues/189
but really not all features can make it in 1.0
In foot I just ctrl+shift+r and search back the references one-by-one in a mode, which I guess is 90% of my use case for scrollback.
No, “just run it again” doesn’t work.
Is there any particular reason?
Also, not sure if this is by default or it picked it up from my old iTerm2 configuration, but cmd+shift+up/down navigates through prompt lines so it's easy to find the start of a long command. My PS1 in zsh is:
I also like that I can have my config in a little plaintext file and just drop it onto a new computer and get the same keybindings. I am using the terminator keybindings for creating and navigating between split panes.
Also I just tried Ghostty for the first time. With iTerm2 and the Zsh/Powerlevel10k theme, there's an extremely brief but perceptible lag from running a command and the render. In ghostty it feels actually instant.
"How much content is in this window"
and
"Where am I in that content"
I still use it daily but it means I have to switch tools for certain things, and reading log files or log output is one of the more common reasons I switch.
I should probably look into trying to get the scrollback info into my statusline, No idea how easy or hard that is - so if someone has done it, feel free to shoot me pointers.
I always was on the camp of "tail -f file.log" but since discovering this app, I saw the light.
Or do you mean when you inevitably forget? Well then yeah you're at the mercy of your terminal but as others mentioned ghostty has a hack to help as well as some other terminals. But this should also help reinforce why you should pipe more often and write to files (or tee). It sucks but not making the same mistakes in the future and learning better habits will help you write better code and use better practices.
But that's the age old problem of "you can't analyze the data you didn't record" and that's a footgun you'll experience in every programming language, every experiment, and across many parts of life. Better to record and throw it away than not record and regret it.
It IS recorded. It's right there in scrollback (Literally the default buffer to record). It's easily accessible with most tooling, including nice scrolling, mouse support, find/search, etc...
Except in Ghostty, it's not so accessible. No find, no scrollbars.
I end up having to dump it into another tool, which at least they make pretty easy (ex: https://ghostty.org/docs/config/keybind/reference#write_scro...).
Although deciding when to do that would be easier if I had a better indicator for just how much scrollback content exists. Ex - if it's 3 pages... I'll just scroll through it. If it's 3000 pages... time to dump to file.
So no - by default I use a pager... just about never. Why would I when I have absolutely everything in scrollback by default 99.9% of the time?
---
Don't confuse your preferences with "correct" :P
I'm doing just fine with code and best practices, I'm simply stating that this is a rough edge on an otherwise lovely tool.
My terminal history is normally huge, and the log output would be some unknown percentage of the total scrollable history.
Plus, they're very open about what they're doing and prioritizing. As another commenter said, it's coming soon. For the rest, open feature requests, you might have needs that others didn't think of or even realize they needed
Pop the whole scrollback in helix, where I can search, select, jump around, paste stuff into a scratch buffer. It’s slick. It’s got a normal search too. But yeah I haven’t used a built in emulator search in a while I guess!
If you don't know, you can send the log to a file, and open that file to look through it. More powerful than just a search next, as you can have instance counts, search with regexp and all the bells and whistles and it virtually stops the logging.
At first I thought the same as you, now I've become quite partial to this concept. I hope they don't remove this.
Finding mechanistic (& programmatic) sympathy counts for so so much! Shapes the arch of software so much! But it's such invisible unknown work to most people, not so overtly clear & obvious but something that constantly builds day after day, person after person, incremental 0.2% gains compounded by lack of friction.
As well as just promoting good practioners, it feels like discourse about software architecture has really fallen off. We are deep inside rabbit holes specific to this framework or that, and there's only occasional popping out to free air to bring back some observations from the burrows. Ideally we'd have many more volumes of Architecture of Open Source Applications (2011), for example, to really dive into what is, to give us some common referents to learn from and talk about. https://aosabook.org/en/
This is all so core, so worth getting deep on & looking how things are assembled, what the interfaces and modules and shapes look like, what the tradeoffs were. But it remains chiefly an arcane art, one that most developers much less most businesses haven't developed a refinement or taste for.
My observations of 20+ years in tech is that tech, collectively, chases the easiest thing to do, then complains it doesn't work without the self-reflection to realize that the very pursuit of doing/understanding as little as possible dooms the result from the beginning.
They spend years of often-needless/excessive effort to avoid weeks of studying that would move them forward.
The software world really needs people like him to drive things forward.
The previous commentor is hoping he'll move on because maintaining isn't as fun as starting? Why do you think he can't decide that for himself?
However their financials are... LOL
Revenue US$583 million (2024)
Operating income US$−254 million (2024)
50% loss margin :-)))
Actually, that's the question (or rather the feeling) I had even before seeing these numbers. Just by reading the docs and looking at everything they built (and how they built it) made me wonder if they spend more than they make. That's a really funny feeling I never had before. Like, surely economies can't be that forgiving when it comes to polishing things. Is that what's happening to the company? Mere overspending?
There's an old Knuth quote:
And I think we're seeing more and more that these projects made with love are successful. That without the hyper fixation on money we can build good projects that make big changes in a world.In some sense I'm a bit envious of Mitchell but truthfully these types of things make me more question how we've constructed our society and economy. It shouldn't require one to start with wealth to be able to build things that have such an impact. What needs to be changed where we can live up to what Knuth proclaimed. I'm sure all of us have had experiences where were we given the time (and usually not much) we could make things so much better. But we make many sacrifices when we rush. Which leads to more good advice by Knuth
At what point do we push back? We see that the people we really look up to did things so differently. Knuth himself expressed how detail obsessed he was, and such a claim is common among the grey breads. Of course, things change, but are we creating a world with no wizards? Are we creating a world where we reward people for solving problems and making our lives easier? Or are we just maximizing some score of a pointless game?I'd love to live in a world with a thousand more Mitchells, following their passions without the burden of needing to justify decisions to a board who has no interest in quality. How do we create that world?
Like you said, what a legend. But, how do we make more legends?
One thing I've been envisioning is something like a "certified B corporation" style qualification that companies can get that indicates they contribute financially back to open source commensurate to the amount of it they consume to run their core business. If everything you do runs through open source software, in a moral sense, one can make the argument that you owe something back to it.
But the same general problem exists in industry. Our fear of doing things non-optimally only results in a less optimal solution. It's a risky move to take no risks.
In both academia and industry you see the same people doing the same things in the same way. It's no wonder things don't change. You can't have a paradigm shift by following the paradigm (playing it safe). I feel like this is a big shame in both tech and academia as the histories of these have always been made by those who rocked the boat. At some point we just have to admit we're not very good at predicting the future and instead of trying to predict what will be the most successful we should fund passion. I'm sure charlatans will get funded too, but its not like we're doing a good job at preventing that from happening now anyways...
I cannot imagine what he went through.
Hero.
From the author himself: "My company had an exit, I did well financially. This is not a secret. I'm extremely privileged and thankful for it.".
Honestly, good for him [for doing well financially] and for admitting that he is privileged, and above all, being thankful for it.
I walked away thinking that no matter what they did, they'd probably be successful. I was extremely happy to find Ghostty and have been using it ever since.
Example: Neovim is considering the switch to libghostty-vt when its ready. https://github.com/neovim/neovim/issues/33155
I never thought in a million years I would even think of ditching iTerm2 but when Ghostty dropped I installed it and fell in love.
I love ghostty, but if it keeps suddenly failing for no apparent reason I might have to go back to wezterm.
FWIW I've using tip since the closed beta and never had major issues.
solution: write a new VT terminal parser to replace the other ten
result: we have eleven different VT terminal parsers
https://xkcd.com/927/
I've looked into it with a PiZero and some HATs but I'd like something made by smarter people. This would be perfect for that.
Ideally just some dip-switchs to set the terminal to emulate and set the display resolution.
My router doesn't have a video port, but it does have a dummy terminal port. I had to scrounge a video card for my server to set it up, but it does have a serial port [3]. So that would have been nice.
Also would be nice for a modern remake of dumb terminal with abandoned monitors.
[1] https://www.cabling-design.com/references/pinouts/EIA-TIA-56...
[2] https://en.wikipedia.org/wiki/Modular_connector#8P8C
[3] https://serverfault.com/a/529159
Gruvbox light theme looks great too.
The fact it's written in Zig is awesome too, if you ever question if Zig is ready, ghostty is your answer to that.
Not seeing myself going back. It's great experience.
Tip: if you combine your ghostty flow with aerospace, it's nearly perfect setup for your keyboard only experience on mac.
I live in vim and after about 30 seconds of checking ghostty out I switched from iTerm2 to ghostty for good. No regerts.
I guess it isn't a huge deal to have every user to modify their ssh_config instead, but it's an ergonomic pain point for many new users.
Mostly terminology is just a fairly good terminal, so I have little incentive to switch. :)
I also used Terminal until recently and don't use any of the advanced features alternatives provide. The main reason to switch from Terminal.app is truecolor support. The terminfo thing is annoying but I just setenv TERM in ssh config. Better split panes is nice. Configuration in a text file is a matter of taste, but documentation is good.
> The terminal seems simple at first (you type in commands and run them! no big deal!), but the more you learn, the more you notice a million little inconsistencies (why does pressing the arrow keys sometimes print out "^[[D"? why does selecting text sometimes not work? why are the colours sometimes unreadable?) that make it feel like an inscrutable black box. And it often doesn’t feel worth it to learn more because documentation about the terminal is so fragmented and full of obscure jargon.
> But! Understanding just a little more about the terminal can make your experience WAY better. You can quickly recognize what’s causing a problem (“oh, my arrow keys aren’t working because this is one of those annoying REPLs that doesn’t support arrow keys!”) and immediately fix it (“I’ll use rlwrap!). Or you can turn “wow, this text is unreadable” into “oh, my terminal emulator is responsible for colours! I’ll just go into the settings and reconfigure my colours!”.
https://youtu.be/07Q9oqNLXB4?si=FthNcZSYQSNnT0mP
Tmux copy mode is already great, my one gripe is no line numbers.
This script https://gist.github.com/Nimmidev/2cf4d5cc80dce32d0240ec7b3cf... is pretty good, but I still get frequent bugs with it, and also it just doesn't work in fullscreen mode (2 panes).
The core issue is that it's allocating a new tmux pane with the sole goal of mirroring line numbers; it would be nice if they synced up in the same pane, avoiding the above issue.
Piping it into neovim is an option that you can do on both neovim and zellij. zellij loses colors, and neovim is probably the best solution to this problem but then again I don't want to have to remember to turn on/off line numbers every time and I personally like one-off panes. Separation of responsibilities, I guess.
Long-winded rant to basically say: would a standard like this solve my issue easier? From what I understand of terminals, I would need to parse the underlying pty, maintain a scrollback buffer internally in the wrapper shim, and also be able to dynamically adjust toggling line numbers on/off.
If I'm doing this kind of translation, how "leaky" will the abstraction be until I'm basically re-implementing the logic in my middle layer, assuming that "for free" I can get the translation both in and out from the pty?
I've been trying to look closer at TUI tools, but that's what really bothered me. Given just how god awful the VT protocol is, you could get the state machine parsing correct, but the developer still has to learn basically every little quirk that was added over the years, no?
(And before someone makes a false equivalence, no, this isn't the case even with languages like c++ - I'm still learning quirks about it to this day, but I don't have to learn the entire thing to build proper, robust code. It does not seem the same with something like the VT protocol. So yes, I'm aware that some learning should take place, but I'm wondering how structured of a developer experience this will end up being.)
106 more comments available on Hacker News