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.

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.

I wonder if people who stuck with vi(m) know about Xerox PARC, wysiwyg, gui and nomodes.

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.

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.

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.

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.

> 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.

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

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)...

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'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??

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!

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/

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.

This list is very useful; Vile isn’t quite Vi, but it’s close enough, and it includes a Windows32 binary which works with CP-1252 [1] (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.

[1] https://en.wikipedia.org/wiki/Windows-1252

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.

Hi you may want to include neatvi[0] and nextvi[1].

[0]: https://github.com/aligrudi/neatvi

[1]: https://github.com/kyx0r/nextvi

If the author is reading this: would be nice to have a "family tree" diagram.

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)

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.

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.