The vi family
lpar.ath0.com
The vi family
1–10 of 198 posts
Re: The vi family
#2cool 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)
Re: The vi family
#3I'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.
Re: The vi family
#4The 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.
Re: The vi family
#5Sam 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.
Re: The vi family
#6Interesting 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.
Re: The vi family
#7The 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.
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.
Re: The vi family
#8The 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.
Seems like an interesting fact for those who don't follow the development of vim/neovim.
Re: The vi family
#9One 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.
Re: The vi family
#10I 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.