But I'd still rather use it than just about any other text editor, just for the simplicity of that muscle memory alone. I have way more stuff to keep in my head than I have room for and I can't afford to expend more than about 0.0001% of context on a text editor.
I can't say I agree. To me this is equivalent to saying "I have way more music in my head than I have room for and I can't afford to expend more than about 0.0001% of context on a piano". The tool you use for 8+ hours a day is extremely important and even small gains will pay dividends over the long run. The more efficiently the text editor allows you to do tasks, the more time you have to think about other tasks.
Hence, I will stick to my piano.
> I consider my vi/vim skills to be extremely minimalist subset, and probably horribly inefficient
Likewise, "I don't configure anything from the default" could be likened to playing an out-of-tune piano because you just can't be bothered. If you genuinely switch machines so often that configuration becomes a burden, sure, stick with the defaults -- but I think it's doing yourself a bit of a disservice if your reason is instead "I don't think it's worth spending time or mental energy on my tools".
Bill Joy, the original author of vi, saw the vi commands as a problem, not a solution [1]:
The fundamental problem with vi is that it doesn't have a mouse and therefore you've got all these commands. In some sense, its backwards from the kind of thing you'd get from a mouse-oriented thing.
[1]: https://web.archive.org/web/20120210184000/http://web.cecs.p...Even if you remember the general placement of things? You still have to consciously track where the pointer is and when it will be on target. I was better with old applications where everything was accessible, bit in this era of low density interface and deep navigation, it’s not great.
The Acme editor is a great example on how to use the mouse. Every click results in an action. And a customizable interface so that you can have what you need at the ready.
:set mouse-=a
But I made the switch to nvim / LazyVim. And it is actually pretty good. I had in mind those endless hours of config and lua scripting. At the end of the day all I needed actually was to remove a plugin (folke, which messes with my 's' key) and learn to use the package manager to setup the languages I wanted.
Having things like GrugFAR or lazygit at the tip of my finger is actually a quality of life improvement. I could do without those for sure but they fit my workflow and muscle memory well.
Still wish there was something better for ansible ; I should have gone with pyinfra with my current job's project but I only learned about it after writing 12k LoCs of ansible :'(
But then I discovered https://www.lazyvim.org/. Turns your copy of NeoVim into an IDE.
I still haven't edited the default config much, actually. But now I'm probably 2x to 3x as productive in vim (nvim, now) as before.
P.S. If you decide to check out the LazyVim config, I highly recommend reading https://lazyvim-ambitious-devs.phillips.codes/ all the way through. There's a lot of new keybindings to learn, but Dusty Phillips's book gives you a gentle on-ramp to learning most of them.
I wrote about how it works in https://news.ycombinator.com/item?id=48118585 so I won't repeat that here. But if I had to pick my favorite feature from LazyVim's config... well, actually it would probably be something else, but `s` is definitely in the top three by now.
BTW: The Vimium extension [1] for Firefox has a similar mode for links called "linkHinting" which I've mapped to s[2] for a similar experience in the browser :)
[1]: addons.mozilla.org/en-US/firefox/addon/vimium-ff/
[2]: `map s LinkHints.activateMode`
Right now I think my .vimrc is two lines. That's also sort of silly as I benefit very little from all the things Vim can do.
What really seals the AstroNVim deal for me though is the community packs. People have very thoughtfully integrated support for a huge range of nvim plugins. And it's super easy to install, and they often fit in nicely to the existing out of box experience of nvim. https://github.com/AstroNvim/astrocommunity
On one of my servers I needed to disable icons which AstroNVim handles very conveniently (https://docs.astronvim.com/recipes/icons/#disable-icons). After switching I noticed that using AstroNVim feels so much more natural to me. It's been a joy to use.
I think it might be because the defaults are less bespoke and it's just a bit leaner. The community packs have also been great for customization.
Once in a while I will mistakenly dump a string of keystrokes into insert mode or another application. That literal output always amazes me because the construction of those strings is so far removed from my brain's "main thread".
The inverse is if I try to write a helper function or explain to someone else how I did something they observed and I need to methodically document each action. It's like trying to describe how to walk or something.
I tried nvim integration but it was half-baked and I can't even use nvim as an editor because they removed cscope support. nvi back in the day also dropped support for cscope because it wasn't vi enough. Hell, there is barely a working source repository for it. Only vim supports it out of the box. Am I the only person using cscope in 2026?
As of current day, I only use vim with no plugins to edit source code.
The comments about LLM contributed code seems like a specific axe to grind that otherwise detracts from a nice history lesson.
The existence of vim classic would be hard to explain without reference to LLMs.
That advice was not entirely accurate (sometimes vi is in /usr/bin/vi, for example), and the merging of /bin with /usr/bin has made it kind of a moot point. (EDIT to add: Though the fact that busybox includes a basic vi implementation has kind of un-mooted the point, actually). But I first started learning vi because I figured I would need it professionally, and when the modal-editing workflow "clicked" for me, I figured out that I had just learned the editor I would want to stick with for years.
And although vim replaced vi and nvim replaced vim in my finger-macros, that has remained true to this day.
You don't need emacs on a server. TRAMP is built-in and can open remote files in a local instance over SSH, SMB, FTP, ADB, or docker/podman.
As an extreme example, today I needed to combine parts of two files into one and decided that
cat foo bar > foobar && mv foobar bar && vim bar
of all things will better keep me in the flow than either googling how to insert one file into another in vim or starting up TRAMP.EDIT: Found http://www.fifi.org/doc/tramp/tramp-emacs.html which mentions that TRAMP started development in November 1998. I would have been getting that advice in late 1997 or early 1998, given when I started my Unix class at college. So the answer appears to be that the advice was actually correct at the time, but superseded sooner than I thought it was.
Of course, if your problem is "/usr won't mount", then it's likely that the ftp server isn't running either, so the advice still makes sense.
Also, I have not been following the d2d development of vim closely after Bram's passing but I can't help but wonder what he'd have thought about this approach to development of vim.
Seems like an interesting fact for those who don't follow the development of vim/neovim.
I have learned it back in Xenix heyday, and decided I was better off with Emacs.
Unfortunely not every server has Emacs pre-installed.
On my own devenv I would rather reach out to IDEs, that replicate as much as possible the Xerox PARC / Symbolics / TI experience.
Helix mode in zed is closest to my perfect text editor right now. Does everything helix does but with alt-up/alt-down to move lines, and a few other little things like that that you'd expect a modern editor to have.
I am but a lowly mouse/GUI user so rarely have to dwell in a shell, but I learnt the basics of vi in my 1st year of university and never forgotten. Gotten me out of many a pickle being able to reliably edit a file quickly.
I'm a GUI user too but using helix-mode (like vim-mode but IMO more intuitive) in my GUI editor, zed, gives me the benefits of both.
If anyone wants to have a look: https://www.youtube.com/watch?v=IXBC85SGC0Q
Correction, the driver is specifically for Apple Xserve front-panel