Live data from Hacker News

The vi family

lpar.ath0.com

21–30 of 198 posts

Re: The vi family

#21

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…

Same. I barely edit default configs. I also mostly use emulators provided by whatever ide I use.

Re: The vi family

#22
post #4

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.

Re: The vi family

#23

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.

Re: The vi family

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

Re: The vi family

#25

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…

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.

Re: The vi family

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

Re: The vi family

#27

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.

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

Re: The vi family

#28
post #26

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.

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"

Re: The vi family

#29
post #9

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.

Re: The vi family

#30

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?

Post reply on HN