Ask HN: Is switching from VSCode to Vim worth it?
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.
41 comments
what are your goals?
'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.
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.
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.
'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.
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.
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.
Thanks for taking the time to write this out. I’ve always been into shortcuts/efficiency when using computers, but vim has made me realize how just how deep the rabbit hole goes and I find it intimidating. With that said, since learning more about vim and why people like it, I find myself getting more and more frustrated every time I instinctively reach for the mouse in vs code or really anything, which while it’s not even that slow, this mental tax leads to an unpleasant development experience. I’m now finding myself at the awkward intersection of seeing how much I leave on the table with vscode in the long term, but also not being anywhere near as productive after making the full switch to vim.
I could care less about what people think of the editor I use. The ergonomic benefit is nice, but after seeing a video[0] of someone who is clearly years ahead in vim fluency, I am so drawn to the idea of having my productivity limited by my thoughts vs how quick I can interaction with my editor.
[0] https://youtu.be/-I1b8BINyEw
I could care less about what people think of the editor I use. The ergonomic benefit is nice, but after seeing a video[0] of someone who is clearly years ahead in vim fluency, I am so drawn to the idea of having my productivity limited by my thoughts vs how quick I can interaction with my editor.
[0] https://youtu.be/-I1b8BINyEw
Watching that video, there's not much in there that you couldn't do with vscode vim plugin. Lots of it was just setting up vim plugins to replicate behavior present in vscode itself. In vscode, these features can also usually (always?) be accessed via the keyboard.
As for mouse-reaching, just flip it over (maybe put a sticky note over laptop trackpads). If you touch it, think, hey, there's probably a way to do this without the mouse. For vim usage, I would also say the same thing about arrow keys (especially in insert mode). Disable these training wheels & see your productivity skyrocket.
As for mouse-reaching, just flip it over (maybe put a sticky note over laptop trackpads). If you touch it, think, hey, there's probably a way to do this without the mouse. For vim usage, I would also say the same thing about arrow keys (especially in insert mode). Disable these training wheels & see your productivity skyrocket.
i think anytime you have to switch a tool, there's going to be a huge dent in productivity. you and i seem to have similar feelings about the mouse and the mental tax that can taint a development experience. what i will say is outside of the productivity dent, there isn't really anything that vscode can do that vim can't. embedded terminals, LSPs, 'command palettes', hell, even githubs Copilot can be achieved in vim.
in my experience the best way to can the fluency you are seeking is to delete vscode, or put it somewhere that you can't see on your machine. when you have a thing that ''''works'''' and you are trying to learn a new thing, it can be an anti-pattern to have such easy access to the thing you are trying to stop using. for example, when i switched to dvorak, i was most successful when i forced myself to only use dvorak, no qwerty, no exceptions. it slowed me down for a week or two, but necessity got me to where i needed to go. the same holds true for vim, that was the same approach i took. even if it means i'm slower for a little bit while i figure out motions, configurations, etc, it got me to where i am now, which is a place where i can do my job in vim (or in my case, evil(vim) mode in emacs) much faster than i could in any editor.
best of luck!
in my experience the best way to can the fluency you are seeking is to delete vscode, or put it somewhere that you can't see on your machine. when you have a thing that ''''works'''' and you are trying to learn a new thing, it can be an anti-pattern to have such easy access to the thing you are trying to stop using. for example, when i switched to dvorak, i was most successful when i forced myself to only use dvorak, no qwerty, no exceptions. it slowed me down for a week or two, but necessity got me to where i needed to go. the same holds true for vim, that was the same approach i took. even if it means i'm slower for a little bit while i figure out motions, configurations, etc, it got me to where i am now, which is a place where i can do my job in vim (or in my case, evil(vim) mode in emacs) much faster than i could in any editor.
best of luck!
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:
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.
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.
3. Train using the command. Do this until your fingers type it without thinking.
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.
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.
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.
[0] https://moolenaar.net/habits.html
[1] https://youtu.be/eX9m3g5J-XA
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.
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.
3. Train using the command. Do this until your fingers type it without thinking.
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.
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.
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.
[0] https://moolenaar.net/habits.html
[1] https://youtu.be/eX9m3g5J-XA
The biggest reason I have to use vi(m) is for messing with servers in production and opening large files.
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.
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).
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.
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.
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).
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.
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 not 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.
Source: Near-full time vimmer and terminal tools user. I found joy in the journey as an end in and of itself.
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 not 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.
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.
Vim shines when you need the same editing interface anywhere, on any VM, any server, any machine.
If that's not you and VSCode suits your needs, especially around navigating large projects, then I'd say stick with that.
Vim shines when you need the same editing interface anywhere, on any VM, any server, any machine.
If that's not you and VSCode suits your needs, especially around navigating large projects, then I'd say stick with that.
Good point. I’m a Fullstack js web dev and decided I should make the switch after a combination of getting fed up with unpleasant experiences on ec2 instances and creating dozens of custom vscode shortcuts that I later learned do things that basic vim does
With vscode.dev (github.dev) VS Code seems even more "everywhere" that I need it to be than ever before.
I don't know what your EC2 experiences have been like, of course, but there are ways to increase the reach of VS Code even into your EC2 instances. On the one side, are you editing a lot of dotfiles that should maybe be in a git repo and synced anyway? On the other side, maybe something like VS Code's very cool SSH remoting tools are more what you need: https://code.visualstudio.com/docs/remote/ssh
I don't know what your EC2 experiences have been like, of course, but there are ways to increase the reach of VS Code even into your EC2 instances. On the one side, are you editing a lot of dotfiles that should maybe be in a git repo and synced anyway? On the other side, maybe something like VS Code's very cool SSH remoting tools are more what you need: https://code.visualstudio.com/docs/remote/ssh
Seems like you should stick with it then.
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.
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.
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.
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.
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:
- 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)
- Invest in your config
- Work on your typing (and address any discomfort that arises--super important)
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.
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:
- 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)
- Invest in your config
- 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.
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.
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.
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.
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.
This is the right perspective. Not “what can it do for me today”, but rather “what will it do for me over my entire career”.
The future of vim is more vim. I have been using vi and its descendants for over 30 years, and the core behavior is the same as it has always been. It has done all I ever needed, and it works everywhere and over slow connections.
The future of VSCode is at the mercy of Microsoft, and that absolutely will change under you without warning. They control the value of the skills that you learn. Why would you take that risk?
The future of vim is more vim. I have been using vi and its descendants for over 30 years, and the core behavior is the same as it has always been. It has done all I ever needed, and it works everywhere and over slow connections.
The future of VSCode is at the mercy of Microsoft, and that absolutely will change under you without warning. They control the value of the skills that you learn. Why would you take that risk?
+1 And a future job might disallow you from using VSCode for some arcane reason. Why would that happen? well workplaces do weird things sometime.. Whereas they can't really stop you from using vim. :)
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.
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.
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.
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!
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.
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'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!
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.
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.
> it does exactly what i want it to
It's difficult to describe how incredibly valuable this is. Pretty much my entire software stack[1] is scriptable, which means I can sand every corner as soon as it becomes an issue. The impact to my productivity from reduced mental load is honestly incalculable, and I'm pretty sure I couldn't concentrate nearly as deeply on complex things without it.
[1] I've started scripting my browser to behave better too, but that's the main holdout at this pt
It's difficult to describe how incredibly valuable this is. Pretty much my entire software stack[1] is scriptable, which means I can sand every corner as soon as it becomes an issue. The impact to my productivity from reduced mental load is honestly incalculable, and I'm pretty sure I couldn't concentrate nearly as deeply on complex things without it.
[1] I've started scripting my browser to behave better too, but that's the main holdout at this pt
> 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.
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.
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!).
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).
I haven't really touched my dotfiles in a year or two outside a few custom keybinds for new workflows I find myself repeating.
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.
[0] https://github.com/neoclide/coc.nvim
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).
I haven't really touched my dotfiles in a year or two outside a few custom keybinds for new workflows I find myself repeating.
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.
[0] https://github.com/neoclide/coc.nvim
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.
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 had 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.
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.
Also, the bonus is that Vim is much 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 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 had 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.
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.
Also, the bonus is that Vim is much 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.
> jumping through UIs and pointing and clicking.
That's strange, most code editors have advanced keyboard shortcuts for almost everything you can do with pointing and clicking. You just have to learn the combos.
That's strange, most code editors have advanced keyboard shortcuts for almost everything you can do with pointing and clicking. You just have to learn the combos.
[deleted]
Absolutely. I wasn't trying to imply that they had to be used that way. But they do tend to be designed point-and-click-first in many aspects. Which is great for people just getting into programming and text editing in general. But Vim's keybindings are absolutely unparalleled. Even Emacs default keybindings can't compete, and I'm an Emacs fan.
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.
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.
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.
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.
For terminals i prefer micro, it is golang written code editor.
Recently dev.github.com provides online code editor that works with ci/cd piplines.
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.
For terminals i prefer micro, it is golang written code editor.
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.
Isn't it much cheaper just to get a beefy workstation with fast SSD and enough RAM so everything's in RAM. Maybe there's occasional waits but it's very short, most coding becomes super fast also with e.g. Visual Studio.
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'd be inclined to agree here, I don't see any reason code should ever be touched outside of a repeatable process, and I'm not sure how you version control stuff developed on a server unless you have ssh keys on it or do lots of manual copying.
But maybe they are doing something super high performance and need fast edit test cycles they can't get on their laptop, although I'm not exactly sure what kind of task needs that.
But maybe they are doing something super high performance and need fast edit test cycles they can't get on their laptop, although I'm not exactly sure what kind of task needs that.
I agree with not editing code on the server, however vim is very useful for editing Dockerfiles quickly. ;)
Why not use the VSCode vim extension best of both worlds :)
You didn't read the post.
> I’m finding myself doubting the amount of time I’m dedicating to configuring/practicing vim
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.
> but now that I’m trying to navigate medium/large projects,
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:
- rip-grep to search for files with text / file names
- Searching through currently currently opened buffers
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).
> the vim endgame looks like
It never _really_ ends. Some VIM features that I miss when I use another editor are:
- 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)
- 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.
- Global commands and macros. VSCode vim supports them, but I've noticed that they can run pretty slowly.
- The buffer, tab, window, model (probably the biggest one I miss when I start using VSCode)
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.
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.
[1] https://github.com/Shougo/denite.nvim (many people use Telescope: https://github.com/nvim-telescope/telescope.nvim) [2] https://www.amazon.com/Practical-Vim-Thought-Pragmatic-Progr...
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.
> but now that I’m trying to navigate medium/large projects,
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:
- rip-grep to search for files with text / file names
- Searching through currently currently opened buffers
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).
> the vim endgame looks like
It never _really_ ends. Some VIM features that I miss when I use another editor are:
- 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)
- 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.
- Global commands and macros. VSCode vim supports them, but I've noticed that they can run pretty slowly.
- The buffer, tab, window, model (probably the biggest one I miss when I start using VSCode)
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.
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.
[1] https://github.com/Shougo/denite.nvim (many people use Telescope: https://github.com/nvim-telescope/telescope.nvim) [2] https://www.amazon.com/Practical-Vim-Thought-Pragmatic-Progr...
> 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).
Yes, VSCode definitely has its own model similar to Vim's buffer/tab/window but that is somewhat unique to VSCode. There are some deep keyboard shortcuts that are similar, but quite different to Vim's, and I recall the VSCode Vim plugin tries its best to split the difference, somewhat.
Something I find very helpful with VSCode tab management in complex scenarios is the "Open Editors" pane. By default it is at the top of the Explorer panel. I think it defaults to minimized in fresh installs, though, but deep in the past it was the "only" tab management interface and a little bit more central to early VS Code workflows so some of us learned to rely on it early and others coming into VS Code fresh don't notice it at all. It's still one of the easiest places to do more complex tab and split management when the vertical tab bars are too cramped to be as useful as a horizontal list of opened tabs/splits.
Yes, VSCode definitely has its own model similar to Vim's buffer/tab/window but that is somewhat unique to VSCode. There are some deep keyboard shortcuts that are similar, but quite different to Vim's, and I recall the VSCode Vim plugin tries its best to split the difference, somewhat.
Something I find very helpful with VSCode tab management in complex scenarios is the "Open Editors" pane. By default it is at the top of the Explorer panel. I think it defaults to minimized in fresh installs, though, but deep in the past it was the "only" tab management interface and a little bit more central to early VS Code workflows so some of us learned to rely on it early and others coming into VS Code fresh don't notice it at all. It's still one of the easiest places to do more complex tab and split management when the vertical tab bars are too cramped to be as useful as a horizontal list of opened tabs/splits.
Awesome! This will make my liveshare sessions so much more bearable. I also found a plugin[1] that enforces single editors per tabs.
[1]: https://marketplace.visualstudio.com/items?itemName=martybeg...
[1]: https://marketplace.visualstudio.com/items?itemName=martybeg...