I've used vi (and later vim and neovim) since the 1980s, and really enjoyed reading this site. I had no idea there were so many vi-able alternatives!
The vi family
161–170 of 198 posts
Re: The vi family
#162I’ve been a long time vim user, and I honestly never really bought into the efficiency claims. That gets repeated over and over, but If you’re a slow typer then no editor can really make much of a difference, and development in reality is a lot of reading code and thinking about code when it comes down to it. I’ve never used it because I thought it would make me some lightning fast super developer. I’ve always used i…
> never really bought into the efficiency claims
Macros, dude.
It's a bit annoying to become disciplined in text structure/regularity to have macros work flawlessly, but it's a bliss afterwards.
And then... recursive macros.
(I know Emacs has better macros but vim macros are way easier and fun for everyday use).
Re: The vi family
#163> "once you learn it, you can be ruthlessly efficient with your editing"
This is no joke. I use it to "massage" data in all sorts of files (.json, .xml, .csv, .txt, etc.), with thousands to millions of lines, in no time at all.
Re: The vi family
#164I’ve been a long time vim user, and I honestly never really bought into the efficiency claims. That gets repeated over and over, but If you’re a slow typer then no editor can really make much of a difference, and development in reality is a lot of reading code and thinking about code when it comes down to it. I’ve never used it because I thought it would make me some lightning fast super developer. I’ve always used i…
I don't think it makes me more efficient at writing code. Its because the act of coding is like 80% reading existing code, only rarely adding new code. You spend far more time moving around and exploring the code, and in vim the keys to do that are single keypresses, or sequences like `]p`. Every other non-modal editor requires you to hit chords like Ctrl-Shift-F to move around, because the "easy" keys are all taken up by "add this character to the buffer", 100% of the time.
Re: The vi family
#165small fun fact: "vi" means "we" in Swedish "The we family" :)
In Portuguese "vi" means "saw" (past of see) and vim means "came", the last one being source of many inside jokes in one of my first jobs
Re: The vi family
#166Interesting 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.
The LLM usage are disclosed only for the projects where this information is relevant.
By the way there are a lot of farmers that doesn't need the power of tractors to make farming their livehood. Makes sense when you realize that not everything needs to be super fast and efficient, sometimes cheap, slow and constant is enough.
Re: The vi family
#167I’ve been a long time vim user, and I honestly never really bought into the efficiency claims. That gets repeated over and over, but If you’re a slow typer then no editor can really make much of a difference, and development in reality is a lot of reading code and thinking about code when it comes down to it. I’ve never used it because I thought it would make me some lightning fast super developer. I’ve always used i…
I like vi/vim, but it gets me all too frequently because I'm not precise enough of a typist. I'm busy typing away and I hit the wrong modifier key or hitting caps lock and I end up pulling things up or making changes that I never intended to make. Worse, in the split second after it happens and my muscle memory tries to correct it my immediate intuition of what mode I was in is wrong or which modifier key I'm pressing or caps lock is on and I only make the situation worse. Any improvements in performance because of the quick key interface are long gone.
Re: The vi family
#168The 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.
If you were to sweep it under the rug, then it wouldn't be a history lesson, now would it?
Re: The vi family
#169I 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...
> Being able to choose is a good thing. Use what works for you.
If you look at many of the ‘user stories’ in this thread (and others), you see a lot of people using vi/vim not because they decided to try it, but because they had no real choice. Very often it’s the only usable option on a Unix-like machine.
And yet, you don’t see many people bemoaning the choice. Despite being forced to use it, once people are over the fabled learning curve they tend to like it.
Re: The vi family
#170Earlier quoted context omitted.
I similarly thank the stars I ran into AstroNVim, which itself is based on LazyVim. Out of the box it has a lot of well integrated/just works pieces. It has a bunch of leader key things setup, and, crucially, a little visual navigator at the bottom of the screen. Going from powerful but invisible to having something I could see was such a help! I'd compare it to moving from tmux to zellij but I'm a pretty happy tmux…
Hey, AstroNvim core maintainer here! Just wanted to clear something up. AstroNvim is in no way based on LazyVim, AstroNvim existed for almost 2 years before LazyVim existed...
Apologies & thanks. AstroNvim used lazy.nvim, which is a (ragingly popular) plugin loader, not LazyVim, a setup for nvim also based on lazy.nvim.
Ref on lazy.vim: https://docs.astronvim.com/configuration/customizing_plugins...