I got started with vi on Sparc 5s (and less!) in 1996 or so, and over the decades have accumulated a 200-line .vimrc file. I do not use it for every purpose, using VS Code for most of my coding, but I do use /vim?/ for a few special purposes.
Sorting - For things like the entries in CSS, I like them to be sorted, so that I don't have to hunt as hard to see if font-size is set. I'm sure it's available in Code, and I think I have it set for one of the systems I use, but it isn't built-in so it isn't consistent. I go into visual mode and get it done.
PerlTidy - Here, I'm very in the minority, but my code base and experience is largely in Perl. 1) the Perltidy VSCode extension isn't happy on on non-Linux systems. 2) the Perltidy VSCode wants to go with system Perl, not my self-compiled current Perl, and thus doesn't always work right.
Remote - The machine I'm editing on is not always the machine under my fingers, and the user I'm editing as is not always me. I can often mount those file systems and edit with VSCode, but it is often quicker and easier to just ssh in, vi file.conf and get out.
Honestly, I could easily get my .vimrc under 100 lines -- maybe less -- without losing any of the functionality I need. A lot of it is taken from people like Damian Conway's vim settings. See Damian Conway show off vim at OSCON.
My problem is the same as the users who don't use it often: it would take time to determine which things I use and need and which things I do not, and it is easier to just go forward with things as they are. I was strongly in a sink-or-swim environment when I learned vi, surrounded by lots of people with similar knowledge but knowing just that keystroke that I needed to move forward. But the space I work in is somewhat anachronistic in the coming cloud world.
I would gladly wear a t-shirt with the "Oh Ned! You Are a vi man after all!" image on it, but honestly, if I could trade my not-ready-for-git-or-other-revision-control current codebase for something where I wasn't developing in production (It existed like this before I got here) and all it would cost me is my vim knowledge, I would trade it in an instant.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I got started with vi on Sparc 5s (and less!) in 1996 or so, and over the decades have accumulated a 200-line .vimrc file. I do not use it for every purpose, using VS Code for most of my coding, but I do use /vim?/ for a few special purposes.
font-sizeis set. I'm sure it's available in Code, and I think I have it set for one of the systems I use, but it isn't built-in so it isn't consistent. I go into visual mode and get it done.vi file.confand get out.Honestly, I could easily get my .vimrc under 100 lines -- maybe less -- without losing any of the functionality I need. A lot of it is taken from people like Damian Conway's vim settings. See Damian Conway show off vim at OSCON.
My problem is the same as the users who don't use it often: it would take time to determine which things I use and need and which things I do not, and it is easier to just go forward with things as they are. I was strongly in a sink-or-swim environment when I learned vi, surrounded by lots of people with similar knowledge but knowing just that keystroke that I needed to move forward. But the space I work in is somewhat anachronistic in the coming cloud world.
I would gladly wear a t-shirt with the "Oh Ned! You Are a vi man after all!" image on it, but honestly, if I could trade my not-ready-for-git-or-other-revision-control current codebase for something where I wasn't developing in production (It existed like this before I got here) and all it would cost me is my vim knowledge, I would trade it in an instant.