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 -`.)
msgodel · 4h ago
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.
kannanvijayan · 1h ago
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".
jmbwell · 24m ago
A wise elder once advised me that if I learned to work quickly and comfortably with an application’s defaults, I would be just as quick and comfortable on any system I would likely encounter. Very zen. Great advice.
codyb · 2h ago
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.
johnmaguire · 4h ago
> (`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 · 4h ago
`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 · 2h ago
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).
magarnicle · 53m ago
Is this the same/similar to 'vim -q <(ripgrep --vimgrep restore_tool)'?
robenkleene · 47m ago
Similar enough, minor semantic differences (e.g., I don't think `-q` creates a buffer containing the matches)
benreesman · 4h ago
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 · 4h ago
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.
iLemming · 1h ago
> 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.
cole-k · 48m ago
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.
iLemming · 27m ago
> I don't see why it would be a universal truth that a good programmer is someone who invests in their tools.
I have never said that. However, since you decided to go that direction. I can bite and entertain you. Here is a list of programmers, some of them I'm sure you'd even recognize. Donald Knuth, Rob Pike, Ken Thompson, Steve Yegge, Gary Bernhardt, Paul Graham, Rich Hickey, Bram Moolenaar, Richard Stallman, Anders Hejlsberg, Guido van Rossum, John Carmack, Tim Pope, Drew Neil, Sindre Sorhus, TJ Holowaychuk, Guillermo Rauch, Ryan Dahl, Fabrice Bellard.
The pattern is clear: many of the best programmers are also prolific tool-builders.
kragen · 45m ago
> 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 María Poveka Montoya Martínez 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 · 35m ago
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.
kragen · 27m ago
Yes, I think we agree.
williamdclt · 1h ago
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 · 47m ago
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.
macspoofing · 1h ago
>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 · 39m ago
Sure, I have ~/bin and a .emacs.d that I've been working on since last millennium, and various other tools I've written that I use regularly. It's certainly a handicap to work in an environment that's unfamiliar, especially for the first day or two. And 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. All the work I spent customizing window manager settings in the 90s, or improving my Perl development experience early this millennium, produced stuff I don't use now—except for the skills.
benreesman · 2h ago
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 · 2h ago
> 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.
benreesman · 25m ago
If the time a programmer spends collaborating is more than the time they spend reading and writing code, they are optimizing for something other than software outcomes. And I appreciate that this is one of the lowest points for employment and advancement on the basis of demonstrated merit in the history of the business, maybe that's a smart play for people with certain priorities.
Not my cup of tea. I'm trying to become the absolute best I can be every single day at the absolute limit of my abilities and hopefully just a little bit past them as measured yesterday. I think competence as criteria is going to make a big comeback fairly soon.
skydhash · 53m ago
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.
abletonlive · 1h ago
> It's not a competition
For professionals it's absolutely a competition, but I'll also agree that engineers overvalue their environment setup.
helloplanets · 2h ago
All completely true. But I also wouldn't voluntarily run a marathon in tennis shoes.
smlavine · 2h ago
Being a programmer is absolutely about knowing how to configure your development environment, though.
deafpolygon · 3h ago
Refreshing to see logic among the sea of your shell "bros".
zahlman · 25m ago
> 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
While I get your point, please consider how absurd this sounds to someone who doesn't recognize most of the names.
tmountain · 4h ago
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 · 2h ago
+1 fd, use it all the time.
groby_b · 1h ago
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.
benreesman · 30m ago
I completely agree that being comfortable with basic tools is critical to a versatile software professional because you're routinely in situations where you don't have your kit with you, for every tool on that list there is a GNU userland equivalent that's had basically the same core behavior since the 90s and I switched from DOS and Windows to Linux and GNU, and I am routinely glad that I know how to write useful `find` and `awk` and all that because I'm trying to get some box brought up.
I'm not knocking the classic tooling, it was designed by geniuses who obsessed about tools and tools that build tools (everyone from Ken Thompson to John Carmack are on the record about the importance of tooling).
It's the stock VSCode and Cursor people with an extension or two that are accepting a totally voluntary handicap. Someone in the thread called me a "shell bro", and I mean, that's just asking to get rocked if it's ever on the line against someone serious.
thom · 5h ago
Every vim/tmux user has created an ad hoc, informally-specified, bug-ridden, admittedly probably quite fast implementation of half of Emacs.
grep_name · 4h ago
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 · 2h ago
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 · 49m ago
The only thing missing from emacs is some (opengl) 2d surface api like the browser’s canvas, to rival the rest of the OS.
iLemming · 7m ago
Although I like the idea of having a full-blown graphics engine built into Emacs, I personally don't suffer (at least not so badly) from not having a real web browser inside of Emacs. I can navigate my browsing history¹; I can even (to a certain degree) control my actual browser from Emacs - going through the list of tabs, jumping to a selected tab, extracting content from a tab, inserting the current URL at point, etc. Some of it can be done with AppleScript (on Mac), some of it can be done using Linux tools like xdotool. I browse HN and Reddit in Org-mode; I've recently built a package to search through HN². I don't really need to jump back and forth between my editor and my browser (or many other apps) all the time.
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 · 4h ago
> 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
- 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.
gertlex · 5h ago
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 · 5h ago
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.
cryptonector · 48m ago
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.
pxc · 6h ago
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.
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:
It's pretty easy to get a very nice tmux setup going!
jynelson · 5h ago
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 · 44m ago
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!
jonjacky · 7h ago
The article title is actually "How I use my terminal"
progbits · 6h ago
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.
Stratoscope · 5h ago
Reminder to anyone submitting an article: you have two hours to edit the title to fix these alterations.
rbanffy · 5h ago
I believe these changes are intended to defang some clickbaity titles, but you are right that it maims some perfectly good ones.
littlerbooks · 5h ago
Weird. I see a post titled "How to store Go pointers from assembly" literally three posts below this one.
happytoexplain · 5h ago
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)
indigodaddy · 5h ago
Not quite reject exactly, you can just edit the title afterward for some X amount of time.
Stratoscope · 5h ago
You are correct.
Hard_Space · 6h ago
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 · 6h ago
I use your sudo?
adolph · 5h ago
I use your
sudo !!
osmsucks · 5h ago
I thought this was going to be a blog post about somebody using a terminal emulator they wrote.
philwelch · 3h ago
And I thought this was going to be a blog post about someone hooking up an old fashioned hardware terminal to their PC.
fitsumbelay · 6h ago
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 · 6h ago
HN will automatically trim some common prefixes and suffixes from title submissions
happytoexplain · 6h ago
The entire blog post being in lowercase distracted me more than I thought it would.
gouggoug · 5h ago
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 · 5h ago
that's voice-to-text on iOS, i haven't found a way to turn off the auto-caps yet.
RestartKernel · 5h ago
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 · 1h ago
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.
dr_kiszonka · 4h ago
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 · 3h ago
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?
incognito124 · 5h ago
Huh interesting, I didn't even notice that
furyofantares · 4h ago
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 · 4h ago
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 · 4h ago
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.
o11c · 2h ago
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.
jynelson · 4h ago
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.
gloosx · 2h ago
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 %
umanwizard · 4h ago
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 · 4h ago
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 · 2h ago
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.
klntsky · 5h ago
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
kjkjadksj · 4h ago
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 · 3h ago
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 · 2h ago
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.
agentultra · 5h ago
Emacs is why I can't go back to terminals.
iLemming · 4h ago
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-kitty¹, 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.
I haven’t delved into emacs yet. Don’t you still have it configure it and all its tools?
umanwizard · 4h ago
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 · 4h ago
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 · 4h ago
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.
bowsamic · 5h ago
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 · 5h ago
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™" 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.
b0a04gl · 5h ago
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
msgodel · 4h ago
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.)
jynelson · 5h ago
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.
abnercoimbre · 50m ago
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
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 · 4h ago
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_ · 3h ago
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.
indigodaddy · 4h ago
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:
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 · 4h ago
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.
tomsmeding · 5h ago
> 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 ^[ .
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 · 5h ago
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 · 3h ago
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.
gylterud · 2h ago
Reminds me of Plan 9 with its plumber! Especially when combined with Acme, win and right clicking to search backwards.
enricozb · 6h ago
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.
politelemon · 1h ago
Is this only possible with tmux? Is there a step learning curve with tmux?
magarnicle · 26m ago
If it is not possible with GNU Screen it would be the first feature I've seen that Tmux has over it.
commandersaki · 2h ago
I do most of this but via neovim using Telescope & live_grep, works well enough.
Are there any terminal emulators that do server-side session management without needing Tmux?
gloosx · 2h ago
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 · 1h ago
wezterm may be something to look into.
gloosx · 2h ago
This tmux stuff is just silly. Everything what is does nvim does out of the box.
aftbit · 5h ago
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.
bilalq · 5h ago
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.
inetknght · 4h ago
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.
gricardo99 · 4h ago
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.
kashnote · 4h ago
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.
msgodel · 4h ago
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.
Ringz · 4h ago
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 · 2h ago
Really that good? I've got back into using Cursor and if seems theyved u1
_Algernon_ · 3h ago
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".
midtake · 5h ago
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.
90s_dev · 3h ago
Why use consistent punctuation but not consistent capitalization? Seems like an odd intentional choice.
timewizard · 4h ago
I miss the console terminal where Alt-F# directly selects a terminal by index. So:
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.
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 -`.)
```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.
Care to explain what it does? Trying `ls | vim -` and `ls | vim -c cb -` I don't immediately see a difference.
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).
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).
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.
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.
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.
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.
I have never said that. However, since you decided to go that direction. I can bite and entertain you. Here is a list of programmers, some of them I'm sure you'd even recognize. Donald Knuth, Rob Pike, Ken Thompson, Steve Yegge, Gary Bernhardt, Paul Graham, Rich Hickey, Bram Moolenaar, Richard Stallman, Anders Hejlsberg, Guido van Rossum, John Carmack, Tim Pope, Drew Neil, Sindre Sorhus, TJ Holowaychuk, Guillermo Rauch, Ryan Dahl, Fabrice Bellard.
The pattern is clear: many of the best programmers are also prolific tool-builders.
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 María Poveka Montoya Martínez 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.
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.
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.
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.
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. All the work I spent customizing window manager settings in the 90s, or improving my Perl development experience early this millennium, produced stuff I don't use now—except for the skills.
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.
> 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.
Not my cup of tea. I'm trying to become the absolute best I can be every single day at the absolute limit of my abilities and hopefully just a little bit past them as measured yesterday. I think competence as criteria is going to make a big comeback fairly soon.
For professionals it's absolutely a competition, but I'll also agree that engineers overvalue their environment setup.
While I get your point, please consider how absurd this sounds to someone who doesn't recognize most of the names.
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.
I'm not knocking the classic tooling, it was designed by geniuses who obsessed about tools and tools that build tools (everyone from Ken Thompson to John Carmack are on the record about the importance of tooling).
It's the stock VSCode and Cursor people with an extension or two that are accepting a totally voluntary handicap. Someone in the thread called me a "shell bro", and I mean, that's just asking to get rocked if it's ever on the line against someone serious.
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.
___
¹ https://github.com/agzam/browser-hist.el
² https://news.ycombinator.com/item?id=44264368
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.
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).
> 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.
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!
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!
(I could be wrong about that)
(In case not obvious, current title is 'I use my terminal')
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
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.
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.
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.)
>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 %
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.
- 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-kitty¹, 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.
___
¹ https://github.com/agzam/.doom.d/blob/main/modules/custom/sh...
No comments yet
That said, yeah, it certainly doesn’t Just Work out of the box the way something like vscode does.
Trying to bootstrap a Python setup "that just works™" 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.
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
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.)
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)
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.
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...
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.
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.
I’m guessing some people already have these capabilities integrated into terminal workflows and I’d love to see a demo/setup.
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.
I am on CC pro but I think to get the 100 or 200$ abonnements.
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.