Life is too short for a slow terminal

I used to use volta but then they killed it and told people to switch to mise. The mise setup is just way too complicated. I just am tired of having different config files for different tooling when it should just read whats in the package.json and be done with it.

I use aliases that lazily load nvm when I actually want to use it. This converts the shell startup penalty into a node/npm startup penalty.

You can also just replace nvm with fnm (https://github.com/Schniz/fnm). It’s a lot faster and generally works better too.

Second this. Just add Starship.rs for prompt and offload tool chain version handling to mise. That covers about 100% of my needs.

If your org doesn’t use mise, just add mise.toml to your global gitignore. Mise tries to be a single tool covering multiple needs, but don’t have to use it that way. I just manage toolchain versions and envvars (replace direnv).

I had performance issues with Mise which I reported here https://github.com/jdx/mise/discussions/4821.

Unrelated to Mise but related to zsh, there's also https://github.com/jeffreytse/zsh-vi-mode/issues/316. I noticed this plugin was causing a lot of delay. Learned a decent amount about zsh profiling from that issue.

I wasn't actually aware of the impact. I measured the zsh startup time locally (with mvn active and commented out) and it indeed makes a difference (.39s -> .08s). Not that I would have noticed that without measuring :) - yes I'm an old geezer.

Thank you for the recommendation, I might then also be able to ditch sdkman as well.

How often do you launch a fresh terminal though? I start mine with a script to have favourite tabs ready at boot and then generally not much afterwards.

Is this poor man's Nix/direnv, or does it do anything else?

I open and close terminals _constantly_, but I'm usually pretty weird in my workflow, so no comment on your first question.

I run a scrolling WM and have settled into a habit of opening terminals when I need them, then closing them right after. I'll open a terminal, git pull, close it. Etc. I also use a terminal that launches cold in 10-20 ms, so it's not like a pay a price for it.

This is actually what I thought this post was about! But then I saw the Ghostty reference, which, in my experience, is not very fast to launch at all. I got it opening new windows quickly by running the main process as a systemd service, but Foot launches way faster without all that fuss, and allows you to go the daemon route if you want it _even_ faster.

EDIT: Just want to clarify, no shade on Ghostty. That project is cross platform and uses the 100% defensible decision to use the full GTK stack on linux. Foot is Linux AND Wayland only, and uses that very restrictive environment to optimize the hell out of startup and general performance.

It can affect shell subprocess startup time as well, which, depending on your setup and the tools you use, might be worth optimising for.

I don't remember when I did it, but it looks like I must have gone through this at some point (maybe due to using GNU Make a lot? Or perhaps it was some other tool) - my zsh setup does a bunch of autocomplete setup only in the interactive case, and it seems to help a bit with startup time, at least on macOS:

    % for i in {1..5}; do /usr/bin/time zsh -i -c exit; done # zsh in interactive mode
            0.05 real         0.03 user         0.02 sys
            0.02 real         0.01 user         0.01 sys
            0.02 real         0.01 user         0.00 sys
            0.02 real         0.01 user         0.00 sys
            0.02 real         0.01 user         0.00 sys
    % for i in {1..5}; do /usr/bin/time zsh -c exit; done # zsh in non-interactive mode
            0.01 real         0.00 user         0.01 sys
            0.01 real         0.00 user         0.00 sys
            0.00 real         0.00 user         0.00 sys
            0.00 real         0.00 user         0.00 sys
            0.00 real         0.00 user         0.00 sys

Maybe, but notice that almost all of the article, and its followup posted today, is about the speed of starting a shell not of a terminal emulator window. So if you use interactive sub-shells, anything from shelling out of a vi clone or mailx, through :terminal in NeoVIM, to running tmux/screen or script, then the concerns are relevant.

That said, it is almost totally about the Z shell. So you might still qualify as 'weird' in this case on the alternative grounds of not using the Z shell. (-:

Same here. Main terminal w/ tmux, editor terminal with tmux (runs nvim so I can jump to it with a key bind), ssh to remote server with remote tmux, scratchpad term with tmux. I try to reuse the same panes a lot, otherwise open a new tmux window temporarily to do something (C-b c). Basically never open a whole new separate terminal instance on top of those.

> But if your terminal can't keep up with your typing speed there is something deeply wrong with it. For the poor sools that had to work in VDI with radio link...

I open terminal far more often than that. But you should also remember that the startup cost is also paid by some subshells, and any shell scripts you run (the actual cost will vary: which init files are sourced varies between interactive and non-interactive shells as well as login shells and non-login shells, but it won't be zero cost).

I only notice how efficient my terminal is if something dumps a ton of logs to stdout. Sure I can pipe to a file and use vim, but it's convenient not to need to do that. And sometimes I have like 8 things going at once.

I'd say your workflow is pretty typical, from what I am seeing.

Developers that are very heavily invested in terminal and (over) optimize their terminal configuration are a small but very vocal minority.

I do the same, so there's a good chance you're (we're) the weird one

I'm the creator of Ghostty. This isn't right. It should idle at 0 to 1%, as supported by sibling comments. If you can collect more details about your system please open a discussion on the main Ghostty repo. Same with memory.

In terms of speed, same thing: if you can provide some kind of objectively measurable thing, we can look into it. Everything we've measured so far firmly places Ghostty in the "fast" camp (with friends such as Kitty).

We're sometimes faster, sometimes slower, but in any case not noticeably so. You wouldn't pick Ghostty vs Kitty for example for performance, it'd be something else. But you would pick Ghostty over say... iTerm2 for performance (but you may pick iTerm2 for features, its extremely feature rich!).

> Just sitting there idle it’s pulling a constant 40% of my CPU? No thanks!

You need to figure out what is going on because that certainly isn't normal.

Literally seeing 0.0% on Linux

I suspect you enabled some weird setting that you've forgotten about. ghostty isn't unimaginably fast but it's faster than iTerm 2 which is plenty. And I'm sitting here with a lengthy Claude Code session open, as well as a couple tabs for my docker container and dev servers, and its idle CPU usage is 0.0%.

WezTerm is great too and, AFAICT, is everything Ghostty wants to be. Kitty is also very good, although WezTerm edges it out for having an integrated muxer.

I can't understand Ghostty either except as some kind of trendy memetic thing, the $GME of the TTY world.

My ghostty is using 0.4$ - 2.5%?

I know ghostty is designed to be super high performance but I find it both uglier and slower than Iterm2!

I started using it expecting to love it, but in reality it didn't seem to gain me anything but in fact was worse in several major ways. Also less configurable than Iterm2. :/

That happened to me too, turns out my desktop was software accelerated because I had screwed up the GPU config somehow. I asked Claude to fix it and it did.

This. Ghostty is significantly slower than Kitty on my Arch setup. It's still fast enough I guess, but no reason to switch from Kitty for me.

If you like that, you should check out my project https://beachcomber.sh . Its about time I take it from dogfooding to beta users if you want to give it a go.

Maybe I should remove the following bit of code from my profile?

    if [ "$SESSION_TYPE" != 'remote/ssh' ]; then
     if [ "${TERM_PROGRAM}" != 'tmux' ]; then 
      ( if [ $[RANDOM % 10] == "0" ]; then fortune -n 40 -s; else echo "Hi, $(whoami)!"; fi ) | cowsay | lolcat && printf '\n'
     else
      if [ "${TMUX_PANE}" == '%0' ]; then 
       fortune | cowsay -f small | lolcat && printf '\n'
      fi
     fi
    fi

But what would life be without a little bit of fun?

That's why you should optimize only the things that matter to you.

"I tell you, we are here on Earth to fart around and don't let anybody tell you any different."

— Kurt Vonnegut

foot is great, I have yet to use anything better. I suspect Ghostty is aimed at part-time and full-time Mac users. I don't get the hype.

I use the term "terminal emulator" in the same sense as in the blog post:

"The terminal itself

Shell startup is only half the story, because the emulator adds its own input latency. I use Ghostty, which is GPU-accelerated and native, and my config is just seven lines long."

I do not use Ghostty or anything similar^1

1. https://en.wikipedia.org/wiki/List_of_terminal_emulators

Further, the terminal emulator cited by the blog author requires a graphics driver

I do not use a graphics driver

> Thus I don't use a terminal emulator.

Yes you do. It's the one built into your operating system's kernel. You'll find a lot of, but not all of, its code in /usr/src/sys/dev/wscons .

"Terminal emulator" as used in the blog post refers to userland software, such as Ghostty, not a terminal emulation module in the operating system kernel

The author of the blog post is using both (a) terminal emulator userland software and (b) kernel module(s) that perform terminal emulation

I only use one. I do not use a userland terminal emulator program

On NetBSD, I don't use a framebuffer

I use the vga driver which does not do graphics