Hacker News Reader

Comment by DanielHB | Hacker News Reader

Am I the weird one? I usually have 3/4 terminals open at a time and rarely open new ones. Terminal startup speed is a non-issue for me.

The only thing I demand to be fast on my terminal is grep reverse search (ctrl+r) and of course typing a character. But if your terminal can't keep up with your typing speed there is something deeply wrong with it.

View on HN

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.

I constantly open and close terminals too. Maybe I'm doing a quick lazygit check on cwd. Maybe I'm opening up an ephemeral claude/codex session for a couple questions about why a test failed. Or quickly editing a file with vim. Or remembering where I put that file with yazi or fzf. -- I don't even know, but all of it is contingent on it being fast to open a new terminal in cwd.

So much so that I vibe-coded my own terminal emulator for vertical tabs on macOS (using libghostty for the terminals) that is faster and less weird than iTerm.

+1 for Foot, truly a joy to use.

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

For the interactive case, I don't really mind (within limits - the worst case, on macOS after a reboot, takes several seconds, and that's tedious). I also start new interactive terminal sessions fairly rarely.

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

Reply on news.ycombinator.com