I'm not a ghostty user (and neither a MacOS user). I use Plasma 6 and yakuake (which uses konsolepart; that is, it's based on Konsole, Plasma's default terminal emulator) is fairly economical in its battery usage.
So, my terminal, while it could perhaps improve in its battery usage, does not behave like this.
Good tools will have an option to disable the spinner. Haven't used Claude Code yet so don't know if it falls into the category of "good tools" by that definition. :-)
I like what you need to know a bazillion ways to disable all this unnecessary cruft.
And people would be angry if you even note what you don't need it.
I propose we should have some global switch to on/off these type of things, something like kern.fidget.widget=off or $VANILLA_PUMPKIN_LATTE=BROYEETSURE
Problem is, esp lately, Claude Code for example takes so long to respond that without the spinners and whatnot one may think the app is frozen or something. And even with them I still wonder sometimes.
Yeah that was my first thought. Use a TUI that abuses the terminal to make a experience poorly recreating an actual GUI, don't be shocked if it doesn't turn out very efficient
Yeah, welcome to 1980, where a library coming from a roguelike shaped almost all the TUI's for Unix until ~2010 or so, Curses.
A 386 could run NetHack at blazing fast speeds and read the news in a TTY perfectly well.
A multicore machine can't get the basic thanks to the 'wonderful' JS. Heck, even s9 Scheme from http://t3x.org ships a Curses module, enough to drive some text and maybe boxes/menues and it should fit in two floppies. A single one if the image it's generated later on-disk.
Dude, back off the buzzkill on my vibe code, man. I told Claude what I wanted, and it works fine on my machine.
What kind of Karen are you that you expect me to check if it works for other people? I mean you have Claude, too, so fix it yourself. I've got more code to vibe and vibe to code. Later for you.
Note: this is dark sarcasm just in case somebody thinks I'm serious. The problem is that I'm not really laughing because I have heard very similar to this and had to be the one harshing both their vibes very much.
Without all thw unnecessary headings, "color", and constant "Let. That. Sink. In."-esque recaps this would be 2 paragraphs. Just let it be! Readers don't need the slop.
Can't we just normalise publishing whatever you put into the LLM instead? I'm sure the author typed things into their favourite AI assistant that regurgitated that long form, LLM-speak style version. I'm sure the original prompt has all the relevant content and was a lot more pleasant to read.
Can't wait for this style of prose to become an incredibly embarrassing faux-pas.
> Can't we just normalise publishing whatever you put into the LLM instead?
Something that has cropped up from time to time in the art world since at least the Dadaists was the idea that rather than distribute the artefact, you distribute the instructions to construct the artefact.
I think if we want to combat slop we have to be honest about why it happens, and the honest truth is that a blog post whose whole content was "I was only using the terminal and Claude code for a couple hours and it drained my whole battery wtf write me an article about this" would not be gaining traction. Some amount of polish and effort is needed, but we can still avoid the most annoying tropes.
My terminal is not burning battery anywhere at all like mining bitcoin, and neither is yours.
If you're not benefitting from the ability to offload your terminal rendering to GPU, why are you using a terminal that offloads terminal rendering to GPU in the first place?
Imagine running something massively CPU bound, but you've still got to spin up perhaps tens of terminals in order to simultaneously ssh in to multiple servers because you don't want to set up a remote monitoring solution because you don't want each of the servers to be running a docker image where SSH>htop would suffice.
There are plenty of situations in which one might want a terminal emulator offloaded to gpu. That you are not in any of those situations is no reason to write a hit piece throwing shade as if the packages mentioned are somehow bloated or inefficient.
Imagine whining about how you've got to pay adobe and use several gigabytes of ram to resize jpgs. You'd obviously be outside Photoshop's ideal customer profile, just as you are outside ghostty et al's.
This, among many other reasons, is why I still use Terminal.app. I switched to iTerm for true color, but when Tahoe added it to Terminal.app- I switched back.
I don’t use MacOS or Claude Code, but I do use Kitty terminal on Linux, which the author suggests has the same issues that plague him using Ghostty.
Kitty is a magnificent piece of software that has radically enhanced the interface between me and my computer. And it does this while consuming negligible resources.
Compared to Kitty, Konsole has image preview, click on files and links, tabs and tiles. Konsole does not have a way of changing the layout of tiles, equivalents to Kitty shell and remote control, pager, and the ssh integration (e.g. ls in an ssh session and Konsole will not open the file).
Aside from its well-known features, such as displaying images directly in the terminal over ssh, I use it to create TUI applications. The application is a saved Kitty session, with a defined arrangement of windows. Each window runs a specified program, and communicates with the other windows over a Unix socket. Kitty has a convenient tool to create these sessions. Once created, I can start the session-application like any other program. The sessions are defined in a text file, so I can edit it to adjust the window arrangement or other details.
I also use its shell integration features, such as putting the scrollback into a pager, constantly.
to answer that question we need to first look at the alternatives. whee else could session management go? and then we can consider the benefits and drawbacks of each approach.
if you are thinking of tmux then the problem here is that tmux is in itself a terminal.
to get session management away from the terminal it would need to be done in such a way that when the session tool connects the session it merely acts as a proxy or less, but does not interpret and then translate the signals that come from the session like tmux does.
this is not trivial, at least with the current way terminals work.
I‘m not sure I understand the question. Some people use similar kinds of sessions in terminal multiplexers such as tmux (is that what you have in mind?), but this leads to problems (interpretations of key sequences, etc.) that the Kitty solution sidesteps.
I don't know that I have ever understood a reason to leave the native terminal included with any given OS, particularly after the Windows modernization pass in recent years on the terminal.
layout, multiplexing, tab-complete, history, using the same interface across multiple systems, ligatures...
There are lots of distributions that ship emulators that don't have modern features, and even among those that do, I still don't want to learn the individual quirks every time I hit a shell.
Gnome terminal, yakuake, ptyxis, cosmic, konsole, xfce4-terminal, qterminal, etc all have slight variations between simple things like rendering and more important things like hotkeys. It's nice to have an alternative that I can install on any system such that I can get comfortable with just the one. If I can't install anything I'm often stuck poking around to find whatever the devs version of correct is, or else asking the owner of the machine "okay, how the hell do I do {x}?" if they're comfy with their cli, but chances are if I'm sitting there it's because they're not comfy with their cli.
I could cover a lot of it with a bashrc file, but I wouldn't want anyone fucking with mine, so I'm not touching anyone elses.
Those would be handled by your shell, not your terminal, right?
> multiplexing
If you have a good window manager, then there is no reason to have a bespoke multiplexing implementation in your terminal. I can stack my terminals and _any other window I want_ with tabs and switch between them using the same hotkeys/interface that I use for my whole system, rather than each app implementing their own tabs.
Some people frequently or exclusively work on remote systems over ssh. Multiple windows is not an alternative to a multiplexer. They have some overlap in use cases. But it's not 1-1.
In that situation, the multiplexing wouldn't be handled in the terminal. You'd use something like tmux or screen. Seems irrelevant to the discussion about terminals.
Same. Need multiple terminals visible at once? New window. Need a few separate sessions? New tab(s).
All the bells and whistles people have shown me over the years... it never even gets close to making me think "oh yea, that's better than basic tab/window management and the terminal app that comes with my OS".
I've always found tabs to be pretty limiting, though I have a ton of them in Firefox and Konsole since that's what's - been - available. They're marginal improvement over multiple windows. Then Horizon[0] came on the scene a few weeks ago and I fell in love with that infinite canvas. Started tweaking it like crazy, but now I'm working on a full port that natively supports Xpra[1], so I can have all my apps on an infinite canvas with views grouped exactly as I prefer. And that's the future IMO.
I need it all the time. large monitors are a lot more productive for any task that involves looking at more than one thing while doing it if you have tiling.
tiling managers like Terminator are, to me, the most efficient. Something like Blender for hybrid customization might be a sweetspot. Blender allows for arbitrary layout and essentially tab control in any tile.
In my case, it's always been because the native terminal emulator had issues actually emulating terminals when connected to remote systems, it was intended to be only a terminal-shaped wrapper around the host system's shell.
I won't use neither Claude, nor a MacBook; I would just keep chilling out programming
with decent tools and a bare XTerm to accomplish the rest. I can get Aragonese bricks ^U sweets in the meanwhile.
On Terminal.app, I wonder if the GNUStep eversion and the ones bundled with Mac OSX shared some code.
I'm not a ghostty user (and neither a MacOS user). I use Plasma 6 and yakuake (which uses konsolepart; that is, it's based on Konsole, Plasma's default terminal emulator) is fairly economical in its battery usage.
So, my terminal, while it could perhaps improve in its battery usage, does not behave like this.
All the stupid spinners at the prompt are obnoxious. Unfortunately it’s so trendy it’s impossible to reverse course
Good tools will have an option to disable the spinner. Haven't used Claude Code yet so don't know if it falls into the category of "good tools" by that definition. :-)
I like what you need to know a bazillion ways to disable all this unnecessary cruft.
And people would be angry if you even note what you don't need it.
I propose we should have some global switch to on/off these type of things, something like kern.fidget.widget=off or $VANILLA_PUMPKIN_LATTE=BROYEETSURE
Problem is, esp lately, Claude Code for example takes so long to respond that without the spinners and whatnot one may think the app is frozen or something. And even with them I still wonder sometimes.
kern.fidget.user-has-an-acutal-job-to-get-done
[flagged]
Claude Code has a reduce motion option in /settings
[dead]
The issue isn't the terminal. The issue seems to be that Claude is using React to render to that terminal at 60FPS like a goddamn video game
Vibe coding is soooo awesome!
And people thought that Electron was a resource pig. You ain't seen nothing yet.
Yeah that was my first thought. Use a TUI that abuses the terminal to make a experience poorly recreating an actual GUI, don't be shocked if it doesn't turn out very efficient
Yeah, welcome to 1980, where a library coming from a roguelike shaped almost all the TUI's for Unix until ~2010 or so, Curses.
A 386 could run NetHack at blazing fast speeds and read the news in a TTY perfectly well.
A multicore machine can't get the basic thanks to the 'wonderful' JS. Heck, even s9 Scheme from http://t3x.org ships a Curses module, enough to drive some text and maybe boxes/menues and it should fit in two floppies. A single one if the image it's generated later on-disk.
Vibe coding is unleashing man-made horrors beyond human comprehension on the world.
Have they not discovered event based rendering yet? Something changed, render! Nothing has changed, don’t render anything and keep the previous frame.
Dude, back off the buzzkill on my vibe code, man. I told Claude what I wanted, and it works fine on my machine.
What kind of Karen are you that you expect me to check if it works for other people? I mean you have Claude, too, so fix it yourself. I've got more code to vibe and vibe to code. Later for you.
Note: this is dark sarcasm just in case somebody thinks I'm serious. The problem is that I'm not really laughing because I have heard very similar to this and had to be the one harshing both their vibes very much.
I’m sorry that you have to deal with that. I think if I ever get into a similar conversation I will just answer “but I don’t have Claude…”
Consider how bloated data centers are when local models are now equally capable of human-scoped problem solving.
Software bloat fills a void created by itself.
Without all thw unnecessary headings, "color", and constant "Let. That. Sink. In."-esque recaps this would be 2 paragraphs. Just let it be! Readers don't need the slop.
Can't we just normalise publishing whatever you put into the LLM instead? I'm sure the author typed things into their favourite AI assistant that regurgitated that long form, LLM-speak style version. I'm sure the original prompt has all the relevant content and was a lot more pleasant to read.
Can't wait for this style of prose to become an incredibly embarrassing faux-pas.
> Can't we just normalise publishing whatever you put into the LLM instead?
Something that has cropped up from time to time in the art world since at least the Dadaists was the idea that rather than distribute the artefact, you distribute the instructions to construct the artefact.
I think if we want to combat slop we have to be honest about why it happens, and the honest truth is that a blog post whose whole content was "I was only using the terminal and Claude code for a couple hours and it drained my whole battery wtf write me an article about this" would not be gaining traction. Some amount of polish and effort is needed, but we can still avoid the most annoying tropes.
Sounds like a viral Tweet. Why wouldn't it be able to gain traction?
It wouldn't gain traction as a blog post, which is my point. Maybe this person would rather have a blog than engage on Twitter.
I hate hate hate the style of writing LLMs make.
I know people have their gripes with KDE, but Konsole has had a lot of these features for some time now.
My terminal is not burning battery anywhere at all like mining bitcoin, and neither is yours.
If you're not benefitting from the ability to offload your terminal rendering to GPU, why are you using a terminal that offloads terminal rendering to GPU in the first place?
Imagine running something massively CPU bound, but you've still got to spin up perhaps tens of terminals in order to simultaneously ssh in to multiple servers because you don't want to set up a remote monitoring solution because you don't want each of the servers to be running a docker image where SSH>htop would suffice.
There are plenty of situations in which one might want a terminal emulator offloaded to gpu. That you are not in any of those situations is no reason to write a hit piece throwing shade as if the packages mentioned are somehow bloated or inefficient.
Imagine whining about how you've got to pay adobe and use several gigabytes of ram to resize jpgs. You'd obviously be outside Photoshop's ideal customer profile, just as you are outside ghostty et al's.
This, among many other reasons, is why I still use Terminal.app. I switched to iTerm for true color, but when Tahoe added it to Terminal.app- I switched back.
I don’t use MacOS or Claude Code, but I do use Kitty terminal on Linux, which the author suggests has the same issues that plague him using Ghostty.
Kitty is a magnificent piece of software that has radically enhanced the interface between me and my computer. And it does this while consuming negligible resources.
What does it do for you that, say, konsole, gnome-terminal or even xterm wouldn't?
I was wondering also. If it can help, there is an overview on Kitty's website : https://sw.kovidgoyal.net/kitty/
Compared to Kitty, Konsole has image preview, click on files and links, tabs and tiles. Konsole does not have a way of changing the layout of tiles, equivalents to Kitty shell and remote control, pager, and the ssh integration (e.g. ls in an ssh session and Konsole will not open the file).
I dont get it. What exactly does kitty give use here?
Aside from its well-known features, such as displaying images directly in the terminal over ssh, I use it to create TUI applications. The application is a saved Kitty session, with a defined arrangement of windows. Each window runs a specified program, and communicates with the other windows over a Unix socket. Kitty has a convenient tool to create these sessions. Once created, I can start the session-application like any other program. The sessions are defined in a text file, so I can edit it to adjust the window arrangement or other details.
I also use its shell integration features, such as putting the scrollback into a pager, constantly.
Does session management really belong in the terminal emulator?
to answer that question we need to first look at the alternatives. whee else could session management go? and then we can consider the benefits and drawbacks of each approach.
if you are thinking of tmux then the problem here is that tmux is in itself a terminal.
to get session management away from the terminal it would need to be done in such a way that when the session tool connects the session it merely acts as a proxy or less, but does not interpret and then translate the signals that come from the session like tmux does.
this is not trivial, at least with the current way terminals work.
we need to entirely rethink the terminal protocol: https://news.ycombinator.com/item?id=47941354
I‘m not sure I understand the question. Some people use similar kinds of sessions in terminal multiplexers such as tmux (is that what you have in mind?), but this leads to problems (interpretations of key sequences, etc.) that the Kitty solution sidesteps.
Fucking AI slop
You're missing the point—we are each supposed to have our agent summarize the key points for us so we don't have to read all the generated slop!
Let me do that now: hmm, this article seems to be a complaint about applications that waste energy.
My exact reaction. Good to see more people think like this
I don't know that I have ever understood a reason to leave the native terminal included with any given OS, particularly after the Windows modernization pass in recent years on the terminal.
layout, multiplexing, tab-complete, history, using the same interface across multiple systems, ligatures...
There are lots of distributions that ship emulators that don't have modern features, and even among those that do, I still don't want to learn the individual quirks every time I hit a shell.
Gnome terminal, yakuake, ptyxis, cosmic, konsole, xfce4-terminal, qterminal, etc all have slight variations between simple things like rendering and more important things like hotkeys. It's nice to have an alternative that I can install on any system such that I can get comfortable with just the one. If I can't install anything I'm often stuck poking around to find whatever the devs version of correct is, or else asking the owner of the machine "okay, how the hell do I do {x}?" if they're comfy with their cli, but chances are if I'm sitting there it's because they're not comfy with their cli.
I could cover a lot of it with a bashrc file, but I wouldn't want anyone fucking with mine, so I'm not touching anyone elses.
edit: distrObutions->distrIbutions
> tab-complete, history
Those would be handled by your shell, not your terminal, right?
> multiplexing
If you have a good window manager, then there is no reason to have a bespoke multiplexing implementation in your terminal. I can stack my terminals and _any other window I want_ with tabs and switch between them using the same hotkeys/interface that I use for my whole system, rather than each app implementing their own tabs.
Some people frequently or exclusively work on remote systems over ssh. Multiple windows is not an alternative to a multiplexer. They have some overlap in use cases. But it's not 1-1.
In that situation, the multiplexing wouldn't be handled in the terminal. You'd use something like tmux or screen. Seems irrelevant to the discussion about terminals.
Same. Need multiple terminals visible at once? New window. Need a few separate sessions? New tab(s).
All the bells and whistles people have shown me over the years... it never even gets close to making me think "oh yea, that's better than basic tab/window management and the terminal app that comes with my OS".
I've always found tabs to be pretty limiting, though I have a ton of them in Firefox and Konsole since that's what's - been - available. They're marginal improvement over multiple windows. Then Horizon[0] came on the scene a few weeks ago and I fell in love with that infinite canvas. Started tweaking it like crazy, but now I'm working on a full port that natively supports Xpra[1], so I can have all my apps on an infinite canvas with views grouped exactly as I prefer. And that's the future IMO.
[0] https://github.com/peters/horizon [1] https://github.com/Xpra-org/xpra/
That requires a good window manager, which macOS does not have.
There are tons of good options for window management these days.
I’m currently trialing https://tangrid.app/ and it’s got some nice features.
For the few times a month I need to have two windows/panes visible at the same time, I take five seconds positioning and sizing them then move on.
I need it all the time. large monitors are a lot more productive for any task that involves looking at more than one thing while doing it if you have tiling.
use tmux.
tiling managers like Terminator are, to me, the most efficient. Something like Blender for hybrid customization might be a sweetspot. Blender allows for arbitrary layout and essentially tab control in any tile.
<nerd snipe>
In my case, it's always been because the native terminal emulator had issues actually emulating terminals when connected to remote systems, it was intended to be only a terminal-shaped wrapper around the host system's shell.
Splits. And tabs. But mostly splits. Nothing tmux and/or a decent window mangers wouldn't fix. But Macos.
iTerm2 has builtin native tmux integration
Game changer
>Zaragoza, Hotel Pilar Plaza café.
I won't use neither Claude, nor a MacBook; I would just keep chilling out programming with decent tools and a bare XTerm to accomplish the rest. I can get Aragonese bricks ^U sweets in the meanwhile.
On Terminal.app, I wonder if the GNUStep eversion and the ones bundled with Mac OSX shared some code.
[dead]