The comments about LLM contributed code seems like a specific axe to grind that otherwise detracts from a nice history lesson.
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 existence of vim classic would be hard to explain without reference to LLMs.
That advice was not entirely accurate (sometimes vi is in /usr/bin/vi, for example), and the merging of /bin with /usr/bin has made it kind of a moot point. (EDIT to add: Though the fact that busybox includes a basic vi implementation has kind of un-mooted the point, actually). But I first started learning vi because I figured I would need it professionally, and when the modal-editing workflow "clicked" for me, I figured out that I had just learned the editor I would want to stick with for years.
And although vim replaced vi and nvim replaced vim in my finger-macros, that has remained true to this day.
You don't need emacs on a server. TRAMP is built-in and can open remote files in a local instance over SSH, SMB, FTP, ADB, or docker/podman.
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.
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.
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.
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)
The moment VSCode and Obsidian support improves, I am switching immediately.
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?
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.
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?
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 don't have a GUI available, I use micro, nano, joe.
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.
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.
But I'd still rather use it than just about any other text editor, just for the simplicity of that muscle memory alone. I have way more stuff to keep in my head than I have room for and I can't afford to expend more than about 0.0001% of context on a text editor.
I can't say I agree. To me this is equivalent 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.
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 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.
Right now I think my .vimrc is two lines. That's also sort of silly as I benefit very little from all the things Vim can do.
What really seals the AstroNVim deal for me though is the community packs. People have very thoughtfully integrated support for a huge range of nvim plugins. And it's super easy to install, and they often fit in nicely to the existing out of box experience of nvim. https://github.com/AstroNvim/astrocommunity