I consider my vi/vim skills to be extremely minimalist subset, and probably horribly inefficient, since they were developed to work accross a broad range of UNIX systems (SCO, Solaris, HP-UX, OSF, AIX) and I rarely add anything to my vim configs on top of that other than syntax highlighting.
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 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.
He IS saying that. Vi is more efficient for him every hour every day because he has been able to learn it to the point where there is nearly zero effort in using it. To learn something else would be to throw away all that hardcoded memory and try to rebuild it.
To continue the musical instrument analogy, I already master the piano and I am happy with it solving my requirements. Learning the guitar will be a great undertaking, and provide me no new songs to play.
> 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".
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 should mention what is becoming my favorite thing about LazyVim's default config, which is the "flash" or "seek" command (LazyVim maps it to `s` so I think of it as "seek") from https://github.com/folke/flash.nvim. I didn't like it at first as I was used to typing `s` to quickly replace a single character with a bunch of text (as opposed to `r` which replaces it with just one character). But I soon learned to remap my brain to use `cl` where I used to use `s`, and then I learned to love "flash"/"seek" mode.
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.
Flash is amazing, and what made me drop VSCode. Flash feels like an innovation and basically lets me move my cursor at almost the speed of thought. Highly recommend people try it out and play with it!
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 :)
I similarly thank the stars I ran into AstroNVim, which itself is based on LazyVim. Out of the box it has a lot of well integrated/just works pieces. It has a bunch of leader key things setup, and, crucially, a little visual navigator at the bottom of the screen. Going from powerful but invisible to having something I could see was such a help! I'd compare it to moving from tmux to zellij but I'm a pretty happy tmux user. https://astronvim.com/
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
Yeah, I have also been really impressed with AstroNVim. I tried using LazyVim for quite some time but I kept having a hard time getting used to it. Somehow I kept tripping up when trying to do things.
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.
I think that it's wrong to assume that vi is the only route to deep muscle memory. Heavy mouse users develop blindingly fast Fitts’ Law targeting. And if you need essential simplicity, they have far fewer commands.
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.
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.
Likewise, I'm also not very demanding of my text editor. I used vi on any *nix systems and Notepad (the original one, not the new bloated monstrosity) on Windows for most of my work. Navigation, basic editing, and searching are probably all I need.
Helix, although a bit barebones by default, has been so much nicer for me recently than any of the vi editors so far. Love the default motions so much more, and having multi-cursor adds so much to the day to day 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.
One thing I noticed that with Claude Code and Codex running in the terminal, I tend to use VS Code much less than before, and found myself opening files in vim more often. It just looks like, for me, the agent development brings me back to using the basic tools, like many years ago, before VS Code existed.
This is interesting to me. vim was my main editor since the start of my career and I was very fast with it, much faster than my peers with an editor. at the outset of llm’s, I ended up using a plugin that would utilize bindings to help me edit faster. with claude code, and how fast it is making changes across many files, I almost never use vim anymore, or vi, unless I need to inspect files in a container/server.
Funny, because the only reason I fire up VSCode is to chat up the bots because we are AI-compliant now and the customers pay for it.
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.
If anyone wanted to write a minimal vi-style helix clone they should call it 'ix', as it's derived from helix, gives a nod to 'vi' and a wink at the turning of vi syntax on its head, like rotating a six to make a nine. Then a descendent of 'ix' could be called 'six', and we'll have come full circle.
Jokes aside, I don't really see the appeal of a demake of helix; it only really makes sense to me as "vim but far more concepts integrated as first-class features rather than addons"; take that away and you have vi with less muscle memory. So, kakuone with the serial numbers filed off.
The history and endurance of vi is impressive. I never thought I would be using the same editor today that I started using in the mid 90s because it was more l33t.
The comments about LLM contributed code seems like a specific axe to grind that otherwise detracts from a nice history lesson.
yes, but that could've been part of the explanation in vim-classic. Other attributes and reasons for improving/forking are explained in the entry of the fork.
I started learning vi around the same time, but in my case (since I was expecting to work on Unix systems for decades, which has proven true) it was "because it'll always be there." I.e. if you're SSHing into a server to fix a problem, it's possible that /usr/bin/emacs won't be there (perhaps the problem you're fixing is that /usr isn't mounting), but you can nearly always count on /bin/vi being available: if you can access the server at all, you will be able to access vi, so at least learn its basic keystrokes, our prof told us.
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.
I often use vim despite knowing only a few basic commands because I'm already running various commands on the remote machine in the terminal and don't want the context switch. And because connection / file path completion in TRAMP is annoyingly slow if the server is far enough.
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.
Yes, I can use TRAMP but as I ssh to the server anyway to run commands, I'm editing the files with vi there. Furthermore I'm sure I don't inadvertently edit the local version of the file instead of the remote one, or that I forget to kill the buffer with the remote file and edit it instead of the local one after a few days. What's on the server stays on the server.
Never really learned emacs so didn't know TRAMP existed. When was it created? I was given that advice ("vi will always be available on the server") in the late 90's so I'm curious to know if TRAMP was an option my prof didn't know about (or didn't mention), or whether it was developed later and the advice was good at the time.
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.
Well, TRAMP was preceded by ange-ftp, which let you edit files remotely over ftp. I was using that in 1995, and I didn't get the impression then that it was brand new, so it had probably been around for a while already.
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.
The inclusion of comments about LLM generated code don't bother me and will probably be quite revealing (for better or worse) when people read this post in the future.
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.
I first used ed(1) back in the ye olden days of early 1980s, vi was like a major advance.
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.
Interesting the history is varied for such a simple tool.
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.
> If you’re wondering why so many people would choose to use a fifty year old text editor with a notoriously steep initial learning curve, it’s because once you learn it, you can be ruthlessly efficient with your editing.
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.
I, for one, am happy that every terminal I've ever used still supports Emacs shortcuts. Useful, for instance, to cut a whole line and paste it later on (ctrl+k, ctrl+y).
Those are not terminal shortcuts. They are program shortcuts. E.g. bash supports Emacs command line editing shortcuts using GNU Readline library. But the library (and bash) support vi mode editing too. POSIX sh(1) specifies vi-mode command line editing only.
I learned vi in '86 or so mid way through the CS course I did. Later on I used emacs and various other editors for many years. The weird thing is that the basic vi commands are hardwired in my brain - I could happily edit a file in vi but I'd be stuck if I had to use emacs (even though I actually used emacs for far longer)...
Interesting. Besides the navigation commands and the most basic of shortcuts, I've never been able to learn vi keybindings, even when I was actively trying. Half the time I still can't remember whether j or k is up.
The first work i had to use vi and screen on a terminal, it were in 90s . I was used to dos editors ( edit, turbo C ... ) and windows . It was a pain. copy and paste at first was a nightmare. Copy from one file to another ,with named register and # was an hell ( it was vi not vim so only 2 files a time ,the actual edited and the prior ones ). I hated that place, that work, those tool for a while . I got so used to vi, to modify columns with regular expression or macro that now, more than 30 years after , vi/vim is the first thing I install on a PC and when i have to modify a file, or to do something complex, the first and last resort for doing it without python or perl, is always vi . But the beginning at 25 years old was very hard because it was a kind of editing even at those time completely out of my usual way to work . Now it is the only editor that i open and use without thinking . VSCode is great, tons of features, but when i see all those menu, if i can, i use vi . I would add a point. for a while i went behind vim features, try to learn them and use them but they are too many and i often work on different machine so i can not move my setup everywhere. Learning the "old vi way" of doing things (motion, regexp,registers, macros ) can seem "limiting", but at the end you can do quite everything with the same tool .
Bram is a glaring omission in the vi family tree, too. Though, they'd have to draw the line somewhere (i.e. include nvim creator?) and maybe it's better leave individual people out.
I had a mini holiday job working for (long since gone from NZ) Philips Design and Development Laboratory in 1992. As part of that I worked on some tools for their silicon graphics workstations. I was shown vi, and how to get help and left to it. Tough learning curve! Seemed ridiculous at first, then I developed a mini set of editing skills and got used to it! Still using Vim/Nvim today.
When I was in college in 2001, I went to the library and checked out Kaare Christian's book called "The UNIX Operating System". One of the early chapters covered vi - I'd telnet into the school's Sun server with a pretty early version of vi (one-level undo) and follow the examples. Never looked back!
This list is very useful; Vile isn’t quite Vi, but it’s close enough, and it includes a Windows32 binary which works with UTF-8 (albeit in a separate window), and fits in under 700k (7-zip compressed).
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.
Early tractors were attempted in 1800s but most farmers ignored them as they were complex, expensive and occasionally exploded[1].
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...
Pretty well if you consider the "bio" label, which is a set of practices not using all of the tech. They can ask for and usually get higher prices for the products.
Granted, it's more about chemicals than tractors, but still quite close to the spirit of the comments. Bio approach sacrifices some tech advances.
Long ago I wrote my own really incomplete vi subset for the C64 that I really should dust off. But there's a more polished vi clone for 6502 machines, including the C64, Apple II and Atari: https://vi65.sourceforge.net/
vis is absolutely great. Wish more people were aware of it (and it's cool it is mentioned in the post) and that more people used it. I still miss some features from vim, like buffers, but feels so much snappier, lighter and intuitive - and the structural regular expressions part is outstanding.
I didn't know about vim-classic, I've switched to it now. I can't really notice much of a difference except themes are missing... and fzf needed a fix.
I think describing Kakoune/Helix as vi-inspired with “slightly different keybindings” is rather missing the point.
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.
cool stuff, for a bunch i didnt realise they were really distinct versions!
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)
Had someone else parrot this line to me the other day, but I remain unconvinced. Especially when vim has visual mode, and you often can make a select before doing something to it. v$ to select from cursor to end of line, then d to cut or y to copy. Is that not the sort of thing you mean? Is visual mode in vim just underused?
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?
Something rather similar to visual mode, and which I've learned to like a lot, is the https://github.com/folke/flash.nvim plugin (NeoVim only since it uses Lua). It gives you a commmand you can bind to a key (https://www.lazyvim.org/ defaults to binding it to `s` for "Seek"). Press that key and then type a couple letters that appear somewhere on your screen. All occurrences of the letters you typed will be highlighted (and the rest will be dimmed), and next to each of them will appear a bright, contrasting letter that serves as a label. Type the label character and you will jump to the start position of the text you typed.
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?
Well that's one extra key press for every action. For example, you have to do `ved` to delete the current word instead of `de`. Whereas in Helix it's just `ed`.
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.
I think you're right and visual mode is underused. It gives you the best of both worlds: "cw" meaning "change word" for when it's obvious what you're going to be selecting, and "v3wwwc" for "change 5 words" when you discover (by experimentation) that the text you wanted to change actually counted as 5 words due to punctuation, not 3 as you had first thought.
I really want to use Helix, it clicks with me so much more. But I do not want to learn how to use Helix for development. I want to be able to continue using VSCode. And last I checked, the VSCode extension was not very good. I also use Vim keybindings in Obsidian.
The moment VSCode and Obsidian support improves, I am switching immediately.
Sam isn't graphical there is sam and samterm which sends commands to sam. sam itself is an ed style line editor, where the concept of a line is replaced with a dot. vis allows multiple dots.
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.
I'm more in the vim camp, but I will say emacs has one of the best GUIs out there. Everything that works in the terminal still works (great keyboard accessibility), plus you get additional benefits, like proper window separation that isn't just a text character drawing an imaginary line (so copying lines of text with the mouse when you have a bunch of splits is easier). There's also image support, you can connect to a server with TRAMP, open up dired, and view remote images right in emacs. I always thought that was cool.
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.
Being able to choose is a good thing. Use what works for you. I prefer the terminal, but not as hard core as switching to a TTY and never see a GUI again...
It’s funny how many forks aiming to keep it free from LLM-generated code. The luddites are present even in the most progressive parts of the population.
I think you are wrong. Luddites don’t seem to exist any more, at least not on this board. Luddites had the courage to smash machines. People on this board might have complaints about LLM but then they will say well what can I do, protesting these developments is not on the Story Board.
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.
allow me to quote the Ancients, the vi creator himself:
> 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?
That's why it's so complicated, and has left and right parentheses commands. You start out with a clean concept and then sort of accrete guano. It lands on you and sticks and you can't do anything about it really.
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.
I consider my vi/vim skills to be extremely minimalist subset, and probably horribly inefficient, since they were developed to work accross a broad range of UNIX systems (SCO, Solaris, HP-UX, OSF, AIX) and I rarely add anything to my vim configs on top of that other than syntax highlighting.
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 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.
He IS saying that. Vi is more efficient for him every hour every day because he has been able to learn it to the point where there is nearly zero effort in using it. To learn something else would be to throw away all that hardcoded memory and try to rebuild it.
To continue the musical instrument analogy, I already master the piano and I am happy with it solving my requirements. Learning the guitar will be a great undertaking, and provide me no new songs to play.
Hence, I will stick to my piano.
They didn't say they mastered the piano, though.
> 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".
I never edited the default config much.
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 should mention what is becoming my favorite thing about LazyVim's default config, which is the "flash" or "seek" command (LazyVim maps it to `s` so I think of it as "seek") from https://github.com/folke/flash.nvim. I didn't like it at first as I was used to typing `s` to quickly replace a single character with a bunch of text (as opposed to `r` which replaces it with just one character). But I soon learned to remap my brain to use `cl` where I used to use `s`, and then I learned to love "flash"/"seek" mode.
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.
Flash is amazing, and what made me drop VSCode. Flash feels like an innovation and basically lets me move my cursor at almost the speed of thought. Highly recommend people try it out and play with it!
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`
The demos of LazyVim looks really nice, and people seem to get a benefit/joy out of it. I gave it a try, but it's a little to much for me.
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 similarly thank the stars I ran into AstroNVim, which itself is based on LazyVim. Out of the box it has a lot of well integrated/just works pieces. It has a bunch of leader key things setup, and, crucially, a little visual navigator at the bottom of the screen. Going from powerful but invisible to having something I could see was such a help! I'd compare it to moving from tmux to zellij but I'm a pretty happy tmux user. https://astronvim.com/
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
Yeah, I have also been really impressed with AstroNVim. I tried using LazyVim for quite some time but I kept having a hard time getting used to it. Somehow I kept tripping up when trying to do things.
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.
I think that it's wrong to assume that vi is the only route to deep muscle memory. Heavy mouse users develop blindingly fast Fitts’ Law targeting. And if you need essential simplicity, they have far fewer commands.
Bill Joy, the original author of vi, saw the vi commands as a problem, not a solution [1]:
[1]: https://web.archive.org/web/20120210184000/http://web.cecs.p...> that muscle memory
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.
Likewise, I'm also not very demanding of my text editor. I used vi on any *nix systems and Notepad (the original one, not the new bloated monstrosity) on Windows for most of my work. Navigation, basic editing, and searching are probably all I need.
Same. I barely edit default configs. I also mostly use emulators provided by whatever ide I use.
Helix, although a bit barebones by default, has been so much nicer for me recently than any of the vi editors so far. Love the default motions so much more, and having multi-cursor adds so much to the day to day 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.
One thing I noticed that with Claude Code and Codex running in the terminal, I tend to use VS Code much less than before, and found myself opening files in vim more often. It just looks like, for me, the agent development brings me back to using the basic tools, like many years ago, before VS Code existed.
This is interesting to me. vim was my main editor since the start of my career and I was very fast with it, much faster than my peers with an editor. at the outset of llm’s, I ended up using a plugin that would utilize bindings to help me edit faster. with claude code, and how fast it is making changes across many files, I almost never use vim anymore, or vi, unless I need to inspect files in a container/server.
Funny, because the only reason I fire up VSCode is to chat up the bots because we are AI-compliant now and the customers pay for it.
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.
Yes indeed, same here!
If anyone wanted to write a minimal vi-style helix clone they should call it 'ix', as it's derived from helix, gives a nod to 'vi' and a wink at the turning of vi syntax on its head, like rotating a six to make a nine. Then a descendent of 'ix' could be called 'six', and we'll have come full circle.
Jokes aside, I don't really see the appeal of a demake of helix; it only really makes sense to me as "vim but far more concepts integrated as first-class features rather than addons"; take that away and you have vi with less muscle memory. So, kakuone with the serial numbers filed off.
The history and endurance of vi is impressive. I never thought I would be using the same editor today that I started using in the mid 90s because it was more l33t.
The comments about LLM contributed code seems like a specific axe to grind that otherwise detracts from a nice history lesson.
> 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.
yes, but that could've been part of the explanation in vim-classic. Other attributes and reasons for improving/forking are explained in the entry of the fork.
I started learning vi around the same time, but in my case (since I was expecting to work on Unix systems for decades, which has proven true) it was "because it'll always be there." I.e. if you're SSHing into a server to fix a problem, it's possible that /usr/bin/emacs won't be there (perhaps the problem you're fixing is that /usr isn't mounting), but you can nearly always count on /bin/vi being available: if you can access the server at all, you will be able to access vi, so at least learn its basic keystrokes, our prof told us.
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.
> if you're SSHing into a server to fix a problem, it's possible that /usr/bin/emacs won't be there
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.
I often use vim despite knowing only a few basic commands because I'm already running various commands on the remote machine in the terminal and don't want the context switch. And because connection / file path completion in TRAMP is annoyingly slow if the server is far enough.
As an extreme example, today I needed to combine parts of two files into one and decided that
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.Yes, I can use TRAMP but as I ssh to the server anyway to run commands, I'm editing the files with vi there. Furthermore I'm sure I don't inadvertently edit the local version of the file instead of the remote one, or that I forget to kill the buffer with the remote file and edit it instead of the local one after a few days. What's on the server stays on the server.
Never really learned emacs so didn't know TRAMP existed. When was it created? I was given that advice ("vi will always be available on the server") in the late 90's so I'm curious to know if TRAMP was an option my prof didn't know about (or didn't mention), or whether it was developed later and the advice was good at the time.
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.
Well, TRAMP was preceded by ange-ftp, which let you edit files remotely over ftp. I was using that in 1995, and I didn't get the impression then that it was brand new, so it had probably been around for a while already.
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.
The inclusion of comments about LLM generated code don't bother me and will probably be quite revealing (for better or worse) when people read this post in the future.
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.
The comments about LLM contributed code seems like a specific axe to grind that otherwise detracts from a nice history lesson.
Seems like an interesting fact for those who don't follow the development of vim/neovim.
Debian is using this upstream repository for nvi and UTF-8 is supported.
https://repo.or.cz/nvi.git
I first used ed(1) back in the ye olden days of early 1980s, vi was like a major advance.
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.
Interesting the history is varied for such a simple tool.
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.
Neovim supports the mouse by the way.
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.
Simple tool? Visual text editor is probably the most complicated piece of software in coreutils.
...and presumably quit vi once you're done!
I have typed either :wq or ZZ into so many files in VS Code... :-)
> If you’re wondering why so many people would choose to use a fifty year old text editor with a notoriously steep initial learning curve, it’s because once you learn it, you can be ruthlessly efficient with your editing.
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.
I, for one, am happy that every terminal I've ever used still supports Emacs shortcuts. Useful, for instance, to cut a whole line and paste it later on (ctrl+k, ctrl+y).
Those are not terminal shortcuts. They are program shortcuts. E.g. bash supports Emacs command line editing shortcuts using GNU Readline library. But the library (and bash) support vi mode editing too. POSIX sh(1) specifies vi-mode command line editing only.
Agreed.
I learned vi in '86 or so mid way through the CS course I did. Later on I used emacs and various other editors for many years. The weird thing is that the basic vi commands are hardwired in my brain - I could happily edit a file in vi but I'd be stuck if I had to use emacs (even though I actually used emacs for far longer)...
Interesting. Besides the navigation commands and the most basic of shortcuts, I've never been able to learn vi keybindings, even when I was actively trying. Half the time I still can't remember whether j or k is up.
Few days ago I watched a video where a guy wrote the code for Linux USB driver from scratch. In frickin' vi! It was a ride
And he doesn’t use any config it seems. No syntax highlighting, no line numbers, plain white text on dark background.
Exactly, it's wild!
If anyone wants to have a look: https://www.youtube.com/watch?v=IXBC85SGC0Q
Correction, the driver is specifically for Apple Xserve front-panel
What is also wild is that the video has 2.5M views, very odd.
The first work i had to use vi and screen on a terminal, it were in 90s . I was used to dos editors ( edit, turbo C ... ) and windows . It was a pain. copy and paste at first was a nightmare. Copy from one file to another ,with named register and # was an hell ( it was vi not vim so only 2 files a time ,the actual edited and the prior ones ). I hated that place, that work, those tool for a while . I got so used to vi, to modify columns with regular expression or macro that now, more than 30 years after , vi/vim is the first thing I install on a PC and when i have to modify a file, or to do something complex, the first and last resort for doing it without python or perl, is always vi . But the beginning at 25 years old was very hard because it was a kind of editing even at those time completely out of my usual way to work . Now it is the only editor that i open and use without thinking . VSCode is great, tons of features, but when i see all those menu, if i can, i use vi . I would add a point. for a while i went behind vim features, try to learn them and use them but they are too many and i often work on different machine so i can not move my setup everywhere. Learning the "old vi way" of doing things (motion, regexp,registers, macros ) can seem "limiting", but at the end you can do quite everything with the same tool .
I actually learned VI using DOS and the Watcom C/C++ compiler and 32 bit dos extender, as it included a vi clone.
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'm vim poweruser since around 2009. When I use VSCodium (not that much today) I obviously use Vim emulation.
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.
How does an article like this not mention Bill Joy??
Bram is a glaring omission in the vi family tree, too. Though, they'd have to draw the line somewhere (i.e. include nvim creator?) and maybe it's better leave individual people out.
I had a mini holiday job working for (long since gone from NZ) Philips Design and Development Laboratory in 1992. As part of that I worked on some tools for their silicon graphics workstations. I was shown vi, and how to get help and left to it. Tough learning curve! Seemed ridiculous at first, then I developed a mini set of editing skills and got used to it! Still using Vim/Nvim today.
When I was in college in 2001, I went to the library and checked out Kaare Christian's book called "The UNIX Operating System". One of the early chapters covered vi - I'd telnet into the school's Sun server with a pretty early version of vi (one-level undo) and follow the examples. Never looked back!
This list is very useful; Vile isn’t quite Vi, but it’s close enough, and it includes a Windows32 binary which works with UTF-8 (albeit in a separate window), and fits in under 700k (7-zip compressed).
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.
Interesting that there is such a clearly stated differentiation between projects that use "LLM-generated code" and those who don't.
I wonder how it went for the farms that stuck to "non-tractor-generated crops" in the 1900s.
Early tractors were attempted in 1800s but most farmers ignored them as they were complex, expensive and occasionally exploded[1].
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...
Pretty well if you consider the "bio" label, which is a set of practices not using all of the tech. They can ask for and usually get higher prices for the products.
Granted, it's more about chemicals than tractors, but still quite close to the spirit of the comments. Bio approach sacrifices some tech advances.
Long ago I wrote my own really incomplete vi subset for the C64 that I really should dust off. But there's a more polished vi clone for 6502 machines, including the C64, Apple II and Atari: https://vi65.sourceforge.net/
vis is absolutely great. Wish more people were aware of it (and it's cool it is mentioned in the post) and that more people used it. I still miss some features from vim, like buffers, but feels so much snappier, lighter and intuitive - and the structural regular expressions part is outstanding.
If the author is reading this: would be nice to have a "family tree" diagram.
Hi you may want to include neatvi[0] and nextvi[1].
[0]: https://github.com/aligrudi/neatvi
[1]: https://github.com/kyx0r/nextvi
I didn't know about vim-classic, I've switched to it now. I can't really notice much of a difference except themes are missing... and fzf needed a fix.
I think describing Kakoune/Helix as vi-inspired with “slightly different keybindings” is rather missing the point.
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.
There was onivim that was a bit hyped a few years ago but unfortunately it died
cool stuff, for a bunch i didnt realise they were really distinct versions!
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)
Helix's selection-action feels way more natural to me than vi/vim's action-selection.
Had someone else parrot this line to me the other day, but I remain unconvinced. Especially when vim has visual mode, and you often can make a select before doing something to it. v$ to select from cursor to end of line, then d to cut or y to copy. Is that not the sort of thing you mean? Is visual mode in vim just underused?
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?
Something rather similar to visual mode, and which I've learned to like a lot, is the https://github.com/folke/flash.nvim plugin (NeoVim only since it uses Lua). It gives you a commmand you can bind to a key (https://www.lazyvim.org/ defaults to binding it to `s` for "Seek"). Press that key and then type a couple letters that appear somewhere on your screen. All occurrences of the letters you typed will be highlighted (and the rest will be dimmed), and next to each of them will appear a bright, contrasting letter that serves as a label. Type the label character and you will jump to the start position of the text you typed.
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?
Well that's one extra key press for every action. For example, you have to do `ved` to delete the current word instead of `de`. Whereas in Helix it's just `ed`.
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.
I think you're right and visual mode is underused. It gives you the best of both worlds: "cw" meaning "change word" for when it's obvious what you're going to be selecting, and "v3wwwc" for "change 5 words" when you discover (by experimentation) that the text you wanted to change actually counted as 5 words due to punctuation, not 3 as you had first thought.
I really want to use Helix, it clicks with me so much more. But I do not want to learn how to use Helix for development. I want to be able to continue using VSCode. And last I checked, the VSCode extension was not very good. I also use Vim keybindings in Obsidian.
The moment VSCode and Obsidian support improves, I am switching immediately.
Sam isn't graphical there is sam and samterm which sends commands to sam. sam itself is an ed style line editor, where the concept of a line is replaced with a dot. vis allows multiple dots.
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.
I have nothing against Vi or Emacs, but since I strongly prefer GUI and mouse over terminal I use GUI editors.
When I don't have a GUI available, I use micro, nano, joe.
I'm more in the vim camp, but I will say emacs has one of the best GUIs out there. Everything that works in the terminal still works (great keyboard accessibility), plus you get additional benefits, like proper window separation that isn't just a text character drawing an imaginary line (so copying lines of text with the mouse when you have a bunch of splits is easier). There's also image support, you can connect to a server with TRAMP, open up dired, and view remote images right in emacs. I always thought that was cool.
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.
With vim/nvim/gvim etc, you can use both.
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.
Being able to choose is a good thing. Use what works for you. I prefer the terminal, but not as hard core as switching to a TTY and never see a GUI again...
honestly only LLMs can write Vimscript
It’s funny how many forks aiming to keep it free from LLM-generated code. The luddites are present even in the most progressive parts of the population.
I think you are wrong. Luddites don’t seem to exist any more, at least not on this board. Luddites had the courage to smash machines. People on this board might have complaints about LLM but then they will say well what can I do, protesting these developments is not on the Story Board.
Of course this is a total digression.
vi was never progressive, it was "the Ancients knew it better, the present sucks, these kids have terrible taste, return to the one true Past"
The Ancients did know it better.
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.
allow me to quote the Ancients, the vi creator himself:
> 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?
http://xahlee.info/comp/interview_with_bill_joy.html
That's why it's so complicated, and has left and right parentheses commands. You start out with a clean concept and then sort of accrete guano. It lands on you and sticks and you can't do anything about it really.
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.
https://youtu.be/Pr1XXvSaVUQ