[HN Gopher] How I use my terminal
___________________________________________________________________
How I use my terminal
Author : todsacerdoti
Score : 220 points
Date : 2025-06-23 15:14 UTC (7 hours ago)
(HTM) web link (jyn.dev)
(TXT) w3m dump (jyn.dev)
| jonjacky wrote:
| The article title is actually "How I use my terminal"
| Hard_Space wrote:
| Thought that this was going to be a 'There Will Be Blood'
| spoof.
|
| (In case not obvious, current title is 'I use my terminal')
| IAmBroom wrote:
| I use your sudo?
| adolph wrote:
| I use your sudo !!
| fitsumbelay wrote:
| noticed this too after skimming the post, feels like the full
| title = "I use my terminal (and so should you )"
|
| Plus one for pro-terminal posts. As a chromebooker I've found
| that all I need is terminal and browser. Switching to my Mac OS
| seems kinda maximalist and I rarely use much outside of the
| terminal and, you know, more browsers
| babelfish wrote:
| HN will automatically trim some common prefixes and suffixes
| from title submissions
| progbits wrote:
| This is a HN "feature" removing How if it's the first word in
| the title. It serves no purpose other than generating
| confusion, with mods saying this somehow stops clickbait. How,
| you wonder? Nobody knows.
| littlerbooks wrote:
| Weird. I see a post titled "How to store Go pointers from
| assembly" literally three posts below this one.
| happytoexplain wrote:
| I believe the submitter can manually reject the auto-
| modified title, but they have to notice that it was
| modified.
|
| (I could be wrong about that)
| Stratoscope wrote:
| You are correct.
| indigodaddy wrote:
| Not quite reject exactly, you can just edit the title
| afterward for some X amount of time.
| Stratoscope wrote:
| Reminder to anyone submitting an article: you have two hours
| to edit the title to fix these alterations.
| rbanffy wrote:
| I believe these changes are intended to defang some
| clickbaity titles, but you are right that it maims some
| perfectly good ones.
| osmsucks wrote:
| I thought this was going to be a blog post about somebody using
| a terminal emulator they wrote.
| philwelch wrote:
| And I thought this was going to be a blog post about someone
| hooking up an old fashioned hardware terminal to their PC.
| pxc wrote:
| If you don't want to write a giant regex like this yourself,
| there are some ready-made tmux plugins that add things like this
| to copy-mode.
|
| https://github.com/tmux-plugins/tmux-fpp
|
| https://github.com/tmux-plugins/tmux-copycat
|
| https://github.com/Morantron/tmux-fingers
|
| https://github.com/tmux-plugins/tmux-urlview
|
| Any configuration or plugin that leans on the built-ins is
| probably going to be faster, so consider that w/r/t tmux-copycat.
|
| I also really like tmux-resurrect, which saves and restores
| sessions for you; tmux-continuum, which runs those automatically;
| and the tmux-zen plugin for Oh-My-Fish:
|
| https://github.com/tmux-plugins/tmux-resurrect
|
| https://github.com/tmux-plugins/tmux-continuum
|
| https://github.com/sagebind/tmux-zen/tree/master
|
| It's pretty easy to get a very nice tmux setup going!
| jynelson wrote:
| yeah, i got the original regex from tmux-copycat. but a) that
| regex doesn't handle `:` and b) copycat builds its own "viewer"
| abstraction on top of saving and restoring the pane state,
| which means that you can only have one action per search. my
| thing allows you to use normal tmux configuration syntax to
| bind actions to the files that are highlighted, because it
| reuses tmux's built-in search. note how all these plugins are
| either only supporting copy/paste or building their own "modes"
| on top, because tmux gives you very little control over
| highlights unless you use the built-in search.
| pxc wrote:
| That's great info! Thanks for filling me in.
|
| I used tmux for everything many years ago, but when I started
| the current job, I decided to try to do everything natively
| with Kitty instead. (IIRC one of my main reasons was that
| Kitty supports macOS' "secure input" features.)
|
| But tbh I never got around to making my Kitty setup as nice
| as my old tmux one. I think I may switch back soon. It sounds
| like I may want to set things up differently in light of
| these new features!
| happytoexplain wrote:
| The entire blog post being in lowercase distracted me more than I
| thought it would.
| gouggoug wrote:
| It's also interesting to see that the author themselves are
| clearly fighting against their own instinct to use uppercase:
| the first 2 items in the "here's what happens in that video:"
| list use uppercase.
| jynelson wrote:
| that's voice-to-text on iOS, i haven't found a way to turn
| off the auto-caps yet.
| incognito124 wrote:
| Huh interesting, I didn't even notice that
| RestartKernel wrote:
| It's a stylistic choice you sometimes see people commit to.
| Porter Robinson (a DJ) does the same thing, and it's always
| struck me as a bit indulgent.
| imiric wrote:
| Yeah, it seems immature to me.
|
| I used to write like that when I was a teenager. I guess it's
| a subtle way of rebelling against "the system". But seeing
| adults do that, especially in a professional setting, is
| cringey.
| furyofantares wrote:
| Kids these days. That's how many of us who grew up online in
| the 90s to early aughts have been doing things for 30+ years.
|
| I think many of us abandoned it when we went professional. Or
| abandoned it in those contexts but still do it in others. I
| don't do it on HN, clearly - but I do it almost everywhere
| else. It's much more natural to me to skip capitals.
|
| I believe there was also a period in the transition to
| ubiquitous smartphones where it wasn't an option to turn off
| auto-caps, or maybe there just wasn't the fine-grained control
| of which auto-correct you use on mobile devices that there is
| now. I suspect that killed some all-lowercase habits. I think
| that's why I ended up with a "normal" style on HN where I use
| caps and normal punctuation (I don't usually use periods for
| sentences that terminate a paragraph outside of HN.)
| happytoexplain wrote:
| I'm 40, but the only place I have ever abandoned proper
| casing is in the specific case of single-sentence
| text/chatroom messages (and later, 4chan posts), where I also
| omit the period. And even then, I only abandon sentence-
| casing - e.g. "I", proper nouns, etc are still capitalized. I
| never adopted that style in other places though, like forums.
| And I'm definitely not used to seeing entire chunks of prose
| in this more extreme version of that format (no uppercases at
| all, rather than just no sentence-casing).
| furyofantares wrote:
| Well I certainly didn't say all of us! Most people our age
| didn't live their whole life on forums/IRC/etc and even
| those who did, didn't necessarily pick that up. But also
| many of us did! I don't recall any forums back then where
| everyone did it; but I don't recall any where nobody did
| either.
| dr_kiszonka wrote:
| I am with you when it comes to texts for humans.
|
| However, for speed, I have recently abandoned capitalization
| and punctuation when interacting with LLMs, unless they are
| critical for clarity. I wonder if this is why many folks in the
| AI crowd write everything in lowercase.
| amonith wrote:
| I was under the impression that LLMs do tokenize upper and
| lower case differently so prompting all in lowercase would
| yield different results. Is this incorrect?
| o11c wrote:
| All writing is about managing the "surprise" budget. Strictly
| following the rules of grammar (subject to the specific dialect
| and field) minimizes surprise, so the author can spend more
| budget on (and the reader still has the focus for) the
| interesting part. Deliberately using a non-default style draws
| the reader's attention to that particular point.
| enricozb wrote:
| Fantastic. Been meaning to put something up like this myself. I
| feel like I gain so much information from just watching someone
| work, and having them open themselves up to questions.
| yobibyte wrote:
| I have a similar setup, but most of the functionality is coming
| from vim: grep/find, quickfix lists and temporary buffers:
| https://news.ycombinator.com/item?id=44282908
| bilalq wrote:
| I've shared similar frustrations with VSCode's vim plugin. These
| days, I often run Neovim from within VSCode's terminal for
| complex editing tasks where I might need to use macros or use
| fugitive or whatever.
| robenkleene wrote:
| I love this, I've been iterating on workflows like this for
| something like a decade now. Over time I've tried to peel back as
| many of my custom layers as possible, because all of those layers
| have a maintenance cost.
|
| Stock Vim (without `tmux`) can actually do most of what's shared
| in this post with `rg --vimgrep restore_tool | vim -c cb -` (`vim
| -c cb -` is my favorite feature in Vim; I find it strange that
| it's so rarely used or talked about).
|
| (Since re-running the `rg` search can be undesirable, and I often
| like to analyze results in a terminal before opening them in Vim.
| I use a custom `tmux` command to copy the output of the last
| command [using this trick that involves adding a Unicode
| character to your prompt https://ianthehenry.com/posts/tmux-copy-
| last-command/], then I send that into Vim with e.g., `tmux saveb
| - | vim -c cb -`.)
| johnmaguire wrote:
| > (`vim -c cb -` is my favorite feature in Vim; I find it
| strange that it's so rarely used or talked about).
|
| Care to explain what it does? Trying `ls | vim -` and `ls | vim
| -c cb -` I don't immediately see a difference.
| robenkleene wrote:
| `cb[uffer]` processes the current buffer as a compile buffer,
| which will find `grep` format matching lines (i.e., at a
| minimum starting with `<path>:<line-number>:<column-number>`)
| and populate the quickfix list with them, and jump to the
| first match.
|
| E.g., your example doesn't do anything because `ls` doesn't
| output `grep` format lines. So try piping the output of
| `grep` (you'll need flags for the line number and column
| number with `grep`, hence the `--vimgrep` flag above)
| matching the above format (or you could try `ls | sed
| 's/$/:0:0/' | vim -c cb -`, which will hack `ls` output to
| grep, and is occasionally useful).
|
| (Note that the above hints at another useful tip, `grep`
| parsing is only part of what `cb[uffer]` does, it can also
| parse compile output, e.g., something like `gcc foo.c | vim
| -c cb -` will jump to the first compile error in your program
| and put the rest of the errors in the quickfix list).
| WorldMaker wrote:
| You get similar buffer behavior if you use :make inside Vim
| and Vim as your build terminal. Despite being named :make
| it isn't hardcoded to just make as build tool (there's a
| bunch of out-of-the box settings you can pick with
| :compiler or you can update individual settings like
| makeprg).
|
| Similar behavior with :grep inside Vim which you can change
| your grepprg to rg if you like.
|
| I've got a feeling the `| vim -c cd -` isn't as commonly
| known because the Vim-initiated versions are somewhat more
| commonly known. It's handy to know that vim can do it in
| both "directions" (initiated from the external shell /
| initiated to the internal shell support).
| msgodel wrote:
| Ten years ago I threw out my massive multi-file, multi-package
| vim config and have been slowly building up a much simpler
| vimrc about 1-2 lines a year. I completely agree, defaults in
| old software are almost always there for a reason and you
| should try to understand that before changing them.
| codyb wrote:
| I also find creating my own little shortcuts to be super
| satisfying and of course very transferable since they work
| out of the box.
|
| ```some examples " Quick access to commonly edited config
| files (and a directory for my Shell scripts!) map <leader>v
| :e ~/.vimrc<cr> map <leader>V :source ~/.vimrc<cr> map
| <leader>w :e ~/Workspace/myCo/tmuxp-session.yaml<cr> map
| <leader>W :e ~/.tmux.conf<cr> map <leader>z :e ~/Shell<cr>
|
| " Super simple in editor note setup, amazing map <leader>x
| :vs<cr>:e ~/Documents/notepad.txt<cr> map <leader>X :vs<cr>:e
| ~/Documents/notes<cr>
|
| " Quick terminal pane map <leader>t
| :vs<cr><c-w>l:term<cr><c-w>j:q<cr> " Pull file path into
| clipboard nmap <leader>b :let @+ = expand("%")<cr> " Pull
| current line into clipboard nmap <leader>B "*yy ```
|
| Quick disposable terminals, tons of short cuts to get me into
| the config files that make it all happen (vimrc, zshrc,
| tmux.conf, a tmuxp session file) and to reload them, and
| super quick access to a well organized directory of notes are
| all huge boons during my workday.
| kannanvijayan wrote:
| I haven't had to in a while as I've lapsed into IDE usage as
| of late, but my vimrc is something I committed to memory a
| long time ago. set tabstop=4 set
| shiftwidth=4 set expandtab set showmatch
| set nohlsearch set background=dark syntax on
|
| Typing that config into a file is emotionally associated with
| a system feeling "ready" for me. "ah, now I can _do_ things".
| magarnicle wrote:
| Is this the same/similar to 'vim -q <(ripgrep --vimgrep
| restore_tool)'?
| robenkleene wrote:
| Similar enough, minor semantic differences (e.g., I don't
| think `-q` creates a buffer containing the matches)
| klntsky wrote:
| It is sad that we have to know how to configure tens of small
| utilities just to be productive. I ended up using emacs with some
| packages that I configure minimally, after spending a few
| hundreds of hours on ricing the shell, file managers, tmux, etc
| agentultra wrote:
| Emacs is why I can't go back to terminals.
| vyaa wrote:
| I haven't delved into emacs yet. Don't you still have it
| configure it and all its tools?
| umanwizard wrote:
| emacs is a lot easier to configure than anything else IMO
| because it's self-documenting. If you want to know how to
| use or configure some command it's trivially easy to jump
| to the source code of that command and just see how it
| works (or modify it, step through it with a debugger, etc).
| You can't do that in any other environment as far as I'm
| aware.
|
| That said, yeah, it certainly doesn't Just Work out of the
| box the way something like vscode does.
| jynelson wrote:
| yes!! i would love an environment where every binary
| carries a mapping from the exe back to the source code,
| DWARF is _kinda_ this but there 's very little tooling
| around it and distros often don't ship it by default. i
| want something like gdbserver but built into the editor
| and terminal.
| umanwizard wrote:
| That is also my dream; doing as much as possible inside
| emacs, using plugins written in emacs lisp, is basically
| the closest you can get to it today.
| iLemming wrote:
| With Emacs one can do some shit in terminal that otherwise
| would just sound absurd. Like
|
| - in Emacs' Eshell, one can pipe results in and out of
| buffers, e.g., you can run a command, then pipe it to
| grep/ripgrep, then pipe the results into a buffer (without
| any intermediate files).
|
| - Conversely, you can read a buffer content and pipe it into
| a command.
|
| - Or you can do simple calculations, you just need to use
| prefix notation e.g. `* 3 42` or `(* 2 pi)`.
|
| - You can run regular emacs functions, like `dired .` or
| `magit-status`, `find-file ~/foo` or `(calendar)`.
|
| - Or you can use Emacs vars and functions directly, e.g., `cd
| $org-directory`, or `cd (projectile-project-root)`, or `mkdir
| (format-time-string "backup-%Y%m%d")`
|
| - You can absolutely delegate some (potentially long running)
| tasks to run in an outside terminal. I wrote this command
| eshell-send-detached-input-to-kitty1, it uses Kitty
| Terminal's socket control feature.
|
| There are integrations that you can only dream about, one
| recent example is John Wiegley (creator of Eshell) and
| Karthik (author of gptel package) having to experiment with
| piping things in and out of LLMs.
|
| Sure, the backwards is also possible - you can emacs from a
| terminal, but terminaling from inside emacs is way more
| cooler.
|
| ___
|
| 1 https://github.com/agzam/.doom.d/blob/main/modules/custom/s
| h...
| bowsamic wrote:
| I hate configuring things. I tried to use PyCharm and it works
| great until it doesn't, then it's a nightmare. For example, the
| ruff support is non-existent and the only plugin is broken as
| hell. I think at some point you just have to accept it won't be
| perfect, but it is sad because I can "imagine" the perfect IDE.
| I just don't have the time or energy to make it reality, and
| apparently neither do Jetbrains
| iLemming wrote:
| I don't think it's Jetbrain's fault, even though I have not
| used their products for almost a decade. Python ecosystem is
| finicky - too many options - it's hard to decide which things
| you want and need - black or yapf or ruff, flake8, rope,
| mypy, pydocstyle, pylint, jedi; there are multiple lsp server
| options (none of which is ideal), you get to know things like
| what the heck 'preload' plugin is - the docstring for lsp-
| pylsp-plugins-preload-enabled just says "Enable or disable
| the plugin", etc.
|
| Trying to bootstrap a Python setup "that just works(tm)" is
| also a common struggle e.g. in Emacs world. Python tools are
| just a bunch of contraptions built with fiddlesticks and
| bullcrap. Anyone who tells you differently either already
| have learned how to navigate that confusing world and totally
| forgot "the beginner's journey"; or too new and have not
| tussled with its tooling just yet; or simply don't know any
| better.
| kjkjadksj wrote:
| I make do with just nano and basic pane/window/sockets in tmux.
| Certainly didn't put in a few hundred hours learning this. Not
| even a few hundred minutes.
| sevensor wrote:
| I use kakoune + tmux very happily, and between the two of
| them I've spent maybe two hours on config in the last eight
| years. There's a point of rapidly diminishing returns once
| you get past changing the control prefix in tmux to something
| that doesn't cause carpal tunnel.
| crmi wrote:
| I've used vim to the stage that I not only know how to exit
| it, its muscle memory... And I still prefer nano. Its just
| better imo.
| tomsmeding wrote:
| > Escape for some reason doesn't get sent as the escape key if it
| shows up next to any other keys???
|
| Welcome to ANSI escape sequences. The left arrow key, for
| example, is really just <Esc>[D . You can see this stuff for
| yourself by running `cat >/dev/null` (cat isn't actually doing
| anything useful here, it's just allowing you to type without the
| shell getting in the way and actually, you know, making an
| attempt to interpret the keys you press). Press backspace to
| figure out which bytes are represented by 1 and which by 2
| characters. 2-character sequences where the first is a caret (^)
| can be produced by ctrl + the second character, and correspond to
| the second character in ASCII minus 64. Hence ^A is byte 0x01.
| The escape key sends ASCII ESC, number 27, and is written ^[ .
|
| https://en.wikipedia.org/wiki/ANSI_escape_code
|
| Software distinguishes between a bare Escape key press and an
| ANSI escape sequence by waiting a couple of milliseconds and
| seeing if more bytes arrive. The number of milliseconds is often
| configurable, with e.g. the 'escape-time' config key in tmux and
| the 'ttimeoutlen' setting in vim.
| jynelson wrote:
| this is all true but it's not related to the bug in my post.
| this is input being sent via `tmux send-keys`, escape-time
| isn't relevant.
| tomsmeding wrote:
| Ah, but I suspect it still is: not the tmux config option
| indeed, but the vim config option. After all, I think with
| that `tmux send-keys`, you're sending input to vim, aren't
| you? And vim itself does escape sequence interpretation.
| aftbit wrote:
| I do all of this from vim. I have \a bound to repeat my last /
| search using ripgrep in the current directory, and open the
| matches in a panel below. I have \gd bound to go to the
| definition/declaration of a symbol.
| gertlex wrote:
| I really appreciate this method of sharing workflows. Well
| catered to the audience. Actually was slightly hoping there'd be
| sound to the vid, too, but reading the list of actions after-the-
| fact was reasonable. I learned a few things I could do and/or
| approach differently in my own flows.
|
| You mentioned the arcane keyboard shortcuts of tmux. I'm curious
| if you or others here have tried/use byobu (which I think of as a
| wrapper around tmux, basing most commands on the F# row). I was
| shown it a decade ago and have used it since (after a couple
| prior years of primitive tmux use).
| jynelson wrote:
| glad you've enjoyed it :) i was trying to find something that
| was clear while still being easy to skim.
|
| > You mentioned the arcane keyboard shortcuts of tmux.
|
| oh, i've remapped almost all the shortcuts in tmux. `ctrl-k` is
| not the default prefix and `h` is not the default key for
| "select pane left".
|
| i haven't tried byobu but from skimming the readme i expect it
| not to have a ton other than nicer default key bindings, and
| i'd rather not add more layers to my terminal.
| midtake wrote:
| I use my terminal too, but VSCode runs fast enough for me. Maybe
| it's because I'm a mid 30s year old boomer now, but I figure if
| it's caching symbol tables then the lag isn't the end of the
| world.
|
| But for whatever reason, I'd rather vimdiff when I have to
| resolve conflicts on rebase.
|
| What I really hate about VSCode currently is how huge pylance is
| though, and how it's all up in my grill when I am trying to
| manually code.
| thom wrote:
| Every vim/tmux user has created an ad hoc, informally-specified,
| bug-ridden, admittedly probably quite fast implementation of half
| of Emacs.
| b0a04gl wrote:
| vim+tmux setups usually lean on system primitives = pipes,
| files, signals, scrollback so the tooling tends to stay
| transparent across environments. that gives them an edge in
| portability and debugging, especially over ssh or in
| constrained shells. it's just lets your workflows shaped around
| different guarantees so natively, it naturally makes building
| your own vim config an obvious choice
| iLemming wrote:
| > especially over ssh
|
| Emacs has TRAMP mode - stands for "Transparent Remote (file)
| Access, Multiple Protocol", it lets you:
|
| - Edit files as if they were local:
| /ssh:user@host:/path/to/file
|
| - Chain connections: /ssh:jumphost|ssh:target:/file for
| bastion hosts
|
| - Access Docker containers: /docker:container:/etc/config
|
| - Edit Kubernetes pods: /kubectl:pod:/app/settings
|
| - Sudo seamlessly: /sudo::/etc/hosts or
| /ssh:host|sudo::/etc/config
|
| - And even combine them:
| /ssh:server|docker:container|sudo::/etc/nginx/nginx.conf
|
| What you get? Transparent integration - Dired, Magit, etc,
| they just work. There's no context switching - you stay in
| your configured Emacs environment. Your keybindings,
| packages, customizations remain the same. It's multiprotocol:
| Supports SSH, FTP, SMB, ADB (Android), and more.
| grep_name wrote:
| As someone who uses both vim/tmux and emacs for certain things
| (and spent years configuring and working only in emacs), my
| emacs setup is WAY more ad hoc, informally specified, and bug
| ridden than my vim+tmux setup ;)
| iLemming wrote:
| The key point you're missing from the parent comment is "half
| of".
|
| Maybe you have no idea how much Elisp code is out there in
| the wild. There is a LOT of things written in Emacs Lisp.
| Elisp is probably the most widely used Lisp, with the global
| total codebase amount exceeding both Clojure and Common Lisp
| combined.
|
| There are things built into Emacs that some specialized apps
| don't even have. Did you know that Emacs has built-in lunar
| and solar calendars, for example?
|
| Just by comparing the sheer amount of code, of course
| vim+tmux may feel less complicated - they give you fewer
| opportunities to encounter complexity because they offer
| significantly less functionality out of the box.
| skydhash wrote:
| The only thing missing from emacs is some (opengl) 2d
| surface api like the browser's canvas, to rival the rest of
| the OS.
| b0a04gl wrote:
| terminal scrollback is the only UI we don't treat as queryable
| state. op's setup shows how much context we're missing away a lot
| of rg output, file paths, stack traces, build logs they're all
| already right there in cluttered state.
|
| if shells exposed a scrollback api with line refs and structural
| tagging, we could annotate paths, link to buffers, diff last two
| runs, all without re executing anything. that would cut through
| half the indirection in current workflows. tmux's regex jump is a
| hack but it hints at a deeper model. scrollback should be its own
| memory layer
| jynelson wrote:
| yes!! one of the things i really want from a terminal is
| structured metadata, it allows you to build so much on top.
| right now anything remotely close requires parsing a bunch of
| ansi escapes.
| Analemma_ wrote:
| PowerShell got so close to doing this, and then they fumbled
| it right at the finish line by having terminal objects be
| binary data instead of structured objects in some kind of
| serialized format. PowerShell is honestly awesome for a bunch
| of reasons and getting to query pipe objects instead of
| parsing them is great, but the binary blobs hold it back from
| being perfect.
|
| Several attempts have been made to do similar things in Unix,
| but there's a massive ecosystem problem: four decades of
| classic tooling has to be totally rewritten to get this kind
| of support. I don't see it happening without some kind of
| industry champion who can throw their weight around to force
| it on people.
| jynelson wrote:
| i have ideas about how to strangler-pattern this so that it
| doesn't require a "flag day" where everyone switches over
| at once. i have about 15 paragraphs of this written up
| locally i need to turn into a blog post ^^
| Analemma_ wrote:
| I would love a new standard stream for structured output
| alongside stdout and stderr. That seems like the lowest-
| friction way to get tooling migrated: programs could opt-
| in if they wanted but nothing would break if they didn't,
| and then once you had sufficient buy-in you could make a
| new shell that defaulted to piping this new stream and
| fall back to stdout if there was no data in the new one.
| But it would still need a lot of coordination to make it
| happen, since AIUI you would need to change libc and
| every other C runtime to pass this new stream fd to every
| program, and that would rile people up.
| abnercoimbre wrote:
| Interesting. You might (or might not, I'm not really sure!)
| become interested by Terminal Click [0]
|
| If you want a comprehensive demo with even more features, I
| have one in this community video [1]
|
| Anyone can email me if they're game: abner at terminal dot
| click
|
| [0] https://terminal.click/posts/2025/04/the-wizard-and-his-
| shel...
|
| [1] https://vimeo.com/1091637660 (6-minute mark)
| msgodel wrote:
| That's the tty or the thing on the other end of the pty (ie
| your VTE like Xterm) which would have to do that. The shell has
| no access to any of it.
|
| There is an xterm command for writing the scrollback buffer to
| a file so in theory if you wanted a hack to enable it _today_
| you could use that + grep (or even trigger it with something
| xdotool if you wanted to automate it.)
| gricardo99 wrote:
| The one thing pulling me towards VS code, and away from terminal
| workflows is Copilot and the Agent workflows. Being able to
| seamlessly chat with AI models and then see/review its code
| changes is the biggest change to my workflow and productivity in
| years.
|
| I'm guessing some people already have these capabilities
| integrated into terminal workflows and I'd love to see a
| demo/setup.
| msgodel wrote:
| Wow really? That seems like it should move you _towards_
| language oriented tools and away from GUIs.
|
| I use aider + neovim FITM plugin (with qwen coder.) It's nice
| because it not only can help me with code problems but the
| often more frustrating tool problems.
| kashnote wrote:
| Totally agree. I'm a big fan of neovim but didn't find a good
| AI solution that compared to Cursor. Even though I miss some of
| my neovim plugins, Cursor + Vim plugin is pretty hard to beat.
| Ringz wrote:
| imo Claude Code beats all of them. It sucked me completely back
| in my terminal and I love that. Combine CC with MCPs, Tasks and
| subagents if you really want to ,,up the game".
|
| I am on CC pro but I think to get the 100 or 200$ abonnements.
| crmi wrote:
| Really that good? I've got back into using Cursor and if
| seems theyved u1
| timewizard wrote:
| I miss the console terminal where Alt-F# directly selects a
| terminal by index. So: bind-key -n M-F1 select-
| window -t :0 bind-key -n M-F2 select-window -t :1
| bind-key -n M-F3 select-window -t :2 bind-key -n M-F4
| select-window -t :3 bind-key -n M-F5 select-window
| -t :4 bind-key -n M-F6 select-window -t :5 bind-
| key -n M-F7 select-window -t :6 bind-key -n M-F8 select-
| window -t :7 bind-key -n M-F9 select-window -t :8
| bind-key -n M-F10 select-window -t :9 bind-key -n M-F11
| select-window -t :10 bind-key -n M-F12 select-window -t
| :11
| jynelson wrote:
| i see a bunch of people saying things like "you can do this in
| vim or emacs". it's true, you can do fuzzy finding and panes/tabs
| in an editor. but then you are in a box. anything that involves
| interacting with the terminal requires either a dedicated plugin
| or opening _another_ nested terminal emulator (e.g. `:terminal`
| in vim). one of the things i get from my setup that 's not
| mentioned in this post is that i can hit `git show HEAD`
| <highlight files and choose one> <tab> and that will put the file
| name in the command. this works for arbitrary commands, not just
| git, because it works by doing meta-processing on the terminal.
| umanwizard wrote:
| Just to be clear, although you can use emacs from a terminal,
| it's not the default and not what most people do. So a terminal
| emulator opened in emacs isn't really "nested"
| jynelson wrote:
| sure. this still ties you to emacs as an editor though. the
| interesting part of emacs to me is the meta-programming with
| buffers, not the editor itself; i want to be able to plug-
| and-play editors and keep the meta-programming.
| markasoftware wrote:
| to be pedantic, if you're using `tmux`, you're already in a
| "box" and are using what amounts to a "nested terminal
| emulator"
|
| Emacs and Vim are perfectly capable of taking arbitrary strings
| (which can be lines from the same terminal buffer that match a
| given regex) and putting them onto the command line of a
| terminal buffer. And more importantly, you can customize that
| whole process without writing C.
| gloosx wrote:
| When you're working with a computer, you are in a some kind of
| a box by definition.
|
| >interacting with the terminal requires either a dedicated
| plugin or opening another nested terminal emulator
|
| This is not true, you can run any terminal command in vim's
| command mode like :!git show HEAD, you can autocomplete it,
| pipe output where you need it etc without ever getting away
| from the file you're currently editing. You can also use % to
| substitute the current open file path in the command like :!git
| add %
| indigodaddy wrote:
| This is cool and fine, but I just use a browser accessible Linux
| desktop using KASM for a Docker image-based/isolated/ephemeral
| (except for homedir/profile persistence) "local development with
| full Linux desktop" environment that I can use from anywhere.
|
| And for package persistence I have an extra configuration to use
| Brew. It all works beautifully and very fast/no noticeably
| latency on a capable VM/vps etc:
|
| https://docs.linuxserver.io/images/docker-kasm/
|
| https://gist.github.com/jgbrwn/3787259bc7d00fce3fdd4b5bd579c...
|
| https://gist.github.com/jgbrwn/28645fcf4ac5a4176f715a6f9b170...
| jynelson wrote:
| one of the things i want from a terminal is to run things in a
| dev container by default and have an explicit button for
| syncing the changes in that container to the host. the
| difference between this and messing with docker is that it uses
| the host system as the base layer.
| indigodaddy wrote:
| gotcha, so more of a develop locally in a docker container
| and then push/deploy to Prod kinda thing. I like it. Could
| actually do same workflow with a KASM workspace using a
| Docker Rootless image which allows you to use docker.
| benreesman wrote:
| This is a nice setup. It's got tmux and fzf and rg and zoxide and
| clean-looking nvim. I'd recommend atuin, starship, bat, glow,
| duf, dogdns, viddy, gum/sesh, dust, btop et all if you don't have
| them, there's a long tail. The Awesome Terminal XYZ lists on
| Github have them all.
|
| atuin is make-or-break, its a bigger deal than zoxide and being a
| coder without zoxide is like being an athlete with shoes for a
| different sport.
|
| asciinema is a better way to do terminal videos.
|
| Its weird that this is weird now: having your tools wired in used
| to be called "being a programmer". VSCode and Zed and Cursor and
| shit are useful additions to the toolbox, you gotta know that
| stuff by heart now too and you have to know which LLM to use for
| what, but these things are the new minimum, they aren't a
| replacement for anything. Even with Claude Code running hot at
| 4am when the PID controller is wide open, sometimes its going to
| trash your tree (and if it doesnt youve got it on too short a
| leash to be faster than gptel) and without magit? gl.
|
| If you think you're faster than OP with stock Cursor? Get them to
| make a video of how to use an LLM with chops.
| kragen wrote:
| Being a programmer is not about configuring your development
| environment. It never has been. I know a relatively
| accomplished programmer whose preferred development environment
| is Unix with the ex editor, and plenty of beginners whose
| whizbang IDEs completely fail to compensate for their lack of
| understanding.
|
| That's not to say that tooling doesn't matter at all. Just
| that, historically, it's been a relatively minor factor. Maybe
| LLMs have changed that, or are about to.
|
| An athlete with shoes for a different sport might run 5%
| slower. In a winner-takes-all competitive environment, that's
| fatal; a sprinter that ran 5% slower than the gold medalist is
| just another loser. Most programmers, however, win by
| collaboration, and on a relatively smooth fitness landscape,
| not a winner-takes-all spike. Even in winner-takes-all regions
| like startups, failure always results from bigger errors. I
| think nobody has ever said, "My startup would have succeeded if
| we'd used Dvorak keyboards instead of QWERTY", or vim instead
| of VSCode, or vice versa. It's always things like feuding
| cofounders, loss of motivation, never finding product-market
| fit, etc.
| deafpolygon wrote:
| Refreshing to see logic among the sea of your shell "bros".
| smlavine wrote:
| Being a programmer is _absolutely_ about _knowing how_ to
| configure your development environment, though.
| benreesman wrote:
| I find this line of argument really weird. Obviously
| mastering his tools is only one of many things required of a
| master craftsman, but the relentless pursuit of excellence in
| all dimensions of ones craft is the minimum possible criteria
| for ever attaining it, almost tautologically.
|
| It's like when people complain that leetcode is nothing like
| the job: yeah, it's a pretty bad test, but you're making a
| bad argument about that because CS knowledge is extremely
| relevant to the job, unless the job is assembly-line library
| composition.
|
| I've consulted for companies that had all their dev boxes on
| coder or something, and you get really good at vscode really
| fast or you don't have much luck. It's more than 5%, but even
| stipulating that it's 5%, whoa, 5 percent?! By installing a
| bunch of stuff off a list on GitHub and dropping some aliases
| in your bashrc or zshrc? in a few weeks you're _five percent_
| more effective? Anyone in any field from banking to
| bioinformatics would think you were joking or a scam artist
| if you offered them 5% more efficient outcomes at that price.
|
| Regarding OG editors like ed and ex and sam and stuff? I can
| absolutely believe that someone with a lifetime mastery of
| one of those tools could smoke a VSCode user, it's not at all
| obvious that VSCode is an upgrade to vim/etc. along any
| dimension other than low barrier to entry. ditto emacs which
| is about 1000x more powerful than vscode and the difference
| in library/extension ecosystem is not measured by size: the
| emacs one is identical to the vscode one with bottom 90% by
| quality sliced off the vscode one.
|
| And this stuff compounds, you get a bit better at the tools
| and you can read more code faster, read the right code
| faster, start moving the derivative of the derivative.
|
| It's also extremely non-obvious that collaboration at the
| kinds of scales and complexities that make exceptional skills
| or experience in it a top 3-5 core competency for people
| doing most software. Study after study going back to Fred
| Brooks and the Mythical Man Month have demonstrated that
| relatively small teams of people who get along very well
| coordinated by a relatively small number of highly technical
| managers who take the offload on the high-complexity cross-
| org collaboration is the golden ticket. It's the same reason
| computers have dedicated routing tables in the NIC and that
| those things talk to even bigger and more specialized
| machines that do all routing all day: you don't want to scale
| O(n^M) with the communication overhead.
|
| A hacker needs to work really well with their immediate team,
| and have a good dialog with a manager who is both technical
| (to understand the work) and who devotes a lot of energy to
| complex collaboration.
| imiric wrote:
| > I can absolutely believe that someone with a lifetime
| mastery of one of those tools could smoke a VSCode user
|
| > And this stuff compounds, you get a bit better at the
| tools and you can read more code faster, read the right
| code faster, start moving the derivative of the derivative.
|
| I think you're overestimating how much tool choice impacts
| developer productivity.
|
| Yes, using good tools is important. Being comfortable with
| and knowing your way around your toolset will make your
| life easier. But it won't make you a better programmer. It
| won't "smoke" anyone else. It's not a competition.
|
| The time we spend reading and writing code is relatively
| minor compared to the time we spend thinking, designing,
| communicating, and collaborating with others. Reading and
| writing code is not the productivity bottleneck. It's
| understanding what you're reading, making a mental model of
| the system, and thinking about how to translate your
| thoughts into working code. The mechanical aspects of it
| are relatively insignificant. Especially nowadays when we
| have LLMs to automate those mechanical parts, for better or
| worse.
| abletonlive wrote:
| > It's not a competition
|
| For professionals it's absolutely a competition, but I'll
| also agree that engineers overvalue their environment
| setup.
| skydhash wrote:
| the activities with the highest ROI for me has been into
| better navigation and searching, then executing some
| commands on the result. The gap from thinking about doing
| something to having the thing done has been reduced
| greatly.
| helloplanets wrote:
| All completely true. But I also wouldn't voluntarily run a
| marathon in tennis shoes.
| iLemming wrote:
| > Being a programmer is not about configuring your
| development environment.
|
| You sure? Programming is an act of creation. Any [good]
| creative worker - artists, sculptors, novelists, potters,
| bakers, et al. would agree that being an artist means finding
| joy in refining your technique, investing in your tools,
| searching for new recipes, and experimenting. Being a
| programmer is not about achieving better productivity
| percentages. As far as I know, most of the best-known
| programmers have never participated in competitive
| programming challenges. Tooling may not matter to building a
| product, yet the product is built by programmers, and tooling
| is very much everything to them. Good programmers do invest
| in their tooling, not because it's a universal rule they have
| to follow or because it gives them a competitive edge. They
| do it simply because they enjoy the process.
|
| Though it's challenging to determine whether someone who
| loves exploring and refining their tools will excel in a
| specific team, one truth remains: those who don't engage with
| their tools likely aren't strong programmers, as they most
| likely fundamentally lack passion for programming itself.
| williamdclt wrote:
| Meh. You can spend hundreds of hours honing your
| programming environment to get a slight edge on others, or
| you can learn a few basic (or not so basic) soft skills and
| blow most other engineers out of the water because they're
| all obsessed with tech and don't realise it's not their
| bottleneck
| iLemming wrote:
| I'm sure you're not talking "soft skills vs. tools",
| that's a false dichotomy trap - great programmers often
| excel at both, and tooling mastery can itself develop
| problem-solving skills that transfer elsewhere.
|
| We are in a better world today specifically because of
| legendary programmers who invested heavily in tooling,
| and even created their own from scratch. Prof. Knuth
| spent decades perfecting typesetting, made TeX/LaTeX,
| METAFONT, and literate programming tools. Linus built Git
| and maintains his own terminal emulator and scuba diving
| log app among many other things. Ken Thompson is famous
| for building tools to build tools. Rob Pike created text
| editors, window systems and numerous Unix tools. Carmack
| built custom level editors and dev tools for each game
| engine he created, he is known for obsessing over
| development workflows.
|
| Can you name one person who "blows most other engineers
| out of the water" while not "being obsessed with tech",
| using nothing but "the soft skills"?
|
| I dunno about you, I, as a software developer, rather
| want to be like these guys, and I think any aspiring
| software dev would. I spent my last weekend figuring out
| my new WM. Not because I had to, forced to do it, offered
| money for it, or because I perceive it as my
| "bottleneck". I don't fetishize over my tools to "get a
| slight edge". I do it purely out of enjoyment for the
| process, nothing else.
|
| And I have watched many of my peers going through their
| career ladders. Sure, many of them might be perceived as
| more successful because while I was busy "sharpening my
| sword," they went into "the real world" and "touched
| grass" and "talked to people." Most of those are no
| longer doing engineering. If the goal is to "grow out" of
| being a software engineer, sure, then focus on the
| tooling might be overrated. That's not for me though; I'm
| happy where I am.
| cole-k wrote:
| That's kind of a weird point to make. I don't see why it
| would be a universal truth that a good programmer is
| someone who invests in their tools.
|
| I could just as easily say that good programmers are the
| ones who _don 't_ have sophisticated tooling setups because
| it means that they spend more time programming.
|
| I'm inclined to agree with other comments that the baseline
| for productivity is probably lower than we think. It's fine
| to enjoy the process of making a perfect setup, but I don't
| see it as a prerequisite or strong indicator for being a
| strong programmer.
| kragen wrote:
| > _You sure? Programming is an act of creation. Any [good]
| creative worker - artists, sculptors, novelists, potters,
| bakers, et al. would agree..._
|
| Yes, I'm sure. Being a painter is not about decorating your
| studio and choosing paints and paintbrushes. Being a
| sculptor is not about using the best chisels and rasps.
| Being a novelist is not about configuring your word
| processor. Being a potter is not about the selection of
| clay bodies and kiln accessories in your workshop. Being a
| baker is not about where you place your oven or what brand
| of mixing bowls you use.
|
| It's surely true that any accomplished potter will have
| enough opinions about clay bodies, glazes, wheels,
| scrapers, and other tools to talk about all afternoon. But
| that's not what being a potter is about. 99% of potters
| have never made anything as beautiful or as useful as many
| of the pots that Maria Poveka Montoya Martinez coil-built
| from clay she dug up near her house and pit-fired with
| dried cow manure. She engaged with her tools, and I bet she
| would have yelled at you if you left one of them in the
| wrong place, but she wasn't defined by them.
|
| That's what being a potter is about.
|
| It's the same for programmers.
| iLemming wrote:
| I see what you're saying, sure, it's an good point about
| craft and creativity. The essence of any art or craft
| lies in the actual doing - in the painting, sculpting,
| writing, throwing pots, or baking bread - not in
| endlessly optimizing the tools or workspace. It's easy to
| get caught up in perfecting the setup as a form of
| procrastination or because it feels safer than actually
| creating. The real work happens when you pick up the
| brush, the chisel, the pen, or get your hands in the clay
| or dough. The tools matter far less than the practice
| itself.
|
| But, at the same time, sometimes, and quite often,
| working on tools IS the craft itself.
|
| Building, configuring and improving programming tools is
| literally programming - you're writing code, solving
| problems, thinking about abstractions and interfaces.
| Every script you write, every editor configuration you
| tweak, every workflow you automate exercises the same
| skills you use in your "real" work. Understanding how
| tools work (and building your own) deepens your
| understanding of systems, APIs, and software design.
|
| So, in essence, working on your tooling could actually
| make a better programmer out of you. In fact, many great,
| well-known programmers do actively work and maintain
| their tools.
| macspoofing wrote:
| >Being a programmer is not about configuring your development
| environment.
|
| I know what OP is referring to. Back in the day, a programmer
| was expected to have built their own toolbox of utility
| scripts, programs and configurations that would travel with
| them as they moved from project to project or company to
| company. This is akin a professional (craftsman,
| photographer, chef, electrician, etc.) bringing their own
| tools to a jobsite.
| kragen wrote:
| Sure, I have ~/bin and a .emacs.d that I've been working on
| since last millennium. And it's certainly a handicap to
| work in an environment that's unfamiliar, especially for
| the first day or two. Sometimes spending five minutes
| automating something can save you five minutes a day.
| Making grep output clickable like in Emacs, as demonstrated
| here, is a good example of that.
|
| But, on the other hand, time spent on sharpening your tools
| is time not spent using them, or learning how to use them,
| and the sharpest tools won't cut in the hands of the
| dullest apprentice. And sometimes spending five hours
| automating something will save you five seconds a week.
| tmountain wrote:
| Nice list of commands. I would add fd (author: sharkdp) to the
| list. It's a find replacement, and it has great ergonomics.
| Also, atuin is probably the single biggest upgrade to my cli.
| It helps me dig up esoteric incantations that I ran six months
| ago with ease.
| benreesman wrote:
| +1 fd, use it all the time.
| groby_b wrote:
| I think you're overindexing on tools.
|
| A good dev can produce excellent results rapidly in an entirely
| "naked" environment. Sure, good tools might help, but you're
| looking at improvements in the margins - and a lot of this is
| about your personal joy, not productivity.
|
| If the rate at which you generate value is noticeably gated by
| which IDE you use... well, you've got a long and exciting
| journey ahead of you. It's going to be fun, and I don't mean
| that facetiously.
|
| "knowing your tools" was _never_ called "being a programmer".
| Best devs I've ever worked with all did absolutely amazing work
| with more/grep/vi and a lot of thinking. And the thinking is
| where the value was created. That's still true, even if you
| throw an LLM into the mix.
| inetknght wrote:
| I use Linux practically exclusively, and use my terminal.
|
| It's apparently black magic, according to team members. But it's
| _extremely_ productive to be able to develop in a terminal. Not
| only is it extremely productive, but it 's also extremely
| extensible -- you can export your workflow in a script and use
| that same workflow in CI/CD. Running the same thing in the cloud
| and on your local workstation is... beyond productive.
|
| tl;dr: learn how to use vim (or emacs, you heathen!) and you will
| get waaaaay better at writing software. You'll start to miss
| having pipes when you're forced to use GUI apps.
| add-sub-mul-div wrote:
| The title is messed up. It's the most HN-coded thing to take
| something that isn't a problem and overconfidently apply
| automation to it and make it worse.
| 90s_dev wrote:
| Why use consistent punctuation but not consistent capitalization?
| Seems like an odd intentional choice.
| _Algernon_ wrote:
| Another victim of the HN removing "How" from the title. What even
| is the point of that? "I Use My Terminal" is a very different
| title to "How I use my terminal".
| tripdout wrote:
| Are there any terminal emulators that do server-side session
| management without needing Tmux?
| gloosx wrote:
| Don't know about terminal emulators but vim can do this by
| specifying the URL for g:session_directory. Sessions are simply
| files and they can be sourced both from your computer or
| server-side store
| ku1ik wrote:
| wezterm may be something to look into.
| gloosx wrote:
| This tmux stuff is just silly. Everything what is does nvim does
| out of the box.
| commandersaki wrote:
| I do most of this but via neovim using Telescope & live_grep,
| works well enough.
| gylterud wrote:
| Reminds me of Plan 9 with its plumber! Especially when combined
| with Acme, win and right clicking to search backwards.
| politelemon wrote:
| Is this only possible with tmux? Is there a step learning curve
| with tmux?
| cryptonector wrote:
| I use: - one top-level tmux - with a window
| for each workspace - running a nested tmuxsession, one per-
| workspace - for any codebase that can be indexed by
| cscope(1) I run cscope on window #0 of each nested tmux
| session, with - CSCOPE_EDITOR set to a script that
| launches $EDITOR in a new window in the same session,
| titled after the basename of the selected file -
| that CSCOPE_EDITOR script exits as soon it runs the `tmux
| new-window` command so that cscope gets focus back
|
| This lets me use tmux+cscope as a poor-man's _mouse-less_ IDE.
___________________________________________________________________
(page generated 2025-06-23 23:00 UTC)