I would really like to try out Ghostty as I live in a terminal all day long; and the devlogs have been great reads but joining a random discord to ask (pretty please) to be added to some private wait list with random selection of testers sounds like far too much faffing about.
Once it goes public beta I’d love to give it a go and compare to Kitty and Alacritty which are my current daily drivers.
to be added to some private wait list with random selection of testers sounds like far too much faffing about.
Completely fair, and I’m sorry about that. :( I’m doing the slowly-opening closed beta process in big part to maintain my personal work/life (hobby/life?) balance, I’m not trying to be exclusive or drum up hype or any of that (some of that is happening and its purely incidental to my actual intents).
Hoping to get to a public release later this year. :)
Sorry if i didn’t articulate it right. I very much understand and support trying to keep the work/life balance right! And I don’t mind private wait lists at all. I was just saying the method of the wait list to me was more involved and esoteric than say an email wait list which I would have signed up for without a second thought.
Recently, I happened to see some “higher profile” people sporting Ghostty and jealousy sets in; the good kind because I’m looking forward to trying it :) I’m a big fan of your work more generally, so I have high hopes for this too! Until the release, I’ll keep enjoying the devlogs! Thanks for work!
For whatever it’s worth, I joined the discord, mostly forgot about it, and then one day had it open and was around when invites were available for a couple of hours. My point being, I have as low a profile as a person can have, and the process didn’t really require much of me at all.
That said, the key element is luck: you have to be online and looking at the channel during a window when invites open up. But if you use already discord at all, I encourage you to join the channel and peek in from time to time. It worked for me.
I have, right around the time they were first published. It has been too long for me to really remember any specific details about them, I probably should go back and review.
If I remember correctly, the main idea was read input into a buffer and then render directly out of it. My conclusion was that this approach wouldn’t play nice with the control sequence and rewriting heavy usage in visual editors, the main usecase where I care about the performance of a terminal emulator.
I do rember only a single video, so maybe this was addressed later in the series?
My conclusion was that this approach wouldn’t play nice with the control sequence and rewriting heavy usage in visual editors, the main usecase where I care about the performance of a terminal emulator.
I’m curious about that assumption. Most interactive things do, at most, one complete redraw of the screen per keypress, which is pretty slow by the standards of any vaguely performant terminal. In contrast, the place where I really care about performance is if I’ve just dumped a 100 MiB log of some process into the terminal and I want to be able to search and scroll within it fast. I can do that with the macOS terminal, but I’ve run commands via ssh that made the Windows terminal take two minutes to catch up with the drawing.
There’s some cool engineering here! It seems to mostly be in service of improving performance on some kinda silly-seeming throughput benchmarks but it sounds like fun and maybe the focus on efficiency here will pay off when it comes to working on stuff like input latency.
IO throughput is the speed that the program running within the terminal emulator (the shell, neovim, tmux, cat, etc.) can pump bytes to the terminal emulator and have them processed. This particular metric has a very real world impact, from tailing very loud log output to accidentally dumping a large file to the terminal (we’ve all been there).
If there’s so much text going to the terminal then I would prefer that my terminal emulator not show it to me or fill the scrollback with it unless I specifically ask for that. I appreciate that it may be more practical (and more fun!) to make the decoder really fast than to develop safe heuristics and a good UX for handling large dumps of data to the terminal.
I don’t think these are silly-seeming benchmarks at all. cat-ing the entirety of a Japanese bible translation to the terminal is actually a pretty representative text-manipulation task - it’s the sort of thing you might do completely seriously if you’re e.g. an amateur scholar of comparative religion and you want to study how Japanese translators chose to render particular bible verses - and it was noticeably faster in the provided ghostty demo. 400 ms vs 50ms is noticeable to the human eye, and it’s the sort of thing that definitely adds up over time. I think it’s great that @mitchellh is working on this kind of performance improvement, and I’m looking forward to giving it a try when it’s ready for a public beta.
There is no way you can read or even comprehend that amount of text in the 350ms difference. I am with cmcaine that this is a silly fabricated benchmark.
I disagree! If you are working with a large document of text in a complicated writing system in a terminal, moving around in it frequently, it does in fact matter to your workflow if rendering happens instantly or with a tiny bit of lag. My assertion is that texts of the level of length and complexity of a Japanese translation of the Bible are in fact pretty representative of texts that at least some people will want to work with in a terminal, and thus spending the time on optimizing ghostty to bring the render time of that amount of text below the human noticeability threshold is a worthwhile optimization.
If there’s so much text going to the terminal then I would prefer that my terminal emulator not show it to me or fill the scrollback with it unless I specifically ask for that.
I did ask for it, by catting the file. Now, I don’t want it to actually draw all of the text, but I do want it all in the scrollback where I can search for it and scroll to any location.
The thing I really want from a terminal is a turn-the-page abstraction (especially if it’s also used for the alternative screen), where I can hit the button, clear my scrollback, but still be able to go back to that scrollback without having to find it. Then I can turn the page, cat a large file, turn the page, do interactive things, turn the page back and search in the file, then to back to the active page and run commands.
Really? What windowing system and how does it expose it? The terminal emulator is the thing that implements the search feature, how does the windowing system let you move back to a previous page and search within that?
In your example, open a window, cat a large file, open another window, do interactive things, switch to the previous window and search in the file, then back to the second window and run commands. Or use tabs.
But now I realise you’re talking about better scrollback handling within a single terminal/shell session, and the pages of scrollback are inert instead of being their own shell sessions.
In your example, open a window, cat a large file, open another window, do interactive things, switch to the previous window and search in the file, then back to the second window and run commands. Or use tabs.
That doesn’t work easily if the thing generating a load of output is in the middle of a stateful session. It’s mildly annoying even if it’s in an ssh session, where at least I need to open a new window, ssh, cd to the right place, and then do the command. That interrupts flow.
But now I realise you’re talking about better scrollback handling within a single terminal/shell session, and the pages of scrollback are inert instead of being their own shell sessions.
Yes, the scrollback at the moment models an infinitely long piece of paper coming out of a teletype. If I had a real teletype, I could tear off chunks of it and refer to them. I could throw some away, pin others up on the wall to refer back to. I want that abstraction, but with all of the benefits of not using paper.
Yes, the scrollback at the moment models an infinitely long piece of paper coming out of a teletype. If I had a real teletype, I could tear off chunks of it and refer to them. I could throw some away, pin others up on the wall to refer back to. I want that abstraction, but with all of the benefits of not using paper.
Not really. For one thing, they subsume my terminal’s scrollback, so I can’t just search. Second, they don’t provide the page abstraction (at least, not in anything I’ve seen). I want to be able to do:
$ cat {large file}
< turn the page >
$ cat {other large file}
< turn the page >
$ vim {other file}
And, within that terminal, jump back to either of the previous pages to search them or copy things from them, and ideally open them in another window so that I can have them side-by-side. If I’m searching, my search should be scoped (by default) to the current page. For example, if I do a big build multiple times, I want to be able to search the build output from the current build, or search the build output from the previous one, but know which one I’m looking at because they’re on different pages.
now ctrl-b p moves to a previous window, ctrl-b n moves to the next window, if the config is set up properly you can jump directly to any window by number; the statusbar will tell you which windows are which.
Enter scroll mode with ctrl-b [ or if you’ve turned mouse mode on, just run your scrollwheel or two-finger trackpad gesture or whatever. Search with ctrl-S if you’ve got emacs mode turned on or / in vi mode. You can copy to clipboard, or if you’re on a system with clipboard, primary and secondary, any or all of those.
If you want to pull a tmux window out to another terminal, open the other terminal, join the existing tmux session in non-exclusive mode tmux attach and you can look at the same or different windows in each terminal.
I used tmux for a while, but eventually moved to dtach. Running a windowing system in a windowing system never works well for me. Scrolling in tmux sessions can’t just use the scroll bar. My terminal has a nice search feature but tmux breaks it. I can’t copy long things from tmux because it doesn’t populate my scrollback (the tmux devs intentionally broke this flow. They truncate going to the terminal if it appears too fast and removed the option to disable that ‘feature’) and so I have to copy and paste things in chunks. All of this hits things I do every day and makes me less productive.
I don’t want to run a terminal emulator in a terminal emulator to get these features, I want my terminal emulator to provide them.
It is closed beta and everyone in the closed beta already has full source access (at the time of writing this, around 700 people). This will be a FOSS project in time, so anyone will be able to learn from it.
does ghostty supports graphics in terminal? with kitty (and tmux) I can render graphviz directly onto terminal which I find handy when debugging ragel grammars, for example
I would really like to try out Ghostty as I live in a terminal all day long; and the devlogs have been great reads but joining a random discord to ask (pretty please) to be added to some private wait list with random selection of testers sounds like far too much faffing about.
Once it goes public beta I’d love to give it a go and compare to Kitty and Alacritty which are my current daily drivers.
Completely fair, and I’m sorry about that. :( I’m doing the slowly-opening closed beta process in big part to maintain my personal work/life (hobby/life?) balance, I’m not trying to be exclusive or drum up hype or any of that (some of that is happening and its purely incidental to my actual intents).
Hoping to get to a public release later this year. :)
Sorry if i didn’t articulate it right. I very much understand and support trying to keep the work/life balance right! And I don’t mind private wait lists at all. I was just saying the method of the wait list to me was more involved and esoteric than say an email wait list which I would have signed up for without a second thought.
Recently, I happened to see some “higher profile” people sporting Ghostty and jealousy sets in; the good kind because I’m looking forward to trying it :) I’m a big fan of your work more generally, so I have high hopes for this too! Until the release, I’ll keep enjoying the devlogs! Thanks for work!
For whatever it’s worth, I joined the discord, mostly forgot about it, and then one day had it open and was around when invites were available for a couple of hours. My point being, I have as low a profile as a person can have, and the process didn’t really require much of me at all.
That said, the key element is luck: you have to be online and looking at the channel during a window when invites open up. But if you use already discord at all, I encourage you to join the channel and peek in from time to time. It worked for me.
Have you, @mitchellh, seen Casey Muratori’s videos on increasing the throughput of the Windows Terminal by a 1000x? Here is an official playlist: https://www.youtube.com/playlist?list=PLEMXAbCVnmY6zCgpCFlgggRkrp0tpWfrn
I’m really rooting for you to make Ghostty the best terminal emulator thus far!
I have, right around the time they were first published. It has been too long for me to really remember any specific details about them, I probably should go back and review.
If I remember correctly, the main idea was read input into a buffer and then render directly out of it. My conclusion was that this approach wouldn’t play nice with the control sequence and rewriting heavy usage in visual editors, the main usecase where I care about the performance of a terminal emulator.
I do rember only a single video, so maybe this was addressed later in the series?
I’m curious about that assumption. Most interactive things do, at most, one complete redraw of the screen per keypress, which is pretty slow by the standards of any vaguely performant terminal. In contrast, the place where I really care about performance is if I’ve just dumped a 100 MiB log of some process into the terminal and I want to be able to search and scroll within it fast. I can do that with the macOS terminal, but I’ve run commands via ssh that made the Windows terminal take two minutes to catch up with the drawing.
There’s some cool engineering here! It seems to mostly be in service of improving performance on some kinda silly-seeming throughput benchmarks but it sounds like fun and maybe the focus on efficiency here will pay off when it comes to working on stuff like input latency.
If there’s so much text going to the terminal then I would prefer that my terminal emulator not show it to me or fill the scrollback with it unless I specifically ask for that. I appreciate that it may be more practical (and more fun!) to make the decoder really fast than to develop safe heuristics and a good UX for handling large dumps of data to the terminal.
I don’t think these are silly-seeming benchmarks at all.
cat-ing the entirety of a Japanese bible translation to the terminal is actually a pretty representative text-manipulation task - it’s the sort of thing you might do completely seriously if you’re e.g. an amateur scholar of comparative religion and you want to study how Japanese translators chose to render particular bible verses - and it was noticeably faster in the provided ghostty demo. 400 ms vs 50ms is noticeable to the human eye, and it’s the sort of thing that definitely adds up over time. I think it’s great that @mitchellh is working on this kind of performance improvement, and I’m looking forward to giving it a try when it’s ready for a public beta.There is no way you can read or even comprehend that amount of text in the 350ms difference. I am with cmcaine that this is a silly fabricated benchmark.
I disagree! If you are working with a large document of text in a complicated writing system in a terminal, moving around in it frequently, it does in fact matter to your workflow if rendering happens instantly or with a tiny bit of lag. My assertion is that texts of the level of length and complexity of a Japanese translation of the Bible are in fact pretty representative of texts that at least some people will want to work with in a terminal, and thus spending the time on optimizing ghostty to bring the render time of that amount of text below the human noticeability threshold is a worthwhile optimization.
Note that this also affects regular text editing when using e.g. vim.
Sure, but vim writes a lot less data per second to the terminal than
cat big_file.txt.I did ask for it, by catting the file. Now, I don’t want it to actually draw all of the text, but I do want it all in the scrollback where I can search for it and scroll to any location.
The thing I really want from a terminal is a turn-the-page abstraction (especially if it’s also used for the alternative screen), where I can hit the button, clear my scrollback, but still be able to go back to that scrollback without having to find it. Then I can turn the page, cat a large file, turn the page, do interactive things, turn the page back and search in the file, then to back to the active page and run commands.
I get this from my windowing system. I’m curious why you want this in the terminal emulator, rather than better window or tab management.
Really? What windowing system and how does it expose it? The terminal emulator is the thing that implements the search feature, how does the windowing system let you move back to a previous page and search within that?
In your example, open a window, cat a large file, open another window, do interactive things, switch to the previous window and search in the file, then back to the second window and run commands. Or use tabs.
But now I realise you’re talking about better scrollback handling within a single terminal/shell session, and the pages of scrollback are inert instead of being their own shell sessions.
That doesn’t work easily if the thing generating a load of output is in the middle of a stateful session. It’s mildly annoying even if it’s in an ssh session, where at least I need to open a new window, ssh, cd to the right place, and then do the command. That interrupts flow.
Yes, the scrollback at the moment models an infinitely long piece of paper coming out of a teletype. If I had a real teletype, I could tear off chunks of it and refer to them. I could throw some away, pin others up on the wall to refer back to. I want that abstraction, but with all of the benefits of not using paper.
You mean like https://0x0.st/HnHa.mp4 ..
Unless I’m misunderstanding you, that’s what tmux or GNU screen does for you, right out of the box.
Not really. For one thing, they subsume my terminal’s scrollback, so I can’t just search. Second, they don’t provide the page abstraction (at least, not in anything I’ve seen). I want to be able to do:
And, within that terminal, jump back to either of the previous pages to search them or copy things from them, and ideally open them in another window so that I can have them side-by-side. If I’m searching, my search should be scoped (by default) to the current page. For example, if I do a big build multiple times, I want to be able to search the build output from the current build, or search the build output from the previous one, but know which one I’m looking at because they’re on different pages.
In tmux:
$ cat largefilectrl-b c [creates a new “window”, jumps to it]
$ cat otherlargefilectrl-b c [creates a third window, jumps to it]
$ vim thirdfilenow
ctrl-b pmoves to a previous window,ctrl-b nmoves to the next window, if the config is set up properly you can jump directly to any window by number; the statusbar will tell you which windows are which.Enter scroll mode with
ctrl-b [or if you’ve turned mouse mode on, just run your scrollwheel or two-finger trackpad gesture or whatever. Search withctrl-Sif you’ve got emacs mode turned on or/in vi mode. You can copy to clipboard, or if you’re on a system with clipboard, primary and secondary, any or all of those.If you want to pull a tmux
windowout to another terminal, open the other terminal, join the existing tmux session in non-exclusive modetmux attachand you can look at the same or differentwindowsin each terminal.Yeah, I think you would benefit from tmux.
I used tmux for a while, but eventually moved to dtach. Running a windowing system in a windowing system never works well for me. Scrolling in tmux sessions can’t just use the scroll bar. My terminal has a nice search feature but tmux breaks it. I can’t copy long things from tmux because it doesn’t populate my scrollback (the tmux devs intentionally broke this flow. They truncate going to the terminal if it appears too fast and removed the option to disable that ‘feature’) and so I have to copy and paste things in chunks. All of this hits things I do every day and makes me less productive.
I don’t want to run a terminal emulator in a terminal emulator to get these features, I want my terminal emulator to provide them.
It’s a little bit of a shame that can’t go look at the actual implementations mentioned in these blog posts.
It is closed beta and everyone in the closed beta already has full source access (at the time of writing this, around 700 people). This will be a FOSS project in time, so anyone will be able to learn from it.
Sure, just be nice to be able to see what can be learnt/adapted to apply in another terminal application I occasionally dabble with improving ;-)
ctrl+f zutty - nothing! Where’s the ZuTTY comparison?
does ghostty supports graphics in terminal? with kitty (and tmux) I can render graphviz directly onto terminal which I find handy when debugging ragel grammars, for example
Yes, It supports the Kitty graphics protocol.
Also, I’ve been planning to start working on sixel - I’ve implemented color decoding, and just left it after that