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.
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.
The comments about LLM contributed code seems like a specific axe to grind that otherwise detracts from a nice history lesson.
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.
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)
When I don't have a GUI available, I use micro, nano, joe.
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 can't say I agree. To me this is equivalent of 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.
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.
The existence of vim classic would be hard to explain without reference to LLMs.
Seems like an interesting fact for those who don't follow the development of vim/neovim.
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.
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.
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?
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.
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?
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.
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 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.
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.
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.
I wonder how it went for the farms that stuck to "non-tractor-generated crops" in the 1900s.
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...
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
Granted, it's more about chemicals than tractors, but still quite close to the spirit of the comments. Bio approach sacrifices some tech advances.
Polls of Linux users suggest that vi family editors are the most popular. The vi editor is a terminal-based text editor which dates back to 1977. 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. There’s also the benefit that it’s basically everywhere, so you don’t have to keep re-learning how to edit — most IDEs have vi key bindings as an option, including VS Code, IntelliJ IDEA, and XCode.
The vi 2.0 release (1979) was a very large piece of software for the time, and in the 1980s it was only available to people with a commercial UNIX® license from AT&T. For this reason, multiple people created free clones of vi to run on 80s personal computers.
There are now many vi clones and derivatives to choose from, and I couldn’t find a good comprehensive list of all of them with links, so here’s mine. Dates are release dates, to the best of my ability to track them down. Some of the projects are no doubt defunct, but it can be hard to tell as they can also go years between releases.
I’m not going to list all the IDEs that have vi key bindings as an option, but other than that suggested additions are welcome.
https://github.com/n-t-roff/heirloom-ex-vi/
The original 2.11BSD vi, upgraded to support UTF-8, with fixes for POSIX compliance.
No major “quality of life” improvements, and it will fall over editing very large files.
https://nosuch.com/tjt/STevie/
A clone for the Atari ST and Amiga. If you don’t have an ST or Amiga you don’t want this. If you do have an ST or Amiga, you probably still don’t want this, as there are better options available to you. Vim (see below) descends from STevie.
https://github.com/mbert/elvis
One of the earliest vi clones, built to run on MS-DOS, Minix, and other systems of the early 1990s.
Elvis added improvements including multiple edit buffers, multiple windows, and syntax coloring. Unlike STevie, it used a file buffer for editing, so it could deal with files larger than available memory. It was used for the 80386 port of BSD Unix.
https://martinwguy.github.io/xvi/
A STevie derivative which adds multiple windows and buffers. Probably the smallest vi clone.
https://invisible-island.net/vile/
Originally derived from Microemacs, given vi style editing, but with more modes. Adds infinite undo, UTF-8 support, syntax highlighting, and more.
Probably the most used vi clone. Derived from STevie. Adds windows, multiple buffers, assorted scripting options, and UTF-8 support. Handles very large files (GB in size).
Now incorporating LLM-generated code.
Based on Elvis, a reimplementation of vi intended to be identical in core behavior to the original. Used for the 4BSD Unix release.
Adds support for additional scripting languages (Perl and Tcl). Introduced use of a database for storing file data. It’ll open files of about a GB in size but will complain about DB page sizes. Also unfortunately still doesn’t support UTF-8 text.
https://github.com/johnsonjh/OpenVi
A derivative of nvi. Extensively cleaned up, but still doesn’t support UTF-8 text. Also missing macros, scripting, syntax highlighting.
BusyBox includes a tiny incomplete (but usable) implementation of vi. You’ll encounter it in Alpine Linux and embedded systems.
https://github.com/illumos/illumos-gate/tree/master/usr/src/cmd/vi
AT&T UNIX® vi from SVR4, open-sourced as part of OpenSolaris in 2005.
https://github.com/lichray/nvi2
Adds UTF-8 support to nvi, as well as various CJK encodings.
Cleans up Vim by removing support for ancient platforms. Adds LSP support, a built-in terminal emulator, Lua scripting to replace VimScript, and many other features.
Now incorporating LLM-generated code.
https://codeberg.org/evi-editor/evi
A fork of Vim from before it began gaining LLM-generated code.
A fork of Vim from version 8.3 (pre LLM code), aiming for long term support by humans.
https://codeberg.org/landley/toybox
ToyBox, the non-GPL BusyBox clone, may be getting its own tiny vi implementation.
Also, some things which aren’t really vi, but…
https://www.gnu.org/software/emacs/manual/html_mono/viper.html
A set of vi key bindings for Emacs.
A modal editor inspired by vi, but with slightly different key bindings. Designed to be minimal, calls external programs for some features.
https://github.com/emacs-evil/evil
Another implementation of vi modal editing on top of Emacs.
https://github.com/martanne/vis
Like vi, but with structural regular expressions and other features taken from sam, the Plan 9 editor. (Sam is a graphical editor, so isn’t in this list.)
https://github.com/helix-editor/helix
Another new modal editor, inspired by Kakoune and Vim. Again, key bindings are different.