The vi family
lpar.ath0.com
lpar.ath0.com
I’ve never used it because I thought it would make me some lightning fast super developer. I’ve always used it because it’s simply fun. It’s makes editing into this interesting sort of game. You start out with a simple set of skills from vimtutor, and inevitably brute force your cursor around the screen for a while. Little by little your movements become more complex and efficient, and the journey to figuring that out is fun and interesting.
It makes you think about typing in a totally different way. It makes it into a some kind of interesting game where your goal is to accomplish a task in the fewest keystrokes possible. That problem solving aspect scratches an itch inside my brain that has always kept me coming back. It’s just fun, and I don’t think that gets talked about enough
I’ve been a long time vim user, and I honestly never really bought into the efficiency claims. That gets repeated over and over, but If you’re a slow typer then no editor can really make much of a difference.
Little by little your movements become more complex and efficient, and the journey to figuring that out is fun and interesting.
It’s just fun, and I don’t think that gets talked about enough
vi definitely doesn't scratch that "itch" for everyone in the same way. But for me, it's as though I found a cheat code. Getting better at vi feels like getting better at a game - only practicing this game makes you better at any number of tasks that are relevant to your daily work.
(although if you also want to get better at typing speed, there are surprisingly fun roguelikes on Steam for just this purpose)
Vi key bindings don't apply outside of vi
The shells themselves also support vi binding.
Outside of the terminal tools like Vimium add support to browsers and many other interfaces.
Macros, dude.
It's a bit annoying to become disciplined in text structure/regularity to have macros work flawlessly, but it's a bliss afterwards.
And then... recursive macros.
(I know Emacs has better macros but vim macros are way easier and fun for everyday use).
The added benefit I found is that Vim’s purely keyboard based design is much, much easier on the wrists. Heck, I pushed myself to learn Vim because I started to feel wrist pain due to KB and mouse switching.
specifically, the keys used by vi were there on every (terminal) keyboard.
In comparison, emacs heavily depended on modifier keys, which were pretty non-standard and if found, frequently were in different places on each keyboard.
That said, more complex editing tasks using modes/automation/etc might be more efficient with emacs.
personally, I have "thresholds". quick/dirty can be vi, more involved goes to emacs. same with scripting, quick/dirty shell script, more involved to something like python. ymmv
My fingers just love it. Every time I need to jump to a non-modal editor my muscle memory screams: "WTF?!"
How about Tiktok then
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.
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`
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.
Ref on lazy.vim: https://docs.astronvim.com/configuration/customizing_plugins...
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.
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.
I never made that switch. The muscle memory of 2 decades of using a software is under appreciated.
For me, it is about preference for what to optimize for.
I love CLI tools that effectively give me the things an IDE would offer such as astgrep for refactoring for example. zoekt with a browser does pretty good indexed searches. fzf can be used to build up almost any useful way of selecting things that you can imagine. So the CLI becomes my IDE.
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.
:set mouse-=a
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.
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.
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 :'(
Nowadays almost never enter vim, because it is 100x faster than I could ever be. I use it for viewing files occasionally but reviewing edits in the claude or codex window usually works just as well. It’s the first skill I expect to decay for me (vim)
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.
I knew there were more visual studio type plugins that may also fit my needs but as I said I do not use plugins. If I install "vim" and it isn't in it, I most likely am not going to use it.
A "language server" also sounds all kinds of wrong although I suppose the function is the same.
The comments about LLM contributed code seems like a specific axe to grind that otherwise detracts from a nice history lesson.
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.
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.
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
Seems like an interesting fact for those who don't follow the development of vim/neovim.
The existence of vim classic would be hard to explain without reference to LLMs.
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.
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.
oh i guess there's GNU Readline, but that's not in coreutils i think
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.
It's worth noting that a lot of the text editing done in the vi family are just calls to ed with different ways of doing selections.
When I use a different editor, there will be lots of jjkk or ,w (I nmap ,w to :w). Habits die hard.
Now I switched to neovim due to the amount of good features I like with it. I use exclusively mini.nvim modules that are awesome.
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.
If anyone wants to have a look: https://www.youtube.com/watch?v=IXBC85SGC0Q
Correction, the driver is specifically for Apple Xserve front-panel
you're thinking about 'Samsung Choco Cookie' :) only know this because someone i know has this set on their phone, and looking at their screen really irritates me for some reason.
some of the openbsd folks use it as a weapon in the fight to prioritize content over presentation. i got a chuckle out of it and it convinced me to stop thoughtlessly hating on comic sans, easy as it is.
you know what, you're right. i'm setting my terminal to this right now, haha: https://dtinth.github.io/comic-mono-font/
Been using vi for decades, mostly nvi and vim 4.6 since UNIX became available for the PC. I still feel like I only utilise a small fraction of what's possible. I believe I do many things "the slow way". In truth I prefer non-interactive editing, e.g., ed, sed, flex
I once saw a video on YouTube that was a "meme" clip of a presenter doing some text manipulation with vi while sharing his screen at a conference. The clip had had been edited to suggest what he was doing with vi was somehow particularly impressive, e.g., mind-blowing "("mind blown")
Everything he was doing was stuff I do all the time. I thought WTF
The most important difference is that they invert the editing model from verb-noun to noun-verb. Meaning you always see exactly what you’re going to be operating on before you do it.
The second most important difference is that they were designed from the ground up around multi-selection editing as a primitive, rather than a plugin or late addition.
That model is typically less efficient purely in terms of keystrokes, for some operations significantly so, but it’s somewhat mitigated if having the state on-screen rather than in your head means you undo less often.
I wouldn’t suggest either approach is superior. I suspect most people (“most people” in the subset of people who jibe with modal editing to begin with, anyway) will find that one just fits their brain better than the other.
Personally, even having used Vim almost daily since finding it on a Fish Disk sometime in the mid-90s, I still turned out to be in the kak/hx group. I can still use vi quite comfortably when I need to, but Helix removed a bit of friction I’d barely been aware of.
There’s a steady stream of NeoVim exiles to Helix forums, I think who mostly found its Lua-based config too complex/brittle, asking why the devs don’t add settings to make it work like Vim, include a *Vim keymap as standard, etc.
It’s kind of wild to me that people would choose their editor based on how minimalist its config/how batteries-included it is, rather than its fundamental editing paradigm.
Maybe it should be included in the list. It can still be downloaded from the openwatcom project, https://openwatcom.org/ftp/manuals/1.5/vi.pdf
I think use of the Watcom compiler led me to Vi way back then, and I am still trying to learn to not use the arrow keys.
Use Helix now as the first one that stuck in my fingers though. before that it was always try a lil while and forget it (back to nano...).
Helix i think is like 'user friendly vi' or maybe 'no config vi'. dont need any plugins or weird stuff. everything essential works out of the box (for me)
Recently I was trying to find a good way to delete from the current position backward to another character, like dT or dF followed by the target character. The trouble was they'd leave at least one character behind, either what I jumped to or what I started on. What worked how I want, and was still easy, was just using visual mode. Where "n" was the character to jump back to, I did vFn which selected from my cursor position back to the letter n (and including that n). I could then hit d and delete all of it, no extra character left behind from either end. I remember at first I was thinking "there's gotta be a way to do this without visual mode". Best I could come up with was hitting x after dFn or whatever to get the stray character. I think using visual mode is probably fine, though. Maybe if I were doing this type of edit a lot I could bind some key sequence to do it.
Would it be accurate to say you didn't use visual mode much in vim before you moved to Helix?
Why is that handy? Well, the idea is that you're probably already looking at the point on the screen you want to move the cursor to, so instead of figuring out a complex navigation, you can type a few keys: `s` plus the letters you're looking at. Then pause for a quarter-second, and type the letter that just appeared where you're looking at. The label letters will be chosen such that none of them appear after the text you typed, e.g. if the words "car", "cat", and "can" all appear in your document, then after you press `sca` the labels `r`, `t`, and `n` will never be chosen. (But the label `d` might be chosen if the word "cad", or words containing it such as "academic", never appear in the document).
It took a little getting used to, but now I've found it's quite the fastest way to issue commands. Want to delete everything from here to that closing parenthesis right there? If you're on its matching open parenthesis then `d%` is fastest, but if you're not, then `ds)` followed by split-second pause to see the label appear (in a bright contrasting color), then type the label. Quite a bit faster than `v` plus a bunch of movement, in my experience. Once you get used to it, it really speeds you up.
And when you get down to it, isn't "once you get used to it, it really speeds you up" a description of the entire vi family of editors in the first place?
Also visual mode doesn't work the same. If I want to delete up to the next word normally I do `dw`, but if I do `vwd` then I also delete the first letter of the next word. I guess in visual mode you'd have to do `vwhd` or `vawd`? Which is 4 keypresses instead of 2, which isn't great for something that I do all the time.
For example, I can move forward by word with 'w' and when I get to the word I want to delete, just hit 'd', or edit it at the beginning with 'i' or end with 'a', or surround with parentheses with 'ms('.
I don't want to have to go into a completely separate mode. It's annoying and I have to constantly be cognizant that I need to switch to that mode just to do basic text editing.
> Had someone else parrot this line to me the other day, but I remain unconvinced.
Side note: this comes off as condescending, as if I need to convince you of the validity of my subjective experience. So, along the same lines: I'm unconvinced there is any good argument for vim's action-selection way of doing things when practically no other UI works like that. It's like hitting ctrl+c before highlighting the text you want to copy with your mouse.
The moment VSCode and Obsidian support improves, I am switching immediately.
On graphical Vis, I liked Cream, which almost made Vim seamless.
https://cream.sourceforge.net/
Instead of GTK2/3, I prefer Athena Vim.
My primary editor for text (not code) editing and e-mail. I just wish Unicode support made it into base vi(1) on OpenBSD, but for now I can at least use it for all other purposes other than the ones in the previous sentence.
This is no joke. I use it to "massage" data in all sorts of files (.json, .xml, .csv, .txt, etc.), with thousands to millions of lines, in no time at all.
When I don't have a GUI available, I use micro, nano, joe.
If you look at many of the ‘user stories’ in this thread (and others), you see a lot of people using vi/vim not because they decided to try it, but because they had no real choice. Very often it’s the only usable option on a Unix-like machine.
And yet, you don’t see many people bemoaning the choice. Despite being forced to use it, once people are over the fabled learning curve they tend to like it.
Vim on the other hand never felt like it benefited much from a GUI, or like it had a very good one available. I just use neovim in a terminal.
Granted, the UI is still TUI, so items like panes, tabs, nerdtree, quickfix, :help windows etc are rendered with characters, but you can drag borders, mouse-select text, click files, focus panes by clicking, scroll-wheel, etc.
I'd use any of them in preference to Vim.
But you might find you like Tilde.
When I started at Red Hat in 2014, they asked if I liked Vim or Emacs, and what was my favourite IRC client. They were boggled when the answers were "neither" and "I can't remember."
I hadn't used IRC since the 1990s or so, and after learning the basics of Vi on SCO Xenix and IBM AIX in 1988-1989 I'd barely looked at it again. I was amazed to find passionate Vi advocates born since the last time I opened vi. It was very strange.
For me, editors moved past the bad old days of 1970s UI in the early 1990s and I've never looked back.
In the '80s I knew dozens of text editor UIs and was fast in all of them. In the 1990s I switched to CUA and never looked back.
My muscle memory is for CUA, and the great thing about it is not only blinding fast text editing, it means I can control the entire OS with the same keystrokes. I don't really need a pointing device at all on a Linux or Windows machine, except for using a web browser.
I use one, because it's always there now, but I can live happily without. My first close blind friend was amazed by the fact that I could operate his PC quite happily. He doesn't own a mouse, because he can't see the pointer. He only has screens on some of his computers so he can watch videos with friends; his UI is 100% speech.
I do need a screen -- I am not very skilled with a screen reader -- but give me a screen and a keyboard and I'm mostly set.
This is for me the selling point of CUA: it's not just an efficient UI and set of keystrokes for a text editor, it also lets me use any compliant app, GUI or text mode, on any platform. Windows 3 to Windows 11, and Xfce, and LXDE, and to a large extent in MATE or Cinnamon or LXQt, on Linux or xBSD.
I wonder how it went for the farms that stuck to "non-tractor-generated crops" in the 1900s.
Granted, it's more about chemicals than tractors, but still quite close to the spirit of the comments. Bio approach sacrifices some tech advances.
Sounds familiar.
[1]: “However, even though steam-powered tractors provided an alternative to draft animals, the size, mechanical complexity and risk of explosion rendered these tractors unusable for most farms.” https://www.volocars.com/blog/history-of-tractors-in-agricul...
By the way there are a lot of farmers that doesn't need the power of tractors to make farming their livehood. Makes sense when you realize that not everything needs to be super fast and efficient, sometimes cheap, slow and constant is enough.
Came in handy when I had to talk a guy through updating a Solaris config file to allow the box to boot when he only had a serial console in the early 2000s.
The alternative is just as steep, if not steeper.
What I wish existed was a fork of Busybox Vi which fully supports UTF-8. I’ve looked at the code and it would require a considerable rewrite to make it UTF-8 compatible, so I can see why it hasn’t been done.
"The we family" :)
I sometimes try working without vim keybindings as it's a pain installing them everywhere. I usually give up the 3rd time I have to delete a function argument and can't dt, or select the body of a function and can't vi{.
For everyone even somewhat decent at vim, having to hold right arrow until the cursor reaches the target is a humiliation ritual, and I genuinely feel second-hand embarrassment and pity when I see people do that.
> What would you do differently?
> JOY: I wish we hadn't used all the keys on the keyboard.
> ...
> JOY: 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.
> Its like one of those pinatas - things that have candy inside but has layer after layer of paper mache on top. It doesn't really have a unified concept. I think if I were going to go back - I wouldn't go back, but start over again.
shots fired:
> JOY: I can just look at my screen, and when I print it off, it's the same as it looks on the screen. It is formatted, and I'm tired of using vi. I get really bored. There have been many nights when I've fallen asleep at the keyboard trying to make a release. At least now I can fall asleep with a mouse in my hand. I use the Xerox optica mouse instead of the other one because it is color coordinated with my office. Did you notice? I prefer the white mouse to the black mouse. You've got to have some fun, right?
But of course he was wrong about 1991-2026:
The days of non-raster stuff are numbered, though sheer momentum will carry it to the end of the decade.
And about AT&T as the same year (1984) they introduced BLIT terminal:
The fundamental tension in UNIX that I think AT&T doesn't understand is that everyone is going to have a bitmap.
The fundamental advantage of vi is that it doesn't have a mouse. If you were born with three arms you can go for sam or something.
Of course this is a total digression.