I used the vim extension for about a month and am now making what is a very jarring/uncomfortable switch to exclusively using vim (neovim technically). I thought I had comfortably got the movements inside a file down, but now that I’m trying to navigate medium/large projects, I see how much more I need to learn before I can “break even” and get back to my speed/comfort in vscode. I’m finding myself doubting the amount of time I’m dedicating to configuring/practicing vim and am seeking insights as to whether or not this is a worthwhile way to spend my time as I don’t really know what the vim endgame looks like, while vscode was definitely good enough.
what are your goals?<p>'if it ain't broke, don't fix it' - if you find that you are able to work comfortably with vscode with the vim extension, and it is meeting all your needs, then honestly that might be what works best for you. However, if you find that you are hitting walls with extensibility or flexibility, _then_ it's time to maybe consider a switch. in my experience of using vim for like a decade now, a successful vim user is often someone who is _obsessed_ with squeezing usability and optimization out of their tools/toolchain. I have seen many an engineer try and force Vim on themselves because of the perception they think others will have of them as a somehow more skilled or 'in the know' engineer. And while i'm not suggesting thats what you are doing, it's definitely a pattern i've seen more and more.<p>Moral of the story, figure out what you need out of your tools and adapt your toolchain to those needs. and if navigation is your main issue, you should look into easy-motion and Tags, those will help a lot.<p>And for what it's worth. After a lot of tinkering and thinking about my own goals, i ultimately settled on Doom Emacs, and that's been my preferred editor for a few years now. Many vimmers have found that to be the ideal 'endgame', anecdotally, at least.
I’d encourage you to apply the three-step process presented in [0] (there’s also a video [1]), which is actually not specific to Vim:<p>1. While you are working with software tools, keep an eye out for actions you repeat and/or spend quite a bit of time on.<p>2. Find out if there is a command (or macro facility etc.) that will do this action quicker. Read the documentation, ask a friend, or look at how others do this.<p>3. Train using the command. Do this until your fingers type it without thinking.<p>This means that you can learn new commands only as the need comes up by observing what you do. Which commands you will want to learn thus depend on the operations you are frequently doing and/or that cost you a lot of time.<p>As I said, that strategy is applicable in general. Tools however differ in how well they support it, e.g. in terms of available commands and facilities.<p>You could start applying that strategy in VSCode (which I’m not familiar with, by the way). If it works well enough, great. If you find it limiting, switch to Vim, Emacs, or some other IDE that serves your needs better.<p>[0] <a href="https://moolenaar.net/habits.html" rel="nofollow">https://moolenaar.net/habits.html</a><p>[1] <a href="https://youtu.be/eX9m3g5J-XA" rel="nofollow">https://youtu.be/eX9m3g5J-XA</a>
The biggest reason I have to use vi(m) is for messing with servers in production and opening large files.<p>Otherwise I use non-GUI Emacs. Before that I used vim. My biggest motivation for using terminal-based text editors is that they're faster than GUI editors and easier to switch between CLI tools and the editor. Also, I prefer to do my development within remote servers (that are much beefier than my laptops/desktops). So I just SSH in and do the work.<p>I'm ok with giving up the builtin niceties like jump-to-definition and syntax-aware find-replace. (I could get this working in emacs but it never works in every language or I forget how to set it up when switching environments or something so I end up not using this kind of feature).<p>If you have a motivation then you'll figure out how to make it work eventually. If you don't have these kinds of motivations then I'm not sure why you'd pick terminal editor.
If you're already comfortable with an editor (such as VSCode), don't worry about learning another one unless you inherently enjoy the journey (which it seems that you don't). Instead, invest some time learning features, keyboard shortcuts, and configurations of your current editor.<p>Also, if you use languages for which an IDE provides significant value - continue using whatever IDE you are using (... if you don't enjoy the vim/shell lifestyle). Vim is <i>not</i> an IDE, though it can eventually be configured to act like one. If you mainly program in C for example, an IDE provides minimal value beyond what a lightly configured Vim would provide.<p>Source: Near-full time vimmer and terminal tools user. I found joy in the journey as an end in and of itself.
You don't mention anything about your needs.<p>Vim shines when you need the same editing interface <i>anywhere</i>, on any VM, any server, any machine.<p>If that's not you and VSCode suits your needs, especially around navigating large projects, then I'd say stick with that.
I did the other way around! I have ~10 years of experience in VIM and for the last 3y or so have been only in vscode. I use vim for the occasional config file but vscode is great and I don't miss using vim on my day to day at all.
Its definitely worth learning vim, which you can do plenty well with the VScode vim plugin. Its probably not worth moving unless you have some real issues with your workflow or you're bored and want to learn something new.<p>Im trying to move completely to Lunarvim, a vim config with a lot of neat tools built in, but only because I fell in love with the keybinds and I don't want to spend the time configuring vscode or pycharm to do the same. That said, I still swap to pycharm or vscode for the debugger.
Re: configuring, I've used (Neo)Vim for +15 years, and I configure very rarely. I started out with a 5 line .vimrc which is now a 150 line init.vim, about half of which is plugin installation and a few options for ALE.<p>That said when I do configure, I'm dedicated to it. The goal is to set it and forget it for literally years in order to build up muscle memory. So it's worth playing around and finding what works.<p>It did take me a few months of consistent use to get better in Vim than other editors. I think that's faster than most people? I'm a pretty good typist so I think that probably makes a big difference. All of which is to say:<p>- Definitely stick with it (maybe try to think of it as "cool" rather than a slog, maybe investigate cool plugins or color schemes to help reinforce that)<p>- Invest in your config<p>- Work on your typing (and address any discomfort that arises--super important)
I probably started using vi in 1989. What I learned then I still use all the time.<p>On the other hand, I primarily program Android at work, and in 2009 Android recommended I use the Eclipse IDE, so I learned how to use that. Then starting around 2013, Android said they were shifting from Eclipse to Android Studio, so then I learned that. Android Studio has odd keyboard shortcuts - on a Linux (or Windows) box you jump to a line by hitting Control-G - on a Mac you hit Command-L.<p>The vi on my Mac and Linux seem fairly similar in terms of keyboard shortcuts and what I use now on both of them is what I used in 2013 and what I used in 1989 as well, and I have used it for a host of things. Whereas even in the specialty of Android programming, the recommended IDE switched some years back, and it has differences on different platforms.
I used the vim extension to learn the basics. From my perspective vscode is an ide and it does some cool things. However, vim/neovim is more of a worldview. I'm much faster when I don't touch the mouse. I don't have to slow down how I think. It's upsetting to have to stop typing, moving, etc..and click a button or tab. So I'm more inclined to go faster.<p>However, it's not a skill developed overnight. It takes time to invest in the tool, but for me the payoff has been significantly increased productivity. I won't ever stop learning new vim skills though. It's both wide and deep. Vim just makes sense to me now, but it took a while to really get it.
I know the feeling. I flirted with vim and later neovim for a few years on-off, but kept going back to vscode because i wasn't as fast in vim. I did stick with the vim keybinds in VSC though and, over time, each foray into vim lasted longer until the time came where I finally stuck with it.<p>I'd recommend using one of the pre-baked configs (LunarVim, Astro, NvChad) to get a taste for what a batteries included vim build feels like. If you're like me you'll use it for a while, tinker with the configs etc. until you reach a point where something annoys you and you'll build a config from scratch. Seeing a fully completed config and playing with it has been really useful!<p>Was it worth it? Hard to say, but I'm now at the point where all the vim stuff is muscle memory, and I'm now getting comfortable with macros etc. You reach a point where rather than thinking of editing code as an interaction with an interface you start to think of it as just editing code. It's a difficult concept to get across but the fact i rarely interact with a mouse has definitely led me to become less easily distracted while coding.<p>My custom config feels like what I imagine having a model railway would feel like. It takes a bit of maintenance and tinkering, but it does exactly what i want it to and I get a sense of satisfaction from keeping it up to date.
> I used the vim extension for about a month (..) I thought I had comfortably got the movements inside a file down, but now that I’m trying to navigate medium/large projects, I see how much more I need to learn before I can “break even” and get back to my speed/comfort in vscode.<p>Keep in mind that even though vscode's vim extension is not bad, it has significant differences to the point it degrades the user experience and gets in the way.
I use coc-nvim [0] for my development environment and love it. The VS Code plugin is a great start to get used to vim movement, but eventually you'll run into some limitations that end up being slightly annoying (albeit this was a few years back and those might not exist anymore!).<p>Most of my development is in TypeScript, which has a pretty good language server, so I don't feel like I'm really missing out on any of the "IDE" features that I get in VSCode. I am not a "pure vim" zealot, so I have a decent amount of plugins to bring my environment closer to an "IDE" than "just vim" (eg. NerdTree, fugitive, surround, sneak).<p>I haven't really touched my dotfiles in a year or two outside a few custom keybinds for new workflows I find myself repeating.<p>Getting good at whatever editor you choose to use for your daily development is a good investment. If you're going to choose one, vim is probably a decent choice for how long it's stayed around.<p>[0] <a href="https://github.com/neoclide/coc.nvim" rel="nofollow">https://github.com/neoclide/coc.nvim</a>
4-5 years ago I was all about the editors with pretty UIs (VS Code, Brackets, Atom, JetBrains IDEs, etc). I thought Vim was dumb and outdated. Boy was I wrong.<p>I eventually decided to try out Emacs, and settled on Spacemacs, which comes with Evil mode pre-installed (a Vim emulation layer on top of Emacs), so I basically <i>had</i> to learn some Vim bindings. Now I'm on Doom, which uses them even more heavily. And boy do I regret not having learned this stuff sooner. So much faster and simpler than jumping through UIs and pointing and clicking.<p>If you haven't heard of it already, Vim/NeoVim come with a tutorial built-in, called Vimtutor. Definitely run through that for a quick interactive primer on how to effectively use the basics.<p>Also, the bonus is that Vim is <i>much</i> more lightweight and snappy than VS Code, even on much older and cheaper machines. So you'll feel at home anywhere you run it. The same cannot be said for VS Code.
I personally much prefer vim due to its infinite portability (I can use the same editor pretty much anywhere), but it came with a big up-front learning curve that I used when I was ramping up on a new codebase anyways.<p>If you like VSCode and feel productive in it, you should stick with it. If you're in a situation where you're able to go slower and ramp up with vim, I think that would be a good time to try it out. The end-game is that your vim-config is truly portable, and no matter where you go, you'll be able to easily duplicate your work environment. Also, once you master the motions, you'll be much faster navigating bigger code-bases and can easily work on a server if need be.
I don't know. My take is, I learned Vim once, and I'll stick to it no matter what kind of text editing I do. Learning Vim is like learning to ride a bicycle. Once I've learned it I can ride a normal bicycle, a modified bicycle, a sports bike, one with a child seat in the back, doesn't matter. I can ride it in the US, in Europe or in China, it's portable and I only have to learn it once. I don't want to learn a mode of transportation that only works in France. I don't want my way of getting around to depend on a cloud service which may disappear, or a company which may stop supporting at some point in the future.
Yes vim will help with small tasks even for beginner, still require advanced study how to use to get vim power. After hype impression of vs code I have found it only extend my workspace ability on the half. Usually I need code something from thin pc where vs code works slow or even I need to connect to cloud terminal instance to programming here on the place.<p>Form thin pc I preffer to use Zed code editor from google apps, this small js program works offline and do not freeze for large code base.<p>For terminals i prefer micro, it is golang written code editor.<p>Recently dev.github.com provides online code editor that works with ci/cd piplines.
The biggest advantage of vim, besides the language for editing text in normal mode, is that you are really fast and it just feels like you never have to wait for your computer anymore.
I did what you're considering. I was tired of VSCode because of Electron and wanted something lightweight. Neovim suited me. But you should know that if you use the lsp, most of the language servers are written in Node. You should learn to configure them for performance, especially pyright, if you use Python. Look up Kickstart.nvim and try to follow that. And checkout telescope. It's amazing.
emacs and vim are competitive advantages over those who don't use them, once one is over the learning curve. The break even point is sooner if you spend less time changing the configuration.
Stick with VSCode. “Editing code on the server”? This isn’t 2010. We use docker and continuous deployment, and if someone is trying to edit production code in the server something is deeply wrong.
> I’m finding myself doubting the amount of time I’m dedicating to configuring/practicing vim<p>If it's not fun, then it's probably not worth it. It really depends on what VIM can do to improve your current workflow. So, you may need to drop the VSCode mindset while you start using VIM.<p>> but now that I’m trying to navigate medium/large projects,<p>I actually have trouble navigating large projects in VSCode. The buffer, tab, window model that Vim uses makes more sense to me (but it's unique to VIM afaik, so it may be jarring at first). Combine that with a fuzzy finder[1] and it allows:<p>- rip-grep to search for files with text / file names<p>- Searching through currently currently opened buffers<p>Whenever I have to use VSCode (mainly for the live share feature, I find myself pretty lost with VSCode's tab based interface (I usually end up with like 20 tabs cluttering my workspace, and tabs are local to a split, which is jarring for me).<p>> the vim endgame looks like<p>It never _really_ ends. Some VIM features that I miss when I use another editor are:<p>- Really nice integration with terminal commands. One thing that I do very often is copy the name of the current file: `!echo % | xclip -sel clip` so I can use the filename as an argument in a terminal split (running tests for example)<p>- Filters (`:help !`) so I can pass parts of a file in to a program that accepts standard input. Example: `'<,'>!jq` to prettify bits of JSON.<p>- Global commands and macros. VSCode vim supports them, but I've noticed that they can run pretty slowly.<p>- The buffer, tab, window, model (probably the biggest one I miss when I start using VSCode)<p>For LSP support, I've tried to migrate to neovim's native LSP tools, but I still find COC to be a lot more intuitive. You should feel right at home with it since a lot of the plugins are similar to their VSCode counterpart.<p>If you'd like a really general and guided tour of VIM, I'd recommend picking up Practial Vim[2] It really helped me understand the workflow a bit more. Approaching VIM with the mindset of another editor wont give you all the benefits of using VIM. Though, if the workflow doesn't click, then that's not a big deal. You can always go back to VSCode.<p>[1] <a href="https://github.com/Shougo/denite.nvim" rel="nofollow">https://github.com/Shougo/denite.nvim</a> (many people use Telescope: <a href="https://github.com/nvim-telescope/telescope.nvim" rel="nofollow">https://github.com/nvim-telescope/telescope.nvim</a>)
[2] <a href="https://www.amazon.com/Practical-Vim-Thought-Pragmatic-Programmers/dp/1934356980" rel="nofollow">https://www.amazon.com/Practical-Vim-Thought-Pragmatic-Progr...</a>