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 -`.)
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.
That would be true if you had universally great designers back then, which wasn't the case, thus the defaults are universally bad, so it's a bad heuristic to stick to them and force a waste in trying to understand them.
For example, why is the default vim cursor hjkl? Well, it's just that the arrows on the physical keyboard of one of the vim designers were drawn there. That's it. There is no deep thought in search of the best cursor position, and understanding the why is just learning a useless piece of trivia.
That seems quite harsh. Just because the designers aren’t perfect doesn’t mean the design is universally bad.
To address your example: Why were the arrow keys on those particular keys? Who put them there? hjkl are on the home row, and touch typists end up having the movement keys under their right hand’s resting fingers. That’s suddenly quite convenient.
> and touch typists end up having the movement keys under their right hand’s resting fingers.
This is false, h isn't in the resting place. So go back and spend more time trying to explain that historic tidbid of design before trying to defend it (I'd also be curious to know why they shifted left instead of using resting places)!
Or don't and use this obvious principle directly and change keybinds to jkl;
Or go with the muscle memory of inverted T and use ijkl
But whatever you do, prioritizing the original design is a common bad heuristic because there is no reason to think that the original designer was great (not perfect!, don't twist it), so trying to understand the original reasons is a waste of "productivity" time (but if you're curious, it's not a waste of regular time)
As pointed out, this is wrong. What touch-typists want is jkl;, because the right home key is j. This is an absolutely necessary config change in vanilla vim, unfortunately.
For me personally is the J/K direction still feels swapped and I always have to remind myself they are in fact the other way round. Even (especially) for touch typists, I would really expect [k] to point down and [j] up. In our writing system from the top left to bottom right my intuition would really be to stick ↑ with ← together and vice versa ↓ with →.
← ↓ ↑ →
makes a little sense to me.
← ↑ ↓ →
would be way better, IMO.
Not only because the most used used direction (↓) would be closer to my "neutral" finger position, but mainly because the the keys for progressing "back" and keys for progressing "forwards would be grouped together.
Honestly, I wouldn't even mind having them spread across two rows, like U I J K
↑ ↓
← →
or something. (Personally, I have global WASD-like arrow mapping bound to IJKL through capslock combo in AutoHotkey, since sometimes cursor keys are really inconveniently far away when typing.)
I think the current system is the way it is in order so that the most used direction (down) uses your strongest finger, the index finger.
I don't know what your mean by "Not only because the most used used direction (↓) would be closer to my "neutral" finger position" - what is your neutral finger position?
I also got lost in the sentence about "back" and "forwards" - what is back and forwards?
Sorry, I didn't realise that was unclear. By "back" and "forwards", I mean movement through the flow of text relative to the cursor position. Given any reference point in linear text, all surrounding content either precedes or follows that point. Moving through preceding content is "going back", and moving through following content is "going forwards". When we move to the preceding line (↑) or preceding character (←), we're going "back". When we move to the following line (↓) or following character (→), we're moving "forwards". My point was that ← ↓ ↑ → effectively represents "back one character — forward one line — back one line — forward one character", which feels counter-intuitive to me.
> strongest finger, the index finger.
Interesting. As far as I now, middle finger is usually considered stronger than the index finger. Index finger might be more dextrous, though (?). Personally, I also slightly prefer the middle finger for rapid pressing over the index finger, but cannot see strong definitive advantage of either one. (I guess most of us use the middle finger for regular ↑↓ keys, as well as W/S in WASD bindings in games/project just fine, and using index finger in that context instead would feel odd.)
> what is your neutral finger position?
Mostly index finger on "K". (So I guess I'd prefer having "down" (being the most frequently used when VIM binding is involved) on "L", where my middle finger usually dwells, and "K" for moving up, if I had to invent it from scratch.)
I like the bindings, because I move vertically more than I move, so I want my strongest (other than the thumb) there. And I move to the right more than I do to the left. So I don’t mind moving my finger to do the latter.
It may be different based for others based on hand anatomy, but at least for me the index finger is so much stronger than the little finger, that it feels more comfortable moving it one space to the left, especially on keyboards with heavy keys (like model M).
I will admit that I had never considered things like this (there's a couple of you making a similar point). It's a decent argument. Maybe I'll revert to the default and see if I can handle the change.
As a touch typist that learned decades before learning vi, with Emacs in the middle, I can definitively say your blanket statement is false. And as a recovering Emacs user, I can also say the little finger thing for a repetitive key is a dangerous proposition with real potential health drawbacks.
The fact that the tools have survived and are still used today is at least somewhat indicative of their quality though. A lot of worse designs have likely been selected away due to nobody even bothering to use them.
P(old thing being good | old thing still being used after N years) is pretty high. Certainly higher than the base rate of P(new design fad being good).
> defaults in old software are almost always there for a reason
Keeping your fingers on the home row is great design for keyboard-first navigation.
All software design is historically contingent so you do have a point but assuming that old design = bad design is just wrong. Some things haven't changed.
> Keeping your fingers on the home row is great design for keyboard-first navigation.
Except you've just made that reason up since vim's defaults don't follow this logic. For example, the most frequent commands of going back/forward by word are not on the home row, they follow a different principle of name-based mnemonics.
Strictly speaking, this isn't even true for hjkl, that was due to the fact that arrows were drawn there, not because the designer followed some good design principles (granted, at least the physical arrows were likely driven by that principle, though there is still a mistery of moving off resting/home keys, which might be related to the fact that cutoff ASCII H code is backspace https://news.ycombinator.com/item?id=3684763).
> Some things haven't changed.
Indeed, and that universal fundamental thing that hasn't changed is that a few random people doing design blindly can't universally create a world of good design!
Yes, they are not in the resting position on the home row, but they are close enough for a command you will be executing often. Crating a key-map is an optimization problem between memorability and ergonomics.
Vim command layout is not perfect, the worst offender in my opinion is $ (move cursor to the end of the line), which is commonly needed, but somewhat hard to reach.
HOWEVER - when you start to use an surviving piece of still used old software, a bit of humility goes a long way. Not because software or designers were necessarily better in the past, but the reason that the software is still in use is probably because there are some benefits to it. So learn the defaults first, modify later when you understand them.
> they are close enough for a command you will be executing often
Right, just like w/b are "close enough" outside the home row completely
> but the reason that the software is still in use is probably because there are some benefits to it.
You forgot to connect this principle to this discussion. How does it make the defaults good to support your faulty conclusion that you need to learn them first?
> Right, just like w/b are "close enough" outside the home row completely
Yes, they are close enough, and w/b are executed often.
> How does it make the defaults good to support your faulty conclusion that you need to learn them first?
You need to at least study them because assuming a priori that they are either good or "universally bad" is a faulty conclusion - and some stuff doesn't become obvious until you use them for some time.
When you start learning VIM, you will be faster with arrow keys, because you are used to them from other programs. When you get enough muscle memory, you may discover that there is some value in having somewhere near where your fingers rest on the keyboard - or maybe you will still find that you are faster with arrow keys - whatever the conclusion, it can not be made objectively before you have enough proficiency with both.
... one still can't correct the fault. You haven't answered the question of the original disconnect in arguments.
Your new arguments aren't relevant either since they're also NOT connected to the original re. bad defaults. You can have bad defaults that aren't there for any good reason and still think that reducing maintenance is more valuable! Fine, but that's a different argument!
Lets go one level deeper: What's the reason that the vim disgners keyboards had hjkl as arrow keys? Because it made sense for it to be the home row. I still use arrow keys though
No accounting for taste, but my similarly terse vim config includes relativenumber and number. Relativenumber is just so damn useful for doing things to larger chunks of code without having to count lines or anything.
I'm also an IDE user though. I tend to maintain a dichotomy between emacs(with evil-mode, of course) as the "kitchen sink" set up, with all the fixings, and vim with a config so short I can type it in as commands if I need to.
Vanilla vim is really perfect for quick edits to config files, scripts on random servers/VMs etc.
Bigger projects, at least for my usage, all happen on the same system , and having a bit more involved of an emacs set up makes sense there.
I suppose one could do a similar dichotomy with vim/neovim, if one had a distaste for emacs.
… why `memory commit` what you can `git commit` and then just `git clone`.
(I keep most of my dotfiles in a repository called "dotfiles".)
I get the emotional value/desire for a minimalistic .vimrc, but I also need the usefulness, and that necessitates, e.g., pulling in some plugins. E.g., lang-servers are just so valuable for immediate feedback in the editor.
Over time, someone of my vimrc has been pruned away just by development that has happened in/on vim itself, which is always lovely to see.
I've done it. It was terrible. I'm glad the project ended.
There's no fixing it, though. I can know the "base tooling with zero config" … and I'm just less productive, that's all there is too it. Customized tooling makes me faster than the base tooling. (I did start trying to find "inventive" ways to try to work around the problem, of course. My case wasn't like military air-gapped or anything, just the only connection was via RDP. So for example, copy & paste is a communication channel.)
I mean there is a middle ground. LSP is good for coding a project. But I do agree with your point. What I generally do (as nvim user) reduces plugins to the bare minimum and try as much as possible to do progressive enhancement (atleast I try). Maybe as nvim improves LSP, I hope the diff between LSP and native methods are close enough that they both work.
I would love a generative llm script that looks at my command history (or something comparable), and adds a new zsh config (or other dotfile) every day, explaining itself via a reliable motd-type screen that flashes on-screen during the first session of the day, explaining what was added and allowing me to play with it and decide to keep it or not by the end of the day :)
Basically, slowly "evolving" my environment by forcing me to try new things daily, without my doing massive "learning" runs where I try batches of new things at once
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.
Seems like using a tool to its fullest potential to get more work done is better advice.
> I would be just as quick and comfortable on any system I would likely encounter.
How often are we encountering other systems…? And even where I am rarely ssh'd into something else … are we doing so much editing of code (live in production…?) that it matters? (I heavily customize my vim, but it isn't like I'm lost on a remote system with stock vim, or nano. ed is another matter.)
But if I need tons and tons of editing, … sshfs+local vim/terminal? But this just such a rare case, it seems like one of those "we should optimize for the common case" — which this is not.
I see it more as like understanding how to use a hammer even if most of the time in your job you use a nailgun.
For me personally it's a classic old timer habit from the days when you had to be prepared to fix a system using only the tools in /sbin. That doesn't mean you should operate like that all the time, but you should certainly know how to do so and be comfortable doing it.
Isn't the author likely to know the tool's potential best? I get that there are special cases but those should be few and ones you know well enough to memorize the exceptions for.
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.
Some defaults suck massively, emacs in tmux basically doesn't work due to hijacking C-b. The one that catches me every time is whatsapp that hijacks C-p.
`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).
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).
I can't help but see it as the tiling window manager of text editors.
Even with plugins it's less featureful than Kate or Jetbrains IDEs. And the last time I really gave it a go, it was slow, which is surprising for a terminal text editor.
If I need to edit text via the terminal, micro has mouse support and keybindings that match what you'd expect in any OS.
I don't like the idea of thinking people who use vim are insane, it obviously has value and people who use it have good reasons for using it, but I can't see it as more than a niche nerd thing a la tiling window managers.
I use both (neovim instead of vim, i3 as wm) and you got me thinking. I think the point of both is actually not having to use the mouse. But the mouse is not the problem per se, probably is the spatial/visual interaction paradigm. I don't care where the window exactly goes, I just want it right/on top/minimized. I don't want to search visually for a button that does what I want, I know what I want, I can just "tell" the computer. It's not about keybindings as shortcuts to do something, it's talking to the computer via keyboard using my language center without the intermediary of the gesture/spatial metaphor. Maybe? I just thought of this sorry.
It's this. I make the analogy to playing a game with a controller. At some point you stop thinking what combination of physical button presses and holds you need to have your character go from a running start to a crouch-jump, you just think in terms of goals for you want your character to accomplish. vim motions put you in the same sort of connection with the text you're editing.
> And the last time I really gave it a go, it was slow, which is surprising for a terminal text editor.
There was likely something wrong with your configuration. It's really hard to be faster than vanilla vim, but you can get weird performance issues from external plugins sometimes.
I used some Vim IDE plugins and I assume the bottleneck was there.
The problem is without some IDE-like features, I don't have a need for a text editor. Micro supports LSP servers by default and that gets me pretty far, before jumping to Kate or a real IDE.
The question is which plugins you used. My neovim configuration gives me "IDE-like features", yet it's noticeably faster than VS Code and others. Also, neovim has native support for LSP too.
I think the sort of person who likes it values the "test of time" aspect of it and trust that vim will still be there in the next three decades, just as it was there for the last three. It's super easy to install, and is indeed preinstalled on almost every Linux installation. So people can learn its ins and outs and do extremely fine-grained customization to their desire. People who get annoyed by tiny details and don't want to put up with it. The downside is that you need to carry around your config files and if you sit at a colleague's computer you don't get the same standard experience. And the fragmentation.
There's of course also the "hacker street cred" aspect of it, to feel like a real serious developer. Or simply being fed up with churn and saying "I'm too old for this shit". JetBrains IDEs might change next year due to some new design fad. Or they may go bankrupt.
In my opinion, valuing boring old tech is good, but you shouldn't make a crusade of it. I choose to put up with some churn and inevitable tool changes for practicality. Yeah, some things have to be relearned this way, some changes seem pointless, but the overall effort may be less if you just learn to be flexible and say "ok if JetBrains goes bankrupt, I'll just learn the next popular IDE like everyone else and be done with it" instead of prepping in my bunker with my vim config files.
Vim existed before Jetbrains IDEs. It’s also much more general. I use Vim to write literary works and manage my knowledge base. There was also a guy who was using Vim as his IRC client. Vim can be the only program you need for editing text, which turns out is most of what we do on a computer. It’s nice to have a single tool for this, that never resists when you try to adapt it. Vim is actually a great example of the practicality of a good philosophy.
Edit: I doubt there’s any feature in the more specialised editors, which you can’t also get from Vim.
This is cool, I learned about `:cb` today (populate quickfix from current buffer)
I find that if I’m already piping into a buffer, I just leave it as a buffer. Vim’s gf and gf keybindings let me jump to the filename under the cursor, and it being a buffer makes it easier for me to edit (reorganize, group, further filter, etc).
I do think people undervalue the quickfix buffer though!
"rg --vimgrep restore_tool | vim -c cb -" looks like I want to use it. However, it doesn't work for me. vim says it had errors while processing, and says I haven't saved the buffer. I get the rg result displayed, but how do I navigate to a place?
The quickfix window is so small, so I added the "-c only" option to make it the only window that first pops up. Then made it a function so it's easier to call:
```
vgrep() {
rg --vimgrep "$1" | vim -c cb! -c copen -c only -
}
```
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.
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.
> 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.
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.
> 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.
I don't even understand what point you are making. The essence of programming is tool making. Of course the best programmers make tools as do the worst. Are you seriously comparing making a terminal hot rod configuration app to, say, creating Tex?
> Being a programmer is not about configuring your development environment.
My point is that being a programmer is also about configuring one's development environment. Exactly because like you said: "the essence of programming is tool making". I just don't understand how it is different - configuring a tool, extending its functionality, adding more features to it from developing a [different] tool from scratch? Both is programming. Shit done by programmers. You don't call one bunch "pseudo-programmers" and the other "alpha-programmers" or some shit like that, right?
Then I misunderstood your comment. I read it as "not invested in their tools => not a good programmer."
Reading the replies to my sibling comments, I don't think we really disagree but we probably have different pictures in our heads when reading the context of this thread.
> 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.
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.
Not in enterprise consulting, there is very little room for creation on the software sausage factory, it is all about social skills, and outputing something that mostly works within the project budget.
The craftmanship is better left for small businesses, or FAANGS with engineers playgrounds.
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
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.
These famous people you cite are famous because they are "devs for devs". These guys were working on a _product_ (be it LaTex, games, text editors...) for which the user happened to be developers: by improving devx a little they had a lot of impact. That has little to do devs with individually spending a lot of time on their own tooling (for whom improving their devx a little has a little impact).
> 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"?
The best engineers I've worked with were comfortable with their tools (of course, that's a requirement) but wouldn't be spending much time on incremental improvements. They'd spend time talking to customers, to PMs, to support, to leadership, learning about their domain and about how other engineers in the industry approached it. They _would_ spend time investing in tools that might be a game-changer (10x or whatever), but not things like vim configs and keyboards.
It always comes down to the same thing: you can have the best tech skills and tooling, yet a (decent) engineer who understand the domain and can communicate effectively will build a better product than you. That's hardly controversial.
> That's not for me though; I'm happy where I am.
I don't agree that it's a question of "growing out of engineering" at all (in fact I'd say it's "growing into" engineering from programming), but at the end of the day I'd totally agree that you should do what makes you happy! If you enjoy what you do and don't want to be doing the other stuff, who cares, I certainly won't be the one to tell you to change your ways!
> The best engineers I've worked with were comfortable with their tools (of course, that's a requirement)
Yeah, that's all what I'm saying.
> but wouldn't be spending much time on incremental improvements.
What is "an incremental improvement"?
My tools change depending on the work I do, and it so happens, the type of tasks I do sometimes change. When I say "working on tools," to me it's like knife sharpening. Sure, it's not impossible to cook with a dull knife, but it's helluva uncomfortable; why just not sharpen it? For me, it's like a chore I can't avoid, the only choice I can make is how to respond to it - and I choose to enjoy it. It takes less than two minutes to sharpen my knife - I have an electric sharpener. It's not tiny, but small enough so I can hold it in my hand, and it's not expensive. I also have regular sharpening stones. That process takes longer. I think I enjoy it, why not; it feels like meditation. But I don't do it every day, or even every week. I think I like how knives feel after.
So basically, I don't even understand what we are arguing about. Some engineers like extending the tools they use. Some, maybe not so much. Some spend a good amount of time doing that. They do it because they love it, and there are mostly benefits.
Some don't sharpen their knives at all - they simply throw them away and buy new set - I just don't know anyone like that in my circles. And similarly, I have never met engineers who never cared about improving their tooling even a little bit.
At the end of the day, we can probably all agree that doing the work without nicely "sharpened" tools is like cooking with a dull knife - it's not impossible; it's just why would anyone do this to themselves? It sounds anguishing.
>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.
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.
> 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.
If you enjoyed the process it was time well spent.
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.
> 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.
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.
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.
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 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.
Few hours later, 2 of these tools are in the front page of hackernews. So it's not that absurd! Sometimes you can just reference stuff here in the comments in order to summon them.
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.
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 ;)
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.
I'm aware! I used emacs exclusively in professional development roles for years. I still use it for a handful of things that nothing else can touch emacs' workflows for.
That said, there is something nice about composing simple programs and keeping things small. With vim + tmux, I have terminal multiplexing and text editing done and haven't touched that configuration in at least 5 years for vim, over 12 for tmux. I know they offer 'less functionality' out of the box, but after years of tweaking and tons of installed packages I was never able to get that same functionality in Emacs, try as I might.
The main pain points were:
- Not having tmux's <c-b z> functionality. You can kinda-sorta-almost jerryrig it with some custom bindings and winner-undo, but you'll still have weird edge cases to think about because you're technically doing a weird undo-tree thing, and all the context (projects, windows, buffers, etc) that emacs maintains will have something to say about that.
- ACTUAL vim emulation. Evil mode is really not good enough, and I never had a package that was so hard to integrate without bugs, and when it breaks you have to usually peel back a massive layer cake of competing configurations to try to make it work. Even then, evil-magit has tons of issues, the dot operator doesn't work correctly, and none of the ctrl-i/ctrl-o plugins work across enough contexts to make it make sense like it does in vim. That's a killer feature for me
- Embedded terminals that feel anything like tmux in wezterm. In the emacs terminals, there was always so much shit going on navigating in them (and again the layer of evil there) that it felt like walking on egshells using them, they tended to have performance issues and usually couldn't run TUI programs properly. I ended up having a separate drop-down terminal I used in tandem with emacs
- Process management. It was always a huge headache for me keeping track of the processes Emacs was spinning up / down through its various plugins and debugging them.
I'd say most tmux+vim setups have something more like 0.00001% of emacs implemented, but sometimes that's a good thing. And again, I love and use both setups for various things.
What the heck are you even talking about? (delete-other-windows) command existed since at least Emacs 18 (released in 1987).
Okay, yeah, I get it, you're complaining that Emacs sorta lacks a dedicated "zoom toggle" that cleanly saves your exact window layout, maximizes one window, then perfectly restores the layout when toggled again. I personally never had any problem with my (toggle-maximize-buffer) command that builds on top of (delete-other-windows)
But do you even realize that you're comparing a bicycle to a Bugatti Veyron - tmux is a simple pane grid with position/size and Emacs windows carry much more state. There are buffer associations, point positions in each buffer, window-local vars, display parameters - margins, fringes, etc., there could be integrations with modes that manage window layouts, there are multiple abstraction layers - framers, pos-frames, buffer display rules.
tmux can get away with a simple layout save/restore because panes are just rectangular terminal regions.
> Evil mode is really not good enough
Ha, I'm a die-hard vimmer, and I laugh at this sentiment. You, my good Sir/Madam/etc., respectfully, have no idea what you're talking about. Evil-mode is the only ACTUAL vim emulation outside of vim/neovim. There's no such thing as a "vim emulation". And I've tried them all - different ones - IdeaVim for IntelliJ, Sublime Vim plugins, VSCode extensions, etc. All of them are pretty much filled with laughable deficiencies; they are not even shadows of the actual Neovim
experience. With one notable exception, and that is the vim-implementation in
Emacs. In Emacs, Evil-mode doesn't even feel like an extension, an afterthought;
it feels like it's a baked-in, major feature of the editor. More than that, it
can do certain things even better than you can do it in Neovim.
Anyway, it seems you're complaining for just the sake of complaining, without any evidentiary input. Like I said before, it's of course absolutely obvious that things of lesser capacity will have smaller surface area and thus would feel more stable.
What would be your reaction if I say - my bicycle of 15 years has never needed an oil change or brake fluid drainage. My new car in comparison, is so much more complicated and requires constant attention? You'd probably laugh and call me names. I hope you'd realize how vain this kind of argumentation is - comparing things of completely different caliber.
This is a very haughty response, I hope you realize that. Yes, (delete-other-windows) does exist. It's so far from the buffer zoom toggle I'm talking about as to be completely unrelated.
> Anyway, it seems you're complaining for just the sake of complaining, without any evidentiary input.
I have given multiple specific examples of every claim that I made. HN's formatting did make my comment difficult to read, but the content is there.
> But do you even realize that you're comparing a bicycle to a Bugatti Veyron - tmux is a simple pane grid with position/size and Emacs windows carry much more state.
Yes, yes, this is exactly what I'm saying. It's cumbersome and much more difficult to maintain. There are reasons to like both things (and I have repeatedly made efforts to re-iterate that I do like both options and use both for different purposes).
Your screed about how great evil-mode is does not address any of the specific issues that I have and was never able to resolve wrt using evil-mode in emacs.
> What would be your reaction if I say - my bicycle of 15 years has never needed an oil change or brake fluid drainage. My new car in comparison, is so much more complicated and requires constant attention? You'd probably laugh and call me names.
Incidentally I wouldn't, especially if your bicycle worked for your lifestyle and the constant attention and expense of motor vehicles factored into your decision making process. That's neither here nor there, though, because I happen to own both a bicycle and a car, and I never made the argument you seem to be fixated on. Like my car and bicycle, I use both a tmux / terminal app based workflow and emacs in different contexts and have swapped back and forth between the two at different points depending on my mood and what I'm doing. Sometimes I even (gasp!) discuss my experiences with the two tools in a comments section.
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
- 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.
it also doesn't quite work with macOS remotes usually.
again, not purely TRAMP's fault, but a default config and habits issue with ~/.zshrc vs ~/.zprofile and maybe /etc/sshd/config settings, i think. i hasn't fully figured it out yet.
using this kind of "full-screen terminal screen sharing" approach has a more predictable experience, because of the amount of data transferred is usually 1 screen worth of characters (and colors) max, on most keystrokes.
that's both a pro and a con.
it imposes a fixed, network connection dependent input lag and the output is also often redrawn by retransmitting the same data over and over again...
I even wrote a little terminal emulator turn my 2-key tmux prefix into the single-key ctrl modified for every command, including the ones that are normally impossible on other terminal emulators
"i don't use Nix partly because all my friends who use Nix have even weirder bugs than they already had and partly because i don't like the philosophy of not being able to install things at runtime."
The first part is mostly true. Nix installs things in a readonly store (/nix/store) so regular dynamically linked binaries don't work. Packaging takes a different approach and when things break, it can be difficult to work around. That said, I've run NixOS for over a year now and I find the benefits are far preferable to these downsides. It's not often I run into bugs, let alone show-stopping ones. What is annoying is how many tools are distributed without the source, so I have to run patchelf on them or use something like nix-ld.
As for the latter part, I think that using Nix will change that mentality. (Note that you can do `nix-env -iA $pkg` but it's not recommended). See, I don't even install things like rust at a global level anymore. I can always do `nix-shell -p $pkg` for an ephemeral shell if I need that, or I encode that dependency directly in the project's flake.nix. If I end up using that program a lot I will make the effort to add it to my NixOS config.
"at runtime" is not the same as "globally". i would love to install things locally at runtime, but the nix evaluator can't manage things that aren't packaged through a nix derivation, and i don't want to have to figure out how to package a random tool on the internet just to be able to run it at all.
Ah I misunderstood. Yes that's a bit more complex. Your options boil down to a) using pkgs.autoPatchelfHook [0], b) learning some nix and writing a derivation yourself, c) using nix-ld [1]. There's also pkgs.steam-run which provides a typical environment expected for games.
A great deal of things are already packaged, but for the most part I find it pretty fast to package something. Once you write a derivation [2] or two, it's not that bad. I never packaged for other distros because they all seemed quite tedious, but the nixpkgs reference [3] lists most things and I can look at the source of similar packages in nixpkgs. It is a time commitment though to learn so it's understandable that it's not really appealing.
I use Nix exactly because it doesn't allow installing things at runtime. This keeps me from hitting surprises where the runtime environment changes from under me. Containers can partially solve this problem as well but have their own usability issues.
Nowadays I start every project with `nix flake init --template templates#utils-generic`. And put everything in that related to the project. I even had some projects where I had to put 'ssh' as a pinned package as it was used in some scripting and the default macOS and Linux versions accepted different flags.
I also do love that I can do something like `nix run nixpkgs#nmap` on any machine I'm on to instantly run a program with worrying where to get it from. I also use this feature in some of our projects so you can click a link in the admin web interface which is a 'command url' for iTerm2[0] like: `nix run gitlab.com/example/example/v1.0 -- test http://example.com` which will prompt to run that specific version of the command in your terminal, without have to checkout the source repo. In this case it is to rerun specific task locally for debugging purposes.
My similar trick is to rely on the tmux scrollback and pipe tokenized output into fzf so I can easily autocomplete in zsh against anything on the visible tmux screen
As someone that was happy that I could finally afford owning computers with a graphics display on them, this going back to the terminal doesn't stop surprising me.
We still do horses, but hardly anyone is favouring them for travelling around the continent delivering mail.
Kudos to the people that would rather experience that, I guess.
My thing is that most UIs use such poor use of the screen real estate. I get it, pretty is the priority. But when I want to do work, the padding on everything gets to be excessive. Additionally, it’s really nice to be able to host my dotfiles in GitHub and I can be in a 100% familiar environment within a couple minutes. I have a variety of machines I work on. Same thing goes for mouse usage. I’m much faster operating the keyboard, whereas I switch between mice and trackpads and sensitivities when I switch devices. Keyboards are mostly the same. Maybe it’s a skill issue on my part but oh well ;)
My issue with the terminal is the exact opposite, everything is monospaced, hard to read, and space-inefficient due to that. Keyboard use is not a terminal-only thing either, it's a problem with some modern UIs that are hostile to power users. I feel it's at least partly because power users that create their own tools removed themselves from serious GUI development and are too busy with fancy TUI doodads and dark themes instead.
I feel like the point of monospace is to be easier to read in text dense environments. I find it much easier to read a monospaced font in the terminal and it makes editing commands much nicer to work with.
The point of monospace is easy vertical alignment in code, tables, logs, and many other types of text. But you definitely lose fast visual shape acquisition and potential density of proportional fonts. CLI is fine conceptually, I'm talking about TUI which is different.
The point isn't really the lack of graphics, it's more about the use of a keyboard and text as a universal data format.
Graphical programs look nice but are a nightmare for interoperability.
Having said that, as an Emacs user I'm surprised that anyone goes to this much effort to not use Emacs. This is what it's made for and it's all built in the most hacker-friendly way imaginable.
It's difficult to express how amazing Emacs is to someone that hasn't used it long enough to really learn it. I used vi for 20 years before switching, and I'll never go back, but the me then just didn't realize what Emacs could do for me.
Yeah, I've given up trying to be evangelical about Emacs. It makes me think of the red pill in the Matrix: noone can be told what Emacs is, you have to see it for yourself. People who want to take the pill will find someone like me to help them, but it has to start with them, not me.
Back in '05 I realised how crazy it was that everyone was using these shitty editors built in to bloated IDEs, all slightly different from each other. It's all just text! This caused me to discover vim and Emacs. This was about 10 years before editors like Atom and then VS Code caught on.
I tried vim for a while, did the tutorials and tried to believe that if I practised the keys I'd become a wizard. But it never paid off. But I'm glad I learnt to enter insertion mode and exit vi/m at least.
Emacs was not presented as well back then. It had (has?) a terrible looking GUI by default. But once I'd switched that off the keyboard interface and major/minor modes made so much sense. No surprise that VS Code uses the same model.
But then when I got into Elisp I can say I truly fell in love. I liked GNU/Linux before, but Emacs is what Free Software was always meant to be. Not just technically hackable but practically so. How many people edit their VS Code plugins to do exactly what they want? With Emacs you can hack everything right there in Emacs while it's running and then just go right back to where you were.
What languages are these systems based around? Maybe Lisp has something to do with it? I've been drawn to things like Guix and stumpwm for this reason. It would be a dream to have an entire OS built on a Lisp.
The horse and car comparison really doesn't work since if anything terminals are higher performance and efficiency than guis. They just have a learning curve and no eye candy.
> We still do horses, but hardly anyone is favouring them for travelling around the continent delivering mail.
Most alternatives are much faster, easier to use, and more reliable than the horse. Just like the terminal, in fact: your metaphor was prefect, you just had it the wrong way round :)
You can't possibly argue that a terminal is easier to use than a GUI.
It's literally what brought computing into the mainstream, so you can click options that are presented to you rather than memorize a bunch of incantations.
I started coding using Borland Pascal on DOS. I went through many tools and in the end split the terminal / UI work depending on whether the language is actually bound to an IDE or a build system.
E.g.: not using Xcode for iOS dev doesn’t make much sense to me. At work we have a fully set-up IDE that works with our build system. I like QtCreator for C++.
But for web dev, scripting and blog writing, I find programs like VSCode extremely slow even with just minimal plugins. After a couple of years I got fed up and went back to vim in terminal.
> As someone that was happy that I could finally afford owning computers with a graphics display on them, this going back to the terminal doesn't stop surprising me.
GUI is not a superset or complete replacement of TUI. For many reasons, one of the reasons is that GUI is much harder and finicky to automate.
Every command can be manipulated as text and repeated as many times as you wish. Every command is also stored in the history, can be saved to any notepad for future, shared with the community.
Every GUI automation is highly non-standard, ad hoc, finicky (usually, depends on exact pixel positions), possibly Turing complete, but even if it is, it's harder to use compared to writing a script.
Wait, you're describing CLI: command line and infinite history. TUI is a distinct thing, it exists on an addressable 2D character grid instead of the bitmapped canvas. For example top and mc are TUI applications, but there's no command line in them (unless you count passing different parameters from the external CLI or a script, which you can also do with a GUI application as it's separate from the interface).
> Every GUI automation is highly non-standard, ad hoc, finicky (usually, depends on exact pixel positions), possibly Turing complete, but even if it is, it's harder to use compared to writing a script.
The same applies to TUI applications. How do you automate top or mc? Don't conflate presentation (which is silly to even attempt automating) with internal logic.
The entire reason for TUI to exist is that TUI apps can be used in a terminal window, alongside CLI, so you don't have to switch to a separate window. But fundamentally it's just "GUI on a character grid".
I think its more like walking. For some things walking is preferable to driving there. its even less effort for things that are nearby, it uses fewer resources, I can do it after having drink, I can go through places that are not accessible by car (foot paths)....
Same here. I'm also amused that the people that do like the experience haven't by this time replaced the protocol (termcap entries, escape sequences, etc) now that memory sizes and network speeds are many orders of magnitude higher than they were when the protocol they are using was designed.
Depends on what you do, really. If I need to edit a photo, of course I’ll use gui. For any kind of text manipulation, including coding, tui is simply superior.
> We still do horses, but hardly anyone is favouring them for travelling around the continent delivering mail.
Except that if you've ever seen someone who truly knows how to use a terminal, you'd be surprised how many times faster he can work than with any other UI-based workflow.
This may change with AI, but so far I'm not holding my breath.
Literally twenty minutes ago, I had to submit several hospital invoices for insurance claims. The website, despite claiming it'd accept PDFs, didn't consider the PDFs I uploaded valid, but somehow PNGs worked. My first thought was 'let's script the conversion', but then I realised there were only six PDFs, so I opened Acrobat, and used keyboard navigation to run through the menus to export all PDFs to PNGs. Done in two minutes flat.
Had I chosen to script it, I would probably still be hunting for the CLI to convert PDFs to PNGs. Sometimes, the trade-off is not so clear.
So I, running Windows, using PowerShell, already knowing CUA shortcuts, generally familiar with Acrobat and its features, having to eventually use the mouse and keyboard anyway to navigate a JS-heavy insurance website, additionally have to:
1. Install sh/bash to get `for`, or convert your 'handy one liner' to PowerShell, and verify it works
2. Install ImageMagick, then ask an LLM to tell me what to do
2.5 And somehow LLMs don't present `convert`, but `pdftoppm`, or worse, both, and give me one giant essay, without my pre-configuring the system prompt to be concise and not overly wordy and avoid meta-sentences like 'if you want more help let me know';
3. Then navigate to my website anyway, and upload everything.
So no, point not made for you. With my existing environment and existing knowledge, it took me two minutes to get the work done. Even the slightest search would have brought me above that measure. There is a local minimum for a certain n at which discoverable GUIs absolutely excel over CLIs.
It's not a race; it is optimising the process for the input size, one's existing knowledge, and context-switch duration from an existing environment. If I had fifty PDFs, I'd look at scripting the result immediately. I had six, and I had Acrobat. I chose the GUI option, and it got me a decent result quickly enough.
A code analogy: it's a bit like how O(n^2) sort algorithms are the fastest for small n, and how most library sorts choose a different algorithm for different `n`. This is what I meant in my initial comment when I said
So I have to install NixOS to get your 'took me less than a minute to write, test, and get the right dependencies'. Given my work-flow, and since I don't use Nix, doing what I did was absolutely 100% faster.
Working in the terminal gets you to make the best use of a single most efficient input source, the keyboard. Which, coincidentally, is what you need for coding. In visual ides (pretty much all of them), some actions can only be performed by using a mouse (because, well, it exists). In editors like nvim that's not the case and everything is accessible via keyboard, usually in some pretty logical and structured way, so that eventually you get used to longer key chords etc for doing various things.
That, plus the terminal (itself) is at your disposal because, uh, you're in it.
That, plus vim emulation in all major ides be it vscode or jetbrains is pretty wonky and not comparable to the real thing.
Not much to do with 'true hackers', it's sad there's people who actually think that.
(all of the above being purely subjective ofc; this can be an infinite argument)
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).
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.
Gotcha! My main reason for advocating for byobu is it's more beginner/defaults-friendly. I've never customized it, nor fully learned its hotkeys.
In my case, we have dev robots with byobu installed, and it's much easier to train non-SW engineers (i.e. HW folks, technicians, QA) on its use (primarily for remote session persistence).
(This is also why I don't do much/heavy customization these days: for uniformity between local and robot machines...)
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:
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.
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!
note that these are not features built in to tmux, they’re things i built on top because tmux allows doing meta-programming on the terminal scrollback.
i expect that kitty allows doing this kind of thing too, kitty and wezterm both seem very programmable. the main thing they’re both missing compared to tmux is session persistence, but if you don’t need that, tmux doesn’t gain you a lot.
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.
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
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.
But why are you doing it in the first place? This is a genuine question, what do you gain by actively fighting against proper writing rules which aid in readability and comprehension? What’s the rationale for making it harder for users to follow your post?
I know I’m far from alone in having skipped your post entirely upon opening. Nothing personal, but I have yet to find a single post by anyone written in this style where the content was worth the effort of parsing non-existing capitalisation.
You go through the trouble of adding aids like syntax highlighting, lists, coloured titles, and even differentiated notes and timestamps. Presumably those are there to help the reader. But then you throw away a lot of readability by making everything lowercase.
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 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?
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.)
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).
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.
I never wrote full sentences or capitalised in my msn messenger convos. I'm not sure if I always did, but certainly at some point I started capitalising my IRC messages. Still don't always write in full sentences, though.
For me it wasn't about being professional, it was just about learning to type. As my typing speed improved it just became second nature to capitalise where appropriate. In other words, I capitalise everywhere out of laziness.
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.
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
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.)
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.
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.
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 ^^
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.
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.
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 %
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”
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.
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.
Would fig not fit this usecase? I seem to be misunderstanding the post a bit. It seems like he's going through great lengths not to use cursor? This regex must of been gnarly to write
># i am so sorry
> # see `search-regex.sh` for wtf this means
># TODO: include shell variable names
bind-key f copy-mode \; send-keys -X search-backward \
'(^|/|\<|[[:space:]"])((\.|\.\.)|[[:alnum:]~_"-]*)((/[][[:alnum:]_.#$%&+=@"-]+)+([/ "]|\.([][[:alnum:]_.#$%&+=@"-]+(:[0-9]+)?(:[0-9]+)?)|[][[:alnum:]_.#$%&+=@"-]+(:[0-9]+)(:[0-9]+)?)|(/[][[:alnum:]_.#$%&+=@"-]+){2,}([/ "]|\.([][[:alnum:]_.#$%&+=@"-]+(:[0-9]+)?(:[0-9]+)?)|[][[:alnum:]_.#$%&+=@"-]+(:[0-9]+)(:[0-9]+)?)?|(\.|\.\.)/([][[:alnum:]_.#$%&+=@"-]+(:[0-9]+)?(:[0-9]+)?))'
> i don't use Nix partly because all my friends who use Nix have even weirder bugs than they already had, and partly because i don't like the philosophy of not being able to install things at runtime.
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
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.
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.
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
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.
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.
Not really. The point is you're interacting with the full-blown Lisp development environment that is emacs and all the software it contains. A normal terminal doesn't let you reach into the internals of the software you're running in it, it just lets you chain that software together in predetermined ways.
A pro tip, if I may: never argue about programmability against a Lisp system. The argument unlikely to ever end up in your favor, because Lisp was designed from the ground up to be the ultimate programmable medium. The essence of Lisp lies in its incredible simplicity and flexibility - code is data, data is code, and everything can be manipulated programmatically.
The development experience is unmatched. You don't even need to save things - you can just eval them in a scratch buffer and see instant results. The REPL is unbelievably good, making programming feel like playing a video game where you get immediate feedback for every action. This interactivity transforms coding from a write-lint-link-compile-run cycle into a fluid, exploratory conversation with your system.
Sure, some things can be done equally well in shells, but not as nicely and elegantly as in a Lisp environment. The uniformity of S-expressions, the power of macros, and the ability to redefine anything at runtime give you a level of control that other systems struggle to match. Yours is a decades old argument yet Lisps are still prolific today, powering everything from Emacs configurations to modern web applications. The longevity speaks for itself - good ideas endure.
All of this is true, I just wish emacs were based on a more modern language like Clojure instead of emacs lisp — it’d be absolutely perfect then. But it’s pretty close already!
I would like to agree. Yet at the same time, as someone who writes in different Lisps daily, I can't say that would be my biggest complaint about Emacs to be honest. In my perspective - a Lisp is a Lisp. Sure, Elisp won't ever win the title of the prettiest and most pragmatic Lisp in existence, I still prefer it to any modern shining language from the RedMonk Top Ten.
I love Clojure. I use it all the time. Sometimes through babashka, sometimes via nbb. Yeah, I would probably consider trading my dog if that gets me proper Clojure-like maps and other immutable structures in Elisp. Still, this would be far down in my wishlist for Emacs improvements. My biggest gripe is the improbability of removing the GIL - I would love to have proper concurrency, but that's not the Lisp machinery of Emacs, that's all C core.
Imagine I launch an email client like Thunderbird from the shell. In a separate window I want to write a script that takes the currently displayed mail message in that client and runs "grep" on it. I can't do that, unless the authors of the email client have gone out of their way to expose an API that allows you to manipulate its state programmatically.
In emacs, you can do this, because your email client is a package written in Lisp and running in the globally shared context of the emacs interpreter, so you can directly query its state. And if you don't know the names of the variables to query, you can trivially jump into the source code and start figuring it out. Furthermore, there is a 99.9% chance the state is implemented using well-known emacs primitives like buffers, whereas for general programs launched from the shell there is no standard set of UI and text manipulation libraries.
There isn't functionality in bash to magically jump to the C++ source code of Thunderbird or read variables from its internal state, which is the key difference.
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.
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.
> 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.
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.
This stuff is beautiful. I still don't understand how nobody has built a nice AI typeahead for the terminal yet. Cursor tab would legit be perfect but they'd don't allow it in terminal. I'm almost tempted to just hack together a product where the terminal gets piped to a fake file and fed into cursor for now.
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.
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.
The golden mean between "customize literally everything" and "never stray from the basics", imo, is to pick and maintain a stack of blessed +2 vorpal binaries that work well even without any of your dotfiles or n=1 designs being present.
That's why I build off of the programs my Shell Bling Ubuntu [1] installs. Not everything I use in an average day is in there, but everything I find myself shocked not to have on a new Ubuntu VM out of the box is.
> terminals are stupidly powerful and most of them expose almost none of it to you as the user.
Well, they aren't really, and given the fundamentally flawed foundation of all text as the lowest common denominator, that power is not exposed.
For example, your regex path detection logic is invariably flawed, and while there are ways to mark the output with extra codes as paths so you could just click on them to open in whatever editor, that requires the whole processing pipeline to stray from the plain text (and might still not allow you to search for files only by type)
- 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.
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.
I’ve tried all kinds of tools but I always end up back at the terminal. It’s simple, direct, and helps me stay focused which makes me work more efficiently.
Being productive isn’t always about using the newest tools. It’s about finding what really fits your rhythm. The terminal might look basic but it’s a minimal and powerful way to get things done.
I've been using a very similar setup with vim/tmux for about 20 years. I've tried all the new IDEs but still keep coming back. With AI, I thought I was going to have to change until Claude code. Now I'm back in my happy place.
Can somebody help me, a CLI layman, out? How can I easily navigate printed directories like he does, in zsh, and paste them right into my prompt, e.g. for Git use? Is that where the tmux regex stuff comes in? Can I use that in iTerm 2?
If you’re on iTerm2, then perhaps the Cmd-; completion shows what you want. Otherwise, it sounds like he’s using `tmux-fingers`, but I can’t confirm as the video doesn’t play on iOS / Safari.
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.
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.
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.
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.
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.
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.
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.
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
I believe he is remoting into a Unix system to do his actual work. The Unix system can have tmux installed and running on it perfectly fine. I've done this too, to the extreme of SSHing into my own Virtualbox VM just to get that perfect compatibility layer that WSL still can't quite match.
this is cool but acting like this is some insane usage is funniest part for me. emacs and 100 other tools can do this easily and have been doing it for 30 years
tmux probably takes about a day to learn the basics of. If all you get out of it is the ability to split your terminal screen even inside a remote SSH connection I'd say it's worth it.
You can fall down an unexpectedly vast rabbit hole with its customisability, however, since multiplexers see so much of what's going on in a very general way (by design).
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".
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.
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.
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 -`.)
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.
That would be true if you had universally great designers back then, which wasn't the case, thus the defaults are universally bad, so it's a bad heuristic to stick to them and force a waste in trying to understand them.
For example, why is the default vim cursor hjkl? Well, it's just that the arrows on the physical keyboard of one of the vim designers were drawn there. That's it. There is no deep thought in search of the best cursor position, and understanding the why is just learning a useless piece of trivia.
That seems quite harsh. Just because the designers aren’t perfect doesn’t mean the design is universally bad.
To address your example: Why were the arrow keys on those particular keys? Who put them there? hjkl are on the home row, and touch typists end up having the movement keys under their right hand’s resting fingers. That’s suddenly quite convenient.
> and touch typists end up having the movement keys under their right hand’s resting fingers.
This is false, h isn't in the resting place. So go back and spend more time trying to explain that historic tidbid of design before trying to defend it (I'd also be curious to know why they shifted left instead of using resting places)!
Or don't and use this obvious principle directly and change keybinds to jkl;
Or go with the muscle memory of inverted T and use ijkl
But whatever you do, prioritizing the original design is a common bad heuristic because there is no reason to think that the original designer was great (not perfect!, don't twist it), so trying to understand the original reasons is a waste of "productivity" time (but if you're curious, it's not a waste of regular time)
> Why were the arrow keys on those particular keys? Who put them there?
They were placed on those particular keys by Lear Siegler who made the ADM-3A terminal Bill Joy was using at the time he made vi. End of story.
As pointed out, this is wrong. What touch-typists want is jkl;, because the right home key is j. This is an absolutely necessary config change in vanilla vim, unfortunately.
For me personally is the J/K direction still feels swapped and I always have to remind myself they are in fact the other way round. Even (especially) for touch typists, I would really expect [k] to point down and [j] up. In our writing system from the top left to bottom right my intuition would really be to stick ↑ with ← together and vice versa ↓ with →.
makes a little sense to me. would be way better, IMO.Not only because the most used used direction (↓) would be closer to my "neutral" finger position, but mainly because the the keys for progressing "back" and keys for progressing "forwards would be grouped together.
Honestly, I wouldn't even mind having them spread across two rows, like U I J K
or something. (Personally, I have global WASD-like arrow mapping bound to IJKL through capslock combo in AutoHotkey, since sometimes cursor keys are really inconveniently far away when typing.)I think the current system is the way it is in order so that the most used direction (down) uses your strongest finger, the index finger.
I don't know what your mean by "Not only because the most used used direction (↓) would be closer to my "neutral" finger position" - what is your neutral finger position?
I also got lost in the sentence about "back" and "forwards" - what is back and forwards?
> what is back and forwards?
Sorry, I didn't realise that was unclear. By "back" and "forwards", I mean movement through the flow of text relative to the cursor position. Given any reference point in linear text, all surrounding content either precedes or follows that point. Moving through preceding content is "going back", and moving through following content is "going forwards". When we move to the preceding line (↑) or preceding character (←), we're going "back". When we move to the following line (↓) or following character (→), we're moving "forwards". My point was that ← ↓ ↑ → effectively represents "back one character — forward one line — back one line — forward one character", which feels counter-intuitive to me.
> strongest finger, the index finger.
Interesting. As far as I now, middle finger is usually considered stronger than the index finger. Index finger might be more dextrous, though (?). Personally, I also slightly prefer the middle finger for rapid pressing over the index finger, but cannot see strong definitive advantage of either one. (I guess most of us use the middle finger for regular ↑↓ keys, as well as W/S in WASD bindings in games/project just fine, and using index finger in that context instead would feel odd.)
> what is your neutral finger position?
Mostly index finger on "K". (So I guess I'd prefer having "down" (being the most frequently used when VIM binding is involved) on "L", where my middle finger usually dwells, and "K" for moving up, if I had to invent it from scratch.)
I like the bindings, because I move vertically more than I move, so I want my strongest (other than the thumb) there. And I move to the right more than I do to the left. So I don’t mind moving my finger to do the latter.
It may be different based for others based on hand anatomy, but at least for me the index finger is so much stronger than the little finger, that it feels more comfortable moving it one space to the left, especially on keyboards with heavy keys (like model M).
I will admit that I had never considered things like this (there's a couple of you making a similar point). It's a decent argument. Maybe I'll revert to the default and see if I can handle the change.
As a touch typist that learned decades before learning vi, with Emacs in the middle, I can definitively say your blanket statement is false. And as a recovering Emacs user, I can also say the little finger thing for a repetitive key is a dangerous proposition with real potential health drawbacks.
The fact that the tools have survived and are still used today is at least somewhat indicative of their quality though. A lot of worse designs have likely been selected away due to nobody even bothering to use them.
P(old thing being good | old thing still being used after N years) is pretty high. Certainly higher than the base rate of P(new design fad being good).
> defaults in old software are almost always there for a reason
Keeping your fingers on the home row is great design for keyboard-first navigation.
All software design is historically contingent so you do have a point but assuming that old design = bad design is just wrong. Some things haven't changed.
> Keeping your fingers on the home row is great design for keyboard-first navigation.
Except you've just made that reason up since vim's defaults don't follow this logic. For example, the most frequent commands of going back/forward by word are not on the home row, they follow a different principle of name-based mnemonics.
Strictly speaking, this isn't even true for hjkl, that was due to the fact that arrows were drawn there, not because the designer followed some good design principles (granted, at least the physical arrows were likely driven by that principle, though there is still a mistery of moving off resting/home keys, which might be related to the fact that cutoff ASCII H code is backspace https://news.ycombinator.com/item?id=3684763).
> Some things haven't changed.
Indeed, and that universal fundamental thing that hasn't changed is that a few random people doing design blindly can't universally create a world of good design!
Yes, they are not in the resting position on the home row, but they are close enough for a command you will be executing often. Crating a key-map is an optimization problem between memorability and ergonomics.
Vim command layout is not perfect, the worst offender in my opinion is $ (move cursor to the end of the line), which is commonly needed, but somewhat hard to reach.
HOWEVER - when you start to use an surviving piece of still used old software, a bit of humility goes a long way. Not because software or designers were necessarily better in the past, but the reason that the software is still in use is probably because there are some benefits to it. So learn the defaults first, modify later when you understand them.
> they are close enough for a command you will be executing often
Right, just like w/b are "close enough" outside the home row completely
> but the reason that the software is still in use is probably because there are some benefits to it.
You forgot to connect this principle to this discussion. How does it make the defaults good to support your faulty conclusion that you need to learn them first?
> Right, just like w/b are "close enough" outside the home row completely
Yes, they are close enough, and w/b are executed often.
> How does it make the defaults good to support your faulty conclusion that you need to learn them first?
You need to at least study them because assuming a priori that they are either good or "universally bad" is a faulty conclusion - and some stuff doesn't become obvious until you use them for some time.
When you start learning VIM, you will be faster with arrow keys, because you are used to them from other programs. When you get enough muscle memory, you may discover that there is some value in having somewhere near where your fingers rest on the keyboard - or maybe you will still find that you are faster with arrow keys - whatever the conclusion, it can not be made objectively before you have enough proficiency with both.
That is absolutely not a faulty conclusion in any objective sense!
Now, you get to say it is faulty, and when one thinks about it for a minute, that idea packs a whole lot less punch.
Just want to dilute some unnecessary implied authority out of this otherwise interesting discussion.
Frankly, I always learn the defaults for the high value idea of reducing my overall configuration and maintenance workload!
Secondly, when I communicate workload to others, I don't have to do as much because the defaults are in place and useful.
These days, I tend to run defaults everywhere I can. Doing this means I do not have to a ton of configuration when setting up new environments.
I have also found those defaults do make a lot of sense. Maybe not the absolute peak sense, but more than enough.
I end up able to move and do a lot very reasonably quickly.
I also find my skills do not need to refresh as often too.
In any case there is plenty of room to disagree here, sans the idea of someone's conclusion being " faulty.
> and when one thinks about it for a minute
... one still can't correct the fault. You haven't answered the question of the original disconnect in arguments.
Your new arguments aren't relevant either since they're also NOT connected to the original re. bad defaults. You can have bad defaults that aren't there for any good reason and still think that reducing maintenance is more valuable! Fine, but that's a different argument!
I am not sure we are always talking about bad defaults.
That needs evaluation, and that need to be done in context.
In many cases, the defaults are not bad. One finds that out by working with them.
Really, I just don't feel "faulty" makes any sense.
If anything, it is more establishing a baseline.
Whether someone bothers with defeats first is debatable. I am on the work with them first side for what should be obvious reasons.
Passersby can arrive at their own conclusions and life carries on.
Re: still think reducing config and maintenance...
Yup. I have shown it many times. This also depends on context. For most of my career, no brainer.
Lets go one level deeper: What's the reason that the vim disgners keyboards had hjkl as arrow keys? Because it made sense for it to be the home row. I still use arrow keys though
and then we have C-n C-p of emacs. it should come with a health hazard warning.
I don’t mind it, because I don’t use it that much. And when I do, I move my whole hand to use the index fingers. I mostly use isearch and imenu.
which even then is horrendous ergonomics.
Haha, yeah, that's way more atrocious, the ergonomic reaper of bad mnemonics of next/previous line sweeping again...
It makes a lot of sense as they are on the home row... Via this argument you could suggest moving it to `jkl;` in order to minimise movement further.
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.
Typing that config into a file is emotionally associated with a system feeling "ready" for me. "ah, now I can _do_ things".No accounting for taste, but my similarly terse vim config includes relativenumber and number. Relativenumber is just so damn useful for doing things to larger chunks of code without having to count lines or anything.
I'm also an IDE user though. I tend to maintain a dichotomy between emacs(with evil-mode, of course) as the "kitchen sink" set up, with all the fixings, and vim with a config so short I can type it in as commands if I need to.
Vanilla vim is really perfect for quick edits to config files, scripts on random servers/VMs etc.
Bigger projects, at least for my usage, all happen on the same system , and having a bit more involved of an emacs set up makes sense there.
I suppose one could do a similar dichotomy with vim/neovim, if one had a distaste for emacs.
… why `memory commit` what you can `git commit` and then just `git clone`.
(I keep most of my dotfiles in a repository called "dotfiles".)
I get the emotional value/desire for a minimalistic .vimrc, but I also need the usefulness, and that necessitates, e.g., pulling in some plugins. E.g., lang-servers are just so valuable for immediate feedback in the editor.
Over time, someone of my vimrc has been pruned away just by development that has happened in/on vim itself, which is always lovely to see.
spoken like someone who has never had to operate on someone else's machine that they provisioned for you on an isolated network
Operate yeah. But write lots of code?
Yep. Some orgs require it.
I'm not arguing for it, just saying I've seen it at multiple billion-dollar+-a-quarter companies.
I've done it. It was terrible. I'm glad the project ended.
There's no fixing it, though. I can know the "base tooling with zero config" … and I'm just less productive, that's all there is too it. Customized tooling makes me faster than the base tooling. (I did start trying to find "inventive" ways to try to work around the problem, of course. My case wasn't like military air-gapped or anything, just the only connection was via RDP. So for example, copy & paste is a communication channel.)
Oh that sucks.
I mean there is a middle ground. LSP is good for coding a project. But I do agree with your point. What I generally do (as nvim user) reduces plugins to the bare minimum and try as much as possible to do progressive enhancement (atleast I try). Maybe as nvim improves LSP, I hope the diff between LSP and native methods are close enough that they both work.
I would love a generative llm script that looks at my command history (or something comparable), and adds a new zsh config (or other dotfile) every day, explaining itself via a reliable motd-type screen that flashes on-screen during the first session of the day, explaining what was added and allowing me to play with it and decide to keep it or not by the end of the day :)
Basically, slowly "evolving" my environment by forcing me to try new things daily, without my doing massive "learning" runs where I try batches of new things at once
Closest thing you'll find, I think, would be some creative use of ShellGPT features...
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.
Is it? I should just purposefully bind myself?
Seems like using a tool to its fullest potential to get more work done is better advice.
> I would be just as quick and comfortable on any system I would likely encounter.
How often are we encountering other systems…? And even where I am rarely ssh'd into something else … are we doing so much editing of code (live in production…?) that it matters? (I heavily customize my vim, but it isn't like I'm lost on a remote system with stock vim, or nano. ed is another matter.)
But if I need tons and tons of editing, … sshfs+local vim/terminal? But this just such a rare case, it seems like one of those "we should optimize for the common case" — which this is not.
I see it more as like understanding how to use a hammer even if most of the time in your job you use a nailgun.
For me personally it's a classic old timer habit from the days when you had to be prepared to fix a system using only the tools in /sbin. That doesn't mean you should operate like that all the time, but you should certainly know how to do so and be comfortable doing it.
Isn't the author likely to know the tool's potential best? I get that there are special cases but those should be few and ones you know well enough to memorize the exceptions for.
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.
Some defaults suck massively, emacs in tmux basically doesn't work due to hijacking C-b. The one that catches me every time is whatsapp that hijacks C-p.
> (`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.
`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).
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).
Can someone sell vim to me?
I can't help but see it as the tiling window manager of text editors.
Even with plugins it's less featureful than Kate or Jetbrains IDEs. And the last time I really gave it a go, it was slow, which is surprising for a terminal text editor.
If I need to edit text via the terminal, micro has mouse support and keybindings that match what you'd expect in any OS.
I don't like the idea of thinking people who use vim are insane, it obviously has value and people who use it have good reasons for using it, but I can't see it as more than a niche nerd thing a la tiling window managers.
I use both (neovim instead of vim, i3 as wm) and you got me thinking. I think the point of both is actually not having to use the mouse. But the mouse is not the problem per se, probably is the spatial/visual interaction paradigm. I don't care where the window exactly goes, I just want it right/on top/minimized. I don't want to search visually for a button that does what I want, I know what I want, I can just "tell" the computer. It's not about keybindings as shortcuts to do something, it's talking to the computer via keyboard using my language center without the intermediary of the gesture/spatial metaphor. Maybe? I just thought of this sorry.
It's this. I make the analogy to playing a game with a controller. At some point you stop thinking what combination of physical button presses and holds you need to have your character go from a running start to a crouch-jump, you just think in terms of goals for you want your character to accomplish. vim motions put you in the same sort of connection with the text you're editing.
Vim has it’s advantages:
- Fast and precise navigation (jumping to files and jumping to some point in the file)
- Fast editing command (there’s no need to select first, and when you need to selection is fast due to the above)
- Easy extensibility (either custom commands which you can bind to keys, or hooking some logic to editor’s event)
- Integration with external tooling (using the text as input, collecting the output, intepret the output to find location to jump to)
All of these are first citizen in Vim, whereas in some editors, it can only be done with plugins.
Vim and related vi-based editors have a built-in 'grammar' for editing text that is concise:
https://stackoverflow.com/questions/1218390/what-is-your-mos...
With a bit of practice, vim/vi-style editing can be developed into muscle memory which makes it incredibly fast to use.
There is a reason why most popular text editors and IDEs have a vim plugins.
> And the last time I really gave it a go, it was slow, which is surprising for a terminal text editor.
There was likely something wrong with your configuration. It's really hard to be faster than vanilla vim, but you can get weird performance issues from external plugins sometimes.
I used some Vim IDE plugins and I assume the bottleneck was there.
The problem is without some IDE-like features, I don't have a need for a text editor. Micro supports LSP servers by default and that gets me pretty far, before jumping to Kate or a real IDE.
The question is which plugins you used. My neovim configuration gives me "IDE-like features", yet it's noticeably faster than VS Code and others. Also, neovim has native support for LSP too.
Can you recommend any plugins that you find useful?
I think the sort of person who likes it values the "test of time" aspect of it and trust that vim will still be there in the next three decades, just as it was there for the last three. It's super easy to install, and is indeed preinstalled on almost every Linux installation. So people can learn its ins and outs and do extremely fine-grained customization to their desire. People who get annoyed by tiny details and don't want to put up with it. The downside is that you need to carry around your config files and if you sit at a colleague's computer you don't get the same standard experience. And the fragmentation.
There's of course also the "hacker street cred" aspect of it, to feel like a real serious developer. Or simply being fed up with churn and saying "I'm too old for this shit". JetBrains IDEs might change next year due to some new design fad. Or they may go bankrupt.
In my opinion, valuing boring old tech is good, but you shouldn't make a crusade of it. I choose to put up with some churn and inevitable tool changes for practicality. Yeah, some things have to be relearned this way, some changes seem pointless, but the overall effort may be less if you just learn to be flexible and say "ok if JetBrains goes bankrupt, I'll just learn the next popular IDE like everyone else and be done with it" instead of prepping in my bunker with my vim config files.
I definitely get that, I feel the same way about Bash. It's stood the test of time, is everywhere and will be everywhere for the foreseeable future.
Thanks for the perspective.
Vim existed before Jetbrains IDEs. It’s also much more general. I use Vim to write literary works and manage my knowledge base. There was also a guy who was using Vim as his IRC client. Vim can be the only program you need for editing text, which turns out is most of what we do on a computer. It’s nice to have a single tool for this, that never resists when you try to adapt it. Vim is actually a great example of the practicality of a good philosophy.
Edit: I doubt there’s any feature in the more specialised editors, which you can’t also get from Vim.
vim and tmux both have mouse support as well, it's nice to be able to resize vim splits and tmux windows with the mouse.
This is cool, I learned about `:cb` today (populate quickfix from current buffer)
I find that if I’m already piping into a buffer, I just leave it as a buffer. Vim’s gf and gf keybindings let me jump to the filename under the cursor, and it being a buffer makes it easier for me to edit (reorganize, group, further filter, etc).
I do think people undervalue the quickfix buffer though!
Is this the same/similar to 'vim -q <(ripgrep --vimgrep restore_tool)'?
Similar enough, minor semantic differences (e.g., I don't think `-q` creates a buffer containing the matches)
I use fish and neovim, thanks to the thread, created the following alias:
"rg --vimgrep restore_tool | vim -c cb -" looks like I want to use it. However, it doesn't work for me. vim says it had errors while processing, and says I haven't saved the buffer. I get the rg result displayed, but how do I navigate to a place?
Use `cb!` instead of `cb`:
You might also wanna open the quickfix list by default: You can learn more about how to navigate it using `:h quickfix`.This is amazing! Thank you!!
The quickfix window is so small, so I added the "-c only" option to make it the only window that first pops up. Then made it a function so it's easier to call:
``` vgrep() { rg --vimgrep "$1" | vim -c cb! -c copen -c only - } ```
$> vgrep "restore_tool"
I tried searching how to open the quickfix window in a vertical split, but found nothing. Any ideas?
got it
40 means open at 40 column.I had never heard of the quickfix list! Thanks a lot!
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.
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.
> 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.
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.
> 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.
I don't even understand what point you are making. The essence of programming is tool making. Of course the best programmers make tools as do the worst. Are you seriously comparing making a terminal hot rod configuration app to, say, creating Tex?
> Being a programmer is not about configuring your development environment.
My point is that being a programmer is also about configuring one's development environment. Exactly because like you said: "the essence of programming is tool making". I just don't understand how it is different - configuring a tool, extending its functionality, adding more features to it from developing a [different] tool from scratch? Both is programming. Shit done by programmers. You don't call one bunch "pseudo-programmers" and the other "alpha-programmers" or some shit like that, right?
> I have never said that.
Then I misunderstood your comment. I read it as "not invested in their tools => not a good programmer."
Reading the replies to my sibling comments, I don't think we really disagree but we probably have different pictures in our heads when reading the context of this thread.
> 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.
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.
Yes, I think we agree.
Not in enterprise consulting, there is very little room for creation on the software sausage factory, it is all about social skills, and outputing something that mostly works within the project budget.
The craftmanship is better left for small businesses, or FAANGS with engineers playgrounds.
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
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.
I don't agree at all with your assessment.
These famous people you cite are famous because they are "devs for devs". These guys were working on a _product_ (be it LaTex, games, text editors...) for which the user happened to be developers: by improving devx a little they had a lot of impact. That has little to do devs with individually spending a lot of time on their own tooling (for whom improving their devx a little has a little impact).
> 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"?
The best engineers I've worked with were comfortable with their tools (of course, that's a requirement) but wouldn't be spending much time on incremental improvements. They'd spend time talking to customers, to PMs, to support, to leadership, learning about their domain and about how other engineers in the industry approached it. They _would_ spend time investing in tools that might be a game-changer (10x or whatever), but not things like vim configs and keyboards.
It always comes down to the same thing: you can have the best tech skills and tooling, yet a (decent) engineer who understand the domain and can communicate effectively will build a better product than you. That's hardly controversial.
> That's not for me though; I'm happy where I am.
I don't agree that it's a question of "growing out of engineering" at all (in fact I'd say it's "growing into" engineering from programming), but at the end of the day I'd totally agree that you should do what makes you happy! If you enjoy what you do and don't want to be doing the other stuff, who cares, I certainly won't be the one to tell you to change your ways!
> The best engineers I've worked with were comfortable with their tools (of course, that's a requirement)
Yeah, that's all what I'm saying.
> but wouldn't be spending much time on incremental improvements.
What is "an incremental improvement"?
My tools change depending on the work I do, and it so happens, the type of tasks I do sometimes change. When I say "working on tools," to me it's like knife sharpening. Sure, it's not impossible to cook with a dull knife, but it's helluva uncomfortable; why just not sharpen it? For me, it's like a chore I can't avoid, the only choice I can make is how to respond to it - and I choose to enjoy it. It takes less than two minutes to sharpen my knife - I have an electric sharpener. It's not tiny, but small enough so I can hold it in my hand, and it's not expensive. I also have regular sharpening stones. That process takes longer. I think I enjoy it, why not; it feels like meditation. But I don't do it every day, or even every week. I think I like how knives feel after.
So basically, I don't even understand what we are arguing about. Some engineers like extending the tools they use. Some, maybe not so much. Some spend a good amount of time doing that. They do it because they love it, and there are mostly benefits.
Some don't sharpen their knives at all - they simply throw them away and buy new set - I just don't know anyone like that in my circles. And similarly, I have never met engineers who never cared about improving their tooling even a little bit.
At the end of the day, we can probably all agree that doing the work without nicely "sharpened" tools is like cooking with a dull knife - it's not impossible; it's just why would anyone do this to themselves? It sounds anguishing.
>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.
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.
> 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.
If you enjoyed the process it was time well spent.
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.
> 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.
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.
> It's not a competition
For professionals it's absolutely a competition, but I'll also agree that engineers overvalue their environment setup.
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.
All completely true. But I also wouldn't voluntarily run a marathon in tennis shoes.
Being a programmer is absolutely about knowing how to configure your development environment, though.
Refreshing to see logic among the sea of your shell "bros".
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.
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.
> 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.
Few hours later, 2 of these tools are in the front page of hackernews. So it's not that absurd! Sometimes you can just reference stuff here in the comments in order to summon them.
I love this place.
> Sometimes you can just reference stuff here in the comments in order to summon them.
I know. It was more a commentary on how whimsical and uninformative all the names are.
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.
+1 fd, use it all the time.
Every vim/tmux user has created an ad hoc, informally-specified, bug-ridden, admittedly probably quite fast implementation of half of Emacs.
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 ;)
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.
I'm aware! I used emacs exclusively in professional development roles for years. I still use it for a handful of things that nothing else can touch emacs' workflows for.
That said, there is something nice about composing simple programs and keeping things small. With vim + tmux, I have terminal multiplexing and text editing done and haven't touched that configuration in at least 5 years for vim, over 12 for tmux. I know they offer 'less functionality' out of the box, but after years of tweaking and tons of installed packages I was never able to get that same functionality in Emacs, try as I might.
The main pain points were: - Not having tmux's <c-b z> functionality. You can kinda-sorta-almost jerryrig it with some custom bindings and winner-undo, but you'll still have weird edge cases to think about because you're technically doing a weird undo-tree thing, and all the context (projects, windows, buffers, etc) that emacs maintains will have something to say about that. - ACTUAL vim emulation. Evil mode is really not good enough, and I never had a package that was so hard to integrate without bugs, and when it breaks you have to usually peel back a massive layer cake of competing configurations to try to make it work. Even then, evil-magit has tons of issues, the dot operator doesn't work correctly, and none of the ctrl-i/ctrl-o plugins work across enough contexts to make it make sense like it does in vim. That's a killer feature for me - Embedded terminals that feel anything like tmux in wezterm. In the emacs terminals, there was always so much shit going on navigating in them (and again the layer of evil there) that it felt like walking on egshells using them, they tended to have performance issues and usually couldn't run TUI programs properly. I ended up having a separate drop-down terminal I used in tandem with emacs - Process management. It was always a huge headache for me keeping track of the processes Emacs was spinning up / down through its various plugins and debugging them.
I'd say most tmux+vim setups have something more like 0.00001% of emacs implemented, but sometimes that's a good thing. And again, I love and use both setups for various things.
> Not having tmux's <c-b z>
What the heck are you even talking about? (delete-other-windows) command existed since at least Emacs 18 (released in 1987).
Okay, yeah, I get it, you're complaining that Emacs sorta lacks a dedicated "zoom toggle" that cleanly saves your exact window layout, maximizes one window, then perfectly restores the layout when toggled again. I personally never had any problem with my (toggle-maximize-buffer) command that builds on top of (delete-other-windows)
But do you even realize that you're comparing a bicycle to a Bugatti Veyron - tmux is a simple pane grid with position/size and Emacs windows carry much more state. There are buffer associations, point positions in each buffer, window-local vars, display parameters - margins, fringes, etc., there could be integrations with modes that manage window layouts, there are multiple abstraction layers - framers, pos-frames, buffer display rules.
tmux can get away with a simple layout save/restore because panes are just rectangular terminal regions.
> Evil mode is really not good enough
Ha, I'm a die-hard vimmer, and I laugh at this sentiment. You, my good Sir/Madam/etc., respectfully, have no idea what you're talking about. Evil-mode is the only ACTUAL vim emulation outside of vim/neovim. There's no such thing as a "vim emulation". And I've tried them all - different ones - IdeaVim for IntelliJ, Sublime Vim plugins, VSCode extensions, etc. All of them are pretty much filled with laughable deficiencies; they are not even shadows of the actual Neovim experience. With one notable exception, and that is the vim-implementation in Emacs. In Emacs, Evil-mode doesn't even feel like an extension, an afterthought; it feels like it's a baked-in, major feature of the editor. More than that, it can do certain things even better than you can do it in Neovim.
Anyway, it seems you're complaining for just the sake of complaining, without any evidentiary input. Like I said before, it's of course absolutely obvious that things of lesser capacity will have smaller surface area and thus would feel more stable.
What would be your reaction if I say - my bicycle of 15 years has never needed an oil change or brake fluid drainage. My new car in comparison, is so much more complicated and requires constant attention? You'd probably laugh and call me names. I hope you'd realize how vain this kind of argumentation is - comparing things of completely different caliber.
This is a very haughty response, I hope you realize that. Yes, (delete-other-windows) does exist. It's so far from the buffer zoom toggle I'm talking about as to be completely unrelated.
> Anyway, it seems you're complaining for just the sake of complaining, without any evidentiary input.
I have given multiple specific examples of every claim that I made. HN's formatting did make my comment difficult to read, but the content is there.
> But do you even realize that you're comparing a bicycle to a Bugatti Veyron - tmux is a simple pane grid with position/size and Emacs windows carry much more state.
Yes, yes, this is exactly what I'm saying. It's cumbersome and much more difficult to maintain. There are reasons to like both things (and I have repeatedly made efforts to re-iterate that I do like both options and use both for different purposes).
Your screed about how great evil-mode is does not address any of the specific issues that I have and was never able to resolve wrt using evil-mode in emacs.
> What would be your reaction if I say - my bicycle of 15 years has never needed an oil change or brake fluid drainage. My new car in comparison, is so much more complicated and requires constant attention? You'd probably laugh and call me names.
Incidentally I wouldn't, especially if your bicycle worked for your lifestyle and the constant attention and expense of motor vehicles factored into your decision making process. That's neither here nor there, though, because I happen to own both a bicycle and a car, and I never made the argument you seem to be fixated on. Like my car and bicycle, I use both a tmux / terminal app based workflow and emacs in different contexts and have swapped back and forth between the two at different points depending on my mood and what I'm doing. Sometimes I even (gasp!) discuss my experiences with the two tools in a comments section.
The only thing missing from emacs is some (opengl) 2d surface api like the browser’s canvas, to rival the rest of the OS.
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.
___
¹ https://github.com/agzam/browser-hist.el
² https://news.ycombinator.com/item?id=44264368
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
> 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.
i would have explicitly mentioned shell & eshell too.
ansi-term however doesn't work thru TRAMP, out of the box, though there are workarounds, like https://github.com/cuspymd/tramp-term.el (hasn't tried it yet)
yeah, magit via TRAMP kinda works, just slow af: https://news.ycombinator.com/item?id=44356346
not really TRAMP's fault, of course...
it also doesn't quite work with macOS remotes usually.
again, not purely TRAMP's fault, but a default config and habits issue with ~/.zshrc vs ~/.zprofile and maybe /etc/sshd/config settings, i think. i hasn't fully figured it out yet.
using this kind of "full-screen terminal screen sharing" approach has a more predictable experience, because of the amount of data transferred is usually 1 screen worth of characters (and colors) max, on most keystrokes.
that's both a pro and a con.
it imposes a fixed, network connection dependent input lag and the output is also often redrawn by retransmitting the same data over and over again...
I even wrote a little terminal emulator turn my 2-key tmux prefix into the single-key ctrl modified for every command, including the ones that are normally impossible on other terminal emulators
https://github.com/ouillie/terminalle
I felt that. In my current workflow I run :Term inside of nvim.
Hi Jyn.
"i don't use Nix partly because all my friends who use Nix have even weirder bugs than they already had and partly because i don't like the philosophy of not being able to install things at runtime."
The first part is mostly true. Nix installs things in a readonly store (/nix/store) so regular dynamically linked binaries don't work. Packaging takes a different approach and when things break, it can be difficult to work around. That said, I've run NixOS for over a year now and I find the benefits are far preferable to these downsides. It's not often I run into bugs, let alone show-stopping ones. What is annoying is how many tools are distributed without the source, so I have to run patchelf on them or use something like nix-ld.
As for the latter part, I think that using Nix will change that mentality. (Note that you can do `nix-env -iA $pkg` but it's not recommended). See, I don't even install things like rust at a global level anymore. I can always do `nix-shell -p $pkg` for an ephemeral shell if I need that, or I encode that dependency directly in the project's flake.nix. If I end up using that program a lot I will make the effort to add it to my NixOS config.
"at runtime" is not the same as "globally". i would love to install things locally at runtime, but the nix evaluator can't manage things that aren't packaged through a nix derivation, and i don't want to have to figure out how to package a random tool on the internet just to be able to run it at all.
Ah I misunderstood. Yes that's a bit more complex. Your options boil down to a) using pkgs.autoPatchelfHook [0], b) learning some nix and writing a derivation yourself, c) using nix-ld [1]. There's also pkgs.steam-run which provides a typical environment expected for games.
A great deal of things are already packaged, but for the most part I find it pretty fast to package something. Once you write a derivation [2] or two, it's not that bad. I never packaged for other distros because they all seemed quite tedious, but the nixpkgs reference [3] lists most things and I can look at the source of similar packages in nixpkgs. It is a time commitment though to learn so it's understandable that it's not really appealing.
[0]: https://github.com/svanderburg/nix-patchtools
[1]: https://blog.thalheim.io/2022/12/31/nix-ld-a-clean-solution-...
[2]: https://ayats.org/blog/nix-tuto-2
[3]: https://nixos.org/manual/nixpkgs/stable/
I use Nix exactly because it doesn't allow installing things at runtime. This keeps me from hitting surprises where the runtime environment changes from under me. Containers can partially solve this problem as well but have their own usability issues.
Nowadays I start every project with `nix flake init --template templates#utils-generic`. And put everything in that related to the project. I even had some projects where I had to put 'ssh' as a pinned package as it was used in some scripting and the default macOS and Linux versions accepted different flags.
I also do love that I can do something like `nix run nixpkgs#nmap` on any machine I'm on to instantly run a program with worrying where to get it from. I also use this feature in some of our projects so you can click a link in the admin web interface which is a 'command url' for iTerm2[0] like: `nix run gitlab.com/example/example/v1.0 -- test http://example.com` which will prompt to run that specific version of the command in your terminal, without have to checkout the source repo. In this case it is to rerun specific task locally for debugging purposes.
[0] https://iterm2.com/documentation-command-selection.html
My similar trick is to rely on the tmux scrollback and pipe tokenized output into fzf so I can easily autocomplete in zsh against anything on the visible tmux screen
https://www.threads.com/@kunalb_/post/C6ZQIOVpwMd https://gist.github.com/kunalb/abfe5757e89ffba1cf3959c9543d9...
which has been really useful.
I have been using xterm's default dabbrev-expand to do the same via "Alt-/" ( https://github.com/ttsiodras/dotfiles/blob/master/.Xresource... ) - which works regardless of what shell you're in.
But I was curious for your approach... so I asked Claude to convert it to bash: https://claude.ai/public/artifacts/01a49347-1617-4afe-8476-0...
Works like a charm - pinned it to Ctrl-k, which was free in my setup. I guess I don't have to depend on XTerm for this any more :-)
Thanks!
Fantastic. Thanks for sharing!
love it!
As someone that was happy that I could finally afford owning computers with a graphics display on them, this going back to the terminal doesn't stop surprising me.
We still do horses, but hardly anyone is favouring them for travelling around the continent delivering mail.
Kudos to the people that would rather experience that, I guess.
Zoomer terminal maximalist here.
My thing is that most UIs use such poor use of the screen real estate. I get it, pretty is the priority. But when I want to do work, the padding on everything gets to be excessive. Additionally, it’s really nice to be able to host my dotfiles in GitHub and I can be in a 100% familiar environment within a couple minutes. I have a variety of machines I work on. Same thing goes for mouse usage. I’m much faster operating the keyboard, whereas I switch between mice and trackpads and sensitivities when I switch devices. Keyboards are mostly the same. Maybe it’s a skill issue on my part but oh well ;)
My issue with the terminal is the exact opposite, everything is monospaced, hard to read, and space-inefficient due to that. Keyboard use is not a terminal-only thing either, it's a problem with some modern UIs that are hostile to power users. I feel it's at least partly because power users that create their own tools removed themselves from serious GUI development and are too busy with fancy TUI doodads and dark themes instead.
I feel like the point of monospace is to be easier to read in text dense environments. I find it much easier to read a monospaced font in the terminal and it makes editing commands much nicer to work with.
The point of monospace is easy vertical alignment in code, tables, logs, and many other types of text. But you definitely lose fast visual shape acquisition and potential density of proportional fonts. CLI is fine conceptually, I'm talking about TUI which is different.
The point isn't really the lack of graphics, it's more about the use of a keyboard and text as a universal data format.
Graphical programs look nice but are a nightmare for interoperability.
Having said that, as an Emacs user I'm surprised that anyone goes to this much effort to not use Emacs. This is what it's made for and it's all built in the most hacker-friendly way imaginable.
It's difficult to express how amazing Emacs is to someone that hasn't used it long enough to really learn it. I used vi for 20 years before switching, and I'll never go back, but the me then just didn't realize what Emacs could do for me.
Yeah, I've given up trying to be evangelical about Emacs. It makes me think of the red pill in the Matrix: noone can be told what Emacs is, you have to see it for yourself. People who want to take the pill will find someone like me to help them, but it has to start with them, not me.
Back in '05 I realised how crazy it was that everyone was using these shitty editors built in to bloated IDEs, all slightly different from each other. It's all just text! This caused me to discover vim and Emacs. This was about 10 years before editors like Atom and then VS Code caught on.
I tried vim for a while, did the tutorials and tried to believe that if I practised the keys I'd become a wizard. But it never paid off. But I'm glad I learnt to enter insertion mode and exit vi/m at least.
Emacs was not presented as well back then. It had (has?) a terrible looking GUI by default. But once I'd switched that off the keyboard interface and major/minor modes made so much sense. No surprise that VS Code uses the same model.
But then when I got into Elisp I can say I truly fell in love. I liked GNU/Linux before, but Emacs is what Free Software was always meant to be. Not just technically hackable but practically so. How many people edit their VS Code plugins to do exactly what they want? With Emacs you can hack everything right there in Emacs while it's running and then just go right back to where you were.
Now extrapolate the experience to a complete operating system, instead of only the editor.
This is what systems like those from Xerox PARC, TI, Genera, ETHZ, Inferno had to offer, and we aren't still quite there in mainstream systems.
What languages are these systems based around? Maybe Lisp has something to do with it? I've been drawn to things like Guix and stumpwm for this reason. It would be a dream to have an entire OS built on a Lisp.
Smalltalk, Lisp, Cedar, Oberon, Limbo.
I keep checking in on Mezzano, a Lisp-based OS. It only runs in a VM right now, but someday... who knows?
Easily solved with scripting languages and REPL environments.
No need to experience like MS-DOS, CP/M, VMS and UNIX without X, is all that we can get hold of.
The horse and car comparison really doesn't work since if anything terminals are higher performance and efficiency than guis. They just have a learning curve and no eye candy.
On case per case basis, depending on what tools one makes use of.
Sure there are bad clis and good guis but that's the minority from my experience
There are plenty of good guis, they just tend to be for things other than programming. That said they do exist.
> We still do horses, but hardly anyone is favouring them for travelling around the continent delivering mail.
Most alternatives are much faster, easier to use, and more reliable than the horse. Just like the terminal, in fact: your metaphor was prefect, you just had it the wrong way round :)
You can't possibly argue that a terminal is easier to use than a GUI.
It's literally what brought computing into the mainstream, so you can click options that are presented to you rather than memorize a bunch of incantations.
I started coding using Borland Pascal on DOS. I went through many tools and in the end split the terminal / UI work depending on whether the language is actually bound to an IDE or a build system.
E.g.: not using Xcode for iOS dev doesn’t make much sense to me. At work we have a fully set-up IDE that works with our build system. I like QtCreator for C++.
But for web dev, scripting and blog writing, I find programs like VSCode extremely slow even with just minimal plugins. After a couple of years I got fed up and went back to vim in terminal.
> As someone that was happy that I could finally afford owning computers with a graphics display on them, this going back to the terminal doesn't stop surprising me.
GUI is not a superset or complete replacement of TUI. For many reasons, one of the reasons is that GUI is much harder and finicky to automate.
What makes TUI easier to automate?
Every command can be manipulated as text and repeated as many times as you wish. Every command is also stored in the history, can be saved to any notepad for future, shared with the community.
Every GUI automation is highly non-standard, ad hoc, finicky (usually, depends on exact pixel positions), possibly Turing complete, but even if it is, it's harder to use compared to writing a script.
Wait, you're describing CLI: command line and infinite history. TUI is a distinct thing, it exists on an addressable 2D character grid instead of the bitmapped canvas. For example top and mc are TUI applications, but there's no command line in them (unless you count passing different parameters from the external CLI or a script, which you can also do with a GUI application as it's separate from the interface).
> Every GUI automation is highly non-standard, ad hoc, finicky (usually, depends on exact pixel positions), possibly Turing complete, but even if it is, it's harder to use compared to writing a script.
The same applies to TUI applications. How do you automate top or mc? Don't conflate presentation (which is silly to even attempt automating) with internal logic.
The entire reason for TUI to exist is that TUI apps can be used in a terminal window, alongside CLI, so you don't have to switch to a separate window. But fundamentally it's just "GUI on a character grid".
I think horses are the wrong comparison.
I think its more like walking. For some things walking is preferable to driving there. its even less effort for things that are nearby, it uses fewer resources, I can do it after having drink, I can go through places that are not accessible by car (foot paths)....
Same here. I'm also amused that the people that do like the experience haven't by this time replaced the protocol (termcap entries, escape sequences, etc) now that memory sizes and network speeds are many orders of magnitude higher than they were when the protocol they are using was designed.
Depends on what you do, really. If I need to edit a photo, of course I’ll use gui. For any kind of text manipulation, including coding, tui is simply superior.
> We still do horses, but hardly anyone is favouring them for travelling around the continent delivering mail.
Except that if you've ever seen someone who truly knows how to use a terminal, you'd be surprised how many times faster he can work than with any other UI-based workflow.
This may change with AI, but so far I'm not holding my breath.
Literally twenty minutes ago, I had to submit several hospital invoices for insurance claims. The website, despite claiming it'd accept PDFs, didn't consider the PDFs I uploaded valid, but somehow PNGs worked. My first thought was 'let's script the conversion', but then I realised there were only six PDFs, so I opened Acrobat, and used keyboard navigation to run through the menus to export all PDFs to PNGs. Done in two minutes flat.
Had I chosen to script it, I would probably still be hunting for the CLI to convert PDFs to PNGs. Sometimes, the trade-off is not so clear.
>the trade-off is not so clear.
Assuming very basic knowledge of CLI on Linux
10 seconds flatIf you've never heard of convert (part of imagemagick) then:
Adds 30sec topsThank you for making my point for me.
So I, running Windows, using PowerShell, already knowing CUA shortcuts, generally familiar with Acrobat and its features, having to eventually use the mouse and keyboard anyway to navigate a JS-heavy insurance website, additionally have to:
1. Install sh/bash to get `for`, or convert your 'handy one liner' to PowerShell, and verify it works
2. Install ImageMagick, then ask an LLM to tell me what to do
2.5 And somehow LLMs don't present `convert`, but `pdftoppm`, or worse, both, and give me one giant essay, without my pre-configuring the system prompt to be concise and not overly wordy and avoid meta-sentences like 'if you want more help let me know';
3. Then navigate to my website anyway, and upload everything.
So no, point not made for you. With my existing environment and existing knowledge, it took me two minutes to get the work done. Even the slightest search would have brought me above that measure. There is a local minimum for a certain n at which discoverable GUIs absolutely excel over CLIs.
> So I, running Windows, using PowerShell
Well, what can I say other than people don't usually get in races with lead weights tied to their ankles.
It's not a race; it is optimising the process for the input size, one's existing knowledge, and context-switch duration from an existing environment. If I had fifty PDFs, I'd look at scripting the result immediately. I had six, and I had Acrobat. I chose the GUI option, and it got me a decent result quickly enough.
A code analogy: it's a bit like how O(n^2) sort algorithms are the fastest for small n, and how most library sorts choose a different algorithm for different `n`. This is what I meant in my initial comment when I said
> Sometimes, the trade-off is not so clear.
fd -e pdf -x magick {} {/}.png
Took less than a minute to write, test, and get the right dependencies (nix-shell -p imagemagick ghostscript). Scales to any number of pdfs.
The terminal just wins probably 95% of the time as long as you know about available tools.
> nix-shell
So I have to install NixOS to get your 'took me less than a minute to write, test, and get the right dependencies'. Given my work-flow, and since I don't use Nix, doing what I did was absolutely 100% faster.
I have been around in this world since the 1970's, and have been coding since 1986, I have seen my share.
Agree, tho, on their defense, they look super cool and hackerish.
Now, velocity and confort, they don't beat any top IDE.
I beg to differ.
I don't understand either. My theory is that working all the time in the terminal makes some devs feel like true hackers.
Working in the terminal gets you to make the best use of a single most efficient input source, the keyboard. Which, coincidentally, is what you need for coding. In visual ides (pretty much all of them), some actions can only be performed by using a mouse (because, well, it exists). In editors like nvim that's not the case and everything is accessible via keyboard, usually in some pretty logical and structured way, so that eventually you get used to longer key chords etc for doing various things.
That, plus the terminal (itself) is at your disposal because, uh, you're in it.
That, plus vim emulation in all major ides be it vscode or jetbrains is pretty wonky and not comparable to the real thing.
Not much to do with 'true hackers', it's sad there's people who actually think that.
(all of the above being purely subjective ofc; this can be an infinite argument)
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).
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.
Gotcha! My main reason for advocating for byobu is it's more beginner/defaults-friendly. I've never customized it, nor fully learned its hotkeys.
In my case, we have dev robots with byobu installed, and it's much easier to train non-SW engineers (i.e. HW folks, technicians, QA) on its use (primarily for remote session persistence).
(This is also why I don't do much/heavy customization these days: for uniformity between local and robot machines...)
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!
Not to forget
https://github.com/laktak/extrakto
(similar to copycat) and
https://github.com/laktak/tome
TOME can be natively performing with tmux panes.
Steps:
1. have two panes open
2. In pane 0, have your cursor or a line or multiple lines of code
3. :VtrSendLinesToRunner
4. In pane 1, the lines are performed
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.
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!
note that these are not features built in to tmux, they’re things i built on top because tmux allows doing meta-programming on the terminal scrollback.
i expect that kitty allows doing this kind of thing too, kitty and wezterm both seem very programmable. the main thing they’re both missing compared to tmux is session persistence, but if you don’t need that, tmux doesn’t gain you a lot.
The article title is actually "How I use my terminal"
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.
Reminder to anyone submitting an article: you have two hours to edit the title to fix these alterations.
I believe these changes are intended to defang some clickbaity titles, but you are right that it maims some perfectly good ones.
Weird. I see a post titled "How to store Go pointers from assembly" literally three posts below this one.
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)
Not quite reject exactly, you can just edit the title afterward for some X amount of time.
You are correct.
You wonder?
Thought that this was going to be a 'There Will Be Blood' spoof.
(In case not obvious, current title is 'I use my terminal')
I use your sudo?
I use your
I thought this was going to be a blog post about somebody using a terminal emulator they wrote.
And I thought this was going to be a blog post about someone hooking up an old fashioned hardware terminal to their PC.
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
HN will automatically trim some common prefixes and suffixes from title submissions
The entire blog post being in lowercase distracted me more than I thought it would.
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.
that's voice-to-text on iOS, i haven't found a way to turn off the auto-caps yet.
But why are you doing it in the first place? This is a genuine question, what do you gain by actively fighting against proper writing rules which aid in readability and comprehension? What’s the rationale for making it harder for users to follow your post?
I know I’m far from alone in having skipped your post entirely upon opening. Nothing personal, but I have yet to find a single post by anyone written in this style where the content was worth the effort of parsing non-existing capitalisation.
You go through the trouble of adding aids like syntax highlighting, lists, coloured titles, and even differentiated notes and timestamps. Presumably those are there to help the reader. But then you throw away a lot of readability by making everything lowercase.
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.
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.
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.
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?
Huh interesting, I didn't even notice that
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.)
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).
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.
I never wrote full sentences or capitalised in my msn messenger convos. I'm not sure if I always did, but certainly at some point I started capitalising my IRC messages. Still don't always write in full sentences, though.
For me it wasn't about being professional, it was just about learning to type. As my typing speed improved it just became second nature to capitalise where appropriate. In other words, I capitalise everywhere out of laziness.
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.
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
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.)
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.
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.
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 ^^
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.
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)
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.
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 %
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”
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.
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.
Would fig not fit this usecase? I seem to be misunderstanding the post a bit. It seems like he's going through great lengths not to use cursor? This regex must of been gnarly to write
># i am so sorry > # see `search-regex.sh` for wtf this means ># TODO: include shell variable names bind-key f copy-mode \; send-keys -X search-backward \ '(^|/|\<|[[:space:]"])((\.|\.\.)|[[:alnum:]~_"-]*)((/[][[:alnum:]_.#$%&+=@"-]+)+([/ "]|\.([][[:alnum:]_.#$%&+=@"-]+(:[0-9]+)?(:[0-9]+)?)|[][[:alnum:]_.#$%&+=@"-]+(:[0-9]+)(:[0-9]+)?)|(/[][[:alnum:]_.#$%&+=@"-]+){2,}([/ "]|\.([][[:alnum:]_.#$%&+=@"-]+(:[0-9]+)?(:[0-9]+)?)|[][[:alnum:]_.#$%&+=@"-]+(:[0-9]+)(:[0-9]+)?)?|(\.|\.\.)/([][[:alnum:]_.#$%&+=@"-]+(:[0-9]+)?(:[0-9]+)?))'
This is pure quantum flux
> i don't use Nix partly because all my friends who use Nix have even weirder bugs than they already had, and partly because i don't like the philosophy of not being able to install things at runtime.
Huh, I install things at runtime all the time.
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
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.
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.
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.
That puts you vastly ahead of most people who encounter vim.
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
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.
Emacs is why I can't go back to terminals.
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.
___
¹ https://github.com/agzam/.doom.d/blob/main/modules/custom/sh...
Why is any of that absurd? That seems like typical terminal stuff.
Not really. The point is you're interacting with the full-blown Lisp development environment that is emacs and all the software it contains. A normal terminal doesn't let you reach into the internals of the software you're running in it, it just lets you chain that software together in predetermined ways.
All the thugs you listed could be done within the shell. Shells are very programmable.
> Shells are very programmable.
A pro tip, if I may: never argue about programmability against a Lisp system. The argument unlikely to ever end up in your favor, because Lisp was designed from the ground up to be the ultimate programmable medium. The essence of Lisp lies in its incredible simplicity and flexibility - code is data, data is code, and everything can be manipulated programmatically.
The development experience is unmatched. You don't even need to save things - you can just eval them in a scratch buffer and see instant results. The REPL is unbelievably good, making programming feel like playing a video game where you get immediate feedback for every action. This interactivity transforms coding from a write-lint-link-compile-run cycle into a fluid, exploratory conversation with your system.
Sure, some things can be done equally well in shells, but not as nicely and elegantly as in a Lisp environment. The uniformity of S-expressions, the power of macros, and the ability to redefine anything at runtime give you a level of control that other systems struggle to match. Yours is a decades old argument yet Lisps are still prolific today, powering everything from Emacs configurations to modern web applications. The longevity speaks for itself - good ideas endure.
All of this is true, I just wish emacs were based on a more modern language like Clojure instead of emacs lisp — it’d be absolutely perfect then. But it’s pretty close already!
I would like to agree. Yet at the same time, as someone who writes in different Lisps daily, I can't say that would be my biggest complaint about Emacs to be honest. In my perspective - a Lisp is a Lisp. Sure, Elisp won't ever win the title of the prettiest and most pragmatic Lisp in existence, I still prefer it to any modern shining language from the RedMonk Top Ten.
I love Clojure. I use it all the time. Sometimes through babashka, sometimes via nbb. Yeah, I would probably consider trading my dog if that gets me proper Clojure-like maps and other immutable structures in Elisp. Still, this would be far down in my wishlist for Emacs improvements. My biggest gripe is the improbability of removing the GIL - I would love to have proper concurrency, but that's not the Lisp machinery of Emacs, that's all C core.
Imagine I launch an email client like Thunderbird from the shell. In a separate window I want to write a script that takes the currently displayed mail message in that client and runs "grep" on it. I can't do that, unless the authors of the email client have gone out of their way to expose an API that allows you to manipulate its state programmatically.
In emacs, you can do this, because your email client is a package written in Lisp and running in the globally shared context of the emacs interpreter, so you can directly query its state. And if you don't know the names of the variables to query, you can trivially jump into the source code and start figuring it out. Furthermore, there is a 99.9% chance the state is implemented using well-known emacs primitives like buffers, whereas for general programs launched from the shell there is no standard set of UI and text manipulation libraries.
There isn't functionality in bash to magically jump to the C++ source code of Thunderbird or read variables from its internal state, which is the key difference.
And now we're talking about something entirely different.
How? Interacting with the state of emacs software is exactly what the OP was talking about.
I haven’t delved into emacs yet. Don’t you still have it configure it and all its tools?
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.
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.
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.
There are modifications of emacs that appeal to normies like spacemacs
You should check out vim's remote functionality to open files in an already running instance https://vim-jp.org/vimdoc-en/remote.html
> 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.
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.
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.
This stuff is beautiful. I still don't understand how nobody has built a nice AI typeahead for the terminal yet. Cursor tab would legit be perfect but they'd don't allow it in terminal. I'm almost tempted to just hack together a product where the terminal gets piped to a fake file and fed into cursor for now.
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...
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.
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.
The golden mean between "customize literally everything" and "never stray from the basics", imo, is to pick and maintain a stack of blessed +2 vorpal binaries that work well even without any of your dotfiles or n=1 designs being present.
That's why I build off of the programs my Shell Bling Ubuntu [1] installs. Not everything I use in an average day is in there, but everything I find myself shocked not to have on a new Ubuntu VM out of the box is.
[1]: https://github.com/hiAndrewQuinn/shell-bling-ubuntu
> terminals are stupidly powerful and most of them expose almost none of it to you as the user.
Well, they aren't really, and given the fundamentally flawed foundation of all text as the lowest common denominator, that power is not exposed.
For example, your regex path detection logic is invariably flawed, and while there are ways to mark the output with extra codes as paths so you could just click on them to open in whatever editor, that requires the whole processing pipeline to stray from the plain text (and might still not allow you to search for files only by type)
I use:
This lets me use tmux+cscope as a poor-man's mouse-less IDE.I miss the console terminal where Alt-F# directly selects a terminal by index. So:
So use a terminal emulator which lets you set this up.
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.
I’ve tried all kinds of tools but I always end up back at the terminal. It’s simple, direct, and helps me stay focused which makes me work more efficiently. Being productive isn’t always about using the newest tools. It’s about finding what really fits your rhythm. The terminal might look basic but it’s a minimal and powerful way to get things done.
I've been using a very similar setup with vim/tmux for about 20 years. I've tried all the new IDEs but still keep coming back. With AI, I thought I was going to have to change until Claude code. Now I'm back in my happy place.
Same!
So relieved Claude Code and Aider exist now - I almost bought into the Cursor hype
Can somebody help me, a CLI layman, out? How can I easily navigate printed directories like he does, in zsh, and paste them right into my prompt, e.g. for Git use? Is that where the tmux regex stuff comes in? Can I use that in iTerm 2?
If you’re on iTerm2, then perhaps the Cmd-; completion shows what you want. Otherwise, it sounds like he’s using `tmux-fingers`, but I can’t confirm as the video doesn’t play on iOS / Safari.
Hm, Cmd+; seems to work! I will try it more out in the wild. Thank you!
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
I made my own fuzzy ripgrep, rgf. Works like rg but then pipes into fzf. When selected, your editor pops up on that line. Pretty handy.
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.
Searches in a directory.. do you mean files or file contents? What do you do for his example of navigating to a file from the rust tool output?
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.
This seems to be Powershell though so not that relevant for me unfortunately. I'd love to see this about zfs
How was the async loading of zsh config accomplished? Just says it did it.. but how?
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.
Reminds me of Plan 9 with its plumber! Especially when combined with Acme, win and right clicking to search backwards.
Why use consistent punctuation but not consistent capitalization? Seems like an odd intentional choice.
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.
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.
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.
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.
Really that good? I've got back into using Cursor and if seems theyved u1
I'm a tmux/vim user and heavily use claude code. It's good.
Which video player is that ? I like the time coded videos as links.
Are there any terminal emulators that do server-side session management without needing Tmux?
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
wezterm may be something to look into.
So, he uses tmux on Windows? How does that actually work? Can someone elaborate on it?
I believe he is remoting into a Unix system to do his actual work. The Unix system can have tmux installed and running on it perfectly fine. I've done this too, to the extreme of SSHing into my own Virtualbox VM just to get that perfect compatibility layer that WSL still can't quite match.
Indeed, this is one of the strongest arguments for tmux versus other approaches to this problem. It can run on the server you're remoted into and still do its job. https://hiandrewquinn.github.io/til-site/posts/tmux-is-worse...
I do most of this but via neovim using Telescope & live_grep, works well enough.
this is cool but acting like this is some insane usage is funniest part for me. emacs and 100 other tools can do this easily and have been doing it for 30 years
This tmux stuff is just silly. Everything what is does nvim does out of the box.
Is this only possible with tmux? Is there a step learning curve with tmux?
tmux probably takes about a day to learn the basics of. If all you get out of it is the ability to split your terminal screen even inside a remote SSH connection I'd say it's worth it.
You can fall down an unexpectedly vast rabbit hole with its customisability, however, since multiplexers see so much of what's going on in a very general way (by design).
If it is not possible with GNU Screen it would be the first feature I've seen that Tmux has over it.
Windows? didn't expect that
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".
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.
You do know vanilla vim can fuzzy search and autocomplete file names? I can’t imagine copy pasting filenames…
[dead]
[dead]
[dead]
Backed out at C:\users ...
Well at least you’re not judging the book by its cover.
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.