- Visual Studio Code provides a rich and easy keyboard shortcuts editing experience using Keyboard Shortcuts editor. It lists all available commands with and without keybindings and you can easily change / remove / reset their keybindings using the available actions.
- Where I guide you how to setup Vim in Visual Studio Code.For more info, check out this complete guide to Vim in VSCode: https://www.barbarianmeetscoding.com/.
- Ever since I switched to Visual Studio Code I missed the speed of editing with Vim, but I also felt some FUD about installing an extension. This course was exactly what I needed — through a series of concise and fun exercises I refreshed my memory of Vim, learned how to use the extension, and now I'm enjoying best of both worlds.
- VSCodeVim Vim emulation for Visual Studio Code VSCodeVim is a Vim emulator for Visual Studio Code. 🚚 For a full list of supported Vim features, please refer to our roadmap.
Description In this video, I go over why you should use Vim commands in VSCode and help you get started with the Vim extension. Socials Twit.
I started using Vim as my main editor around six months ago and I can say it hasbeen a worthwhile experience because it has pushed me to think in a moreefficient way when it comes to editing text.
This article explains my rationale for switching to Vim so, hopefully, it helpsyou make a decision on whether investing in learning Vim is justifiable for youtoo.
My history with text editors
I have tried a number of text editors since I first learnt to code just overthree years ago and I’ve had good experiences with each one for the most part.
Vim Visual Studio Code
I want to write a bit about those experiences so you can see where I’m comingfrom and understand how I came to using Vim eventually.
Sublime Text
The first editor I used was Sublime Text 3. Ichose it because it seemed to be really popular at the time amongst webdevelopers and most tutorials recommended it as a beginner friendly option.
At this point, I was only just learning to code so I only made use of its mostbasic features, although I did learn how to install plugins for addedfunctionality. Emmet was one of my favourites as it helpedme write HTML faster and that was just awesome.
I used Sublime for well over a year and even completed the Front-End certificateon freeCodeCamp doing all my projects within it. To be honest, I didn’t have anyreal problems with Sublime save for the popup that shows up every now and thenencouraging me to purchase the full version of the product.
To be sure, the free version is unrestricted in its feature set, but you justhave to deal with that popup and it can be annoying sometimes. As I didn’t have80 dollars to spend on a text editor, I began to look for alternatives.
First stint with Vim
Around this period, I decided to give Vim a go for the first time since it was always part of the conversation when you look at text editors for programmers and was favoured by many.
Vim was definitely more difficult to start with and although I was able to learn the basics, I just didn’t see why everything had to be so complicated.
I wasn’t productive at all so I gave up on Vim after messing with it for a while and decided to take a look at Atom instead which was closer to Sublime in terms of interface and workflow.
Atom
Switching from Sublime to Atom wasn’t difficult because Atom is largely inspiredby Sublime so they had a lot in common which made it really easy for me to startusing it.
All the plugins I used or an equivalent were available on Atom so I was prettymuch good to go from the start. As a result, I was able to get my work donewithout much fuss.
However, being built on Electron, Atom was having a huge impact on my RAM andCPU. As I had only 4GB of RAM at the time, this was significant to me andnecessitated an upgrade in that department which I effected by installing anadditional 4GB on my computer.
With Atom, performance was not as good as Sublime from the start. I was notsurprised by this since basically all other Electron apps I had tried had moreor less the same issues. Startup time on my PC was slow, but once it loaded up,it wasn’t too bad.
Overtime, I became frustrated at the lack of improvement in this area despitereceiving regular updates. So I sought a change all over again.
Visual Studio Code
Around this time, Visual Studio Code wasgenerating a lot of discussion in programming forums and had a lot of good presson various blogs. Since it was also built on Electron, I wasn’t expecting toomuch difference from Atom in terms of performance, but I gave it a whirl anyway.
I wasn’t too impressed at first; it didn’t seem to offer anything that I wasn’talready getting from Atom and performance wasn’t significantly better. So Iuninstalled it and stuck with Atom.
However, with each monthly release, there would be some hype, and I woulddownload it again and try it out. It always seemed to get better while Atom, incontrast, was stuck in a rot especially on the performance side.
Eventually, VS Code became clearly superior in feature-set and performance so Iswitched to it full-time. At this point, I deleted Atom from my Computer and VSCode reigned supreme.
Switching to VS Code from Atom was not as seamless as the switch from Sublime toAtom. This was partly because the interface was a little different and it tookme some time to adjust.
The default key bindings were also so much different from what I was used tocoming from Atom. This issue was easily solved by installing an extension thatremapped the key bindings to Atom’s so that eased my transition a bit.
VS Code is probably the best text editor for developers who write a lot ofJavaScript and TypeScript due to its comprehensive out-of-the-box support forboth languages. However, other languages are also well supported. It was reallyeasy to work with Rust for example, which Idabbled in sometime last year, with the help of some plugins.
In the months in which I used VS Code, I didn’t have much to complain about.Although performance wasn’t as good as Sublime, it was much better than Atom andcontinued to improve.
Despite this, I still had an eye on learning and using Vim. Any time I readabout text editors in a discussion forum like Reddit or Hacker News, someone isbound to sing the praises of Vim and mention how much it can improve personalproductivity.
When one of my friends switched toVim and soon after was singing thesame song, that did it for me. I just had to get what was so good about Vim.
Trying Vim for the second time
Since I didn’t have much going at the time, haven just released StellarPhotos, I decided to switch to Vim cold turkeymeaning I didn’t retain any other text editor on my computer during thistransition process in a bid to force myself to use Vim exclusively.
It certainly wasn’t as difficult as when I tried it the first time. I usedvimtutor to remind myself of the basic commands and just went from there.
Vim is bare bones and doesn’t come with all the features I had taken for grantedin other text editors, but in most cases, I could add the functionality I neededusing a plugin.
That said, this became problematic to some extent as it led me to install morethan what I actually needed and my .vimrc file was populated with a lot ofstuff that I didn’t understand.
So I took a step back and stopped trying to make Vim work like the other texteditors I had used and instead, learn the features it has that makes it sounique and special. It quickly dawned on me that Vim can actually do a lot onits own without plugins.
Where necessary, I could still add plugins but, by not using them to scratch myevery itch, I was forced to learn the Vim way of doing things which was, in mostcases, better than what I was used to.
Working with just the keyboard has been a real eye-opener to just how fast onecan be without touching the mouse. Everything can be achieved with just a fewstrokes, and due to Vim’s modal nature, each key combination has a differentmeaning in each mode. That may sound complicated on first thought, but it’sactually really intuitive once you get used to it.
I have adopted the mindset of preferring to just use the keyboard in other areasas well like using jumpapp for switchingbetween applications and using Saka Keyfor navigating quickly in my browser.
Update: I now use Surfingkeysinstead of Saka Key and Run or raisefor GNOME on Wayland.
One of the things I love about Vim is that each change can be repeated manytimes using the dot command or macros which does save me a lot of time whenediting code. It may just be seconds saved here and there but it adds up.
The one thing I’ve found significantly worse in Vim compared to other editors isthe colour and font quality, but I suspect this has more to do with my terminalemulator (I use Terminator).
I know its possible to make Vim look really good in the terminal as I’ve seenscreenshots of other setups on r/Unixporn,but I’ve not been able to create something I’m entirely happy with thus far soI’m currently exploring what Gvim (Vim GUI) has to offer.
Conclusion
Having spent six months using Vim as my main editor, I can say it has definitelybeen a worthwhile experience and I don’t see myself switching over to some othereditor anytime soon.
Right now, I’m looking to improve my mastery of the editor, and learn someadvanced flows to become even more efficient. To that end, I’m currently readingPractical Vim by DrewNeilwhich appears to be one of the best books on the subject.
If you already have a productive setup in your current editor, I don’t thinkit’s necessary to switch to Vim abruptly like I did. It may not even berealistic depending on your work situation.
Having said that, I think it is still useful to learn the Vim way of editingtext and you don’t need to use Vim itself to do so. Most editors have a pluginthat emulates Vim key bindings so you can easily experience the Vim way withoutthrowing away your existing workflow.
Here are the ones for Sublime,Atom, and VSCode.
I will keep sharing what I learn on this blog, so if you’re interested inchecking out Vim, don’t be afraid to try it. You might just like it.
Summary
This post will go through using Visual Studio Code (VS Code) as the “native” file editor for Linux by leveraging the Windows Subsystem for Linux 2 (WSL2). Cross-platform development between Windows and Linux has been made simpler over the years since the introduction of Windows Subsystem for Linux. Gone are the days of dual boots, hypervisor VMs, or multiple machines to get started in developing between Windows and Linux. However, until WSL2 I continued to use both Windows and Linux native editors for each environment. In Windows it is Visual Studio or VS Code and in Linux it is VIM or nano.
With WSL2 it is now possible to edit the direct Linux filesystem files from within VS Code in Windows which reduces the need for VIM/nano and provides IntelliSense for known file types. A very transparent editing experience with high productivity.
Prerequisites
- Windows 10 (version 2004 or higher)
Description
The intent of this post is not to compare VIM to VS Code or claim one is better than the other. Code/text editors strike passion in anyone who does any type of substantial editing, particularly if attempting to convince them there is a better one than what they are using. This passion is fully justified and what is the right editor for one may not be right for someone else. Regardless of editor; Notepad, Notepad++, Word, VS Code, Visual Studio, Eclipse, VI, VIM, nano, etc. if the one you are using makes you productive, then that is the right editor for you. After all, computing was intended to make our lives more productive, not less (a tidbit I sometimes find overlooked in the spirit of innovation).
The problem WSL2 and VS Code has solved, is if we are productive using VS Code based on its capabilities and extensions, such as IntelliSense, Source Code Management, etc., we want that productivity to carry across Windows and Linux filesystems.
WSL2 is a feature of Windows 10 that allows running a full Linux Kernel instance on the same machine utilizing its hypervisor technology, Hyper-V, effectively running a lightweight Linux VM on Windows. Yes, the summary is less than truthful by stating hypervisor VMs are gone. It is still there and the enabling technology for WSL2, however, we do not need to manage it ourselves, thus making us more productive. This virtualization technology enables us to view and edit the Linux filesystems from Windows using VS Code.
Next we will go through the steps of getting WSL2 installed and configured with VS Code integration to see this editing in practice. However, VS Code will not replace VIM, only make its use a little less (for my editing), and if we so choose we can even run VIM within VS Code as will be highlighted in the steps.
Steps
1. Install the Windows Subsystem for Linux 2 (WSL2) utilizing the Microsoft Installation Guide
2. Install the ‘Remote-WSL’ extension for VS Code
3. Open a Command Prompt and list installed WSL subsystems and their versions by typing:
4. Optional, I had WSL (v1) instances installed prior to running WSL2. One of these, Ubuntu, was configured for WSL2 by running the following command:
5. Using the WSL2 shell, in this case for Ubuntu, log in to the terminal.
6. Enter the following command to install the VS Code Server on Linux and launch VS Code in Windows from the current directory:
7. VS Code should launch into a WSL session showing the instance, Ubuntu, with a directory and file listing for the current directory.
8. Using VS Code, we can now open and edit the files directly, including a terminal window inside the editor for executing bash commands within Linux.
9. The Ubuntu WSL terminal can now be closed and all file editing and terminal commands can be executed directly within VS Code.
Goodbye VIM? Well, not really. I will continue to use VIM (and nano), particularly when working on systems with no WSL support or Windows. However, getting VS Code extensions and IntelliSense support for known file types while editing them directly on the Linux filesystem is a nice productivity boost.
Should the urge/need be there to continue editing with VIM, we can also perform that action while staying within VS Code using the terminal window. This gives us an editor-in-an-editor experience where changes in VIM shows up in VS Code (and vice versa). (Haven’t found a huge need for it, but pretty neat capability none the less :-))
10. Using the example from step 8, we keep the ‘hosts’ file open in the VS Code editor window and use the bash terminal to edit the same hosts file in VIM
11. Enter a new host entry, ‘piorange’ in VIM
12. Save the change and close VIM
13. Notice the VS Code editor version of the hosts file updates automatically to show the new change ‘piorange’
Vim Vs Visual Studio
Enjoy!
Next Steps
Visual Studio Code Vim Tabs
- Will this work if Windows and Linux are on separate machines and not using WSL2?
I don’t know but suspect the answer is no as of this writing, but perhaps someone can confirm. I could see it is a nice-to-have feature, but seems to stretch the intent behind WSL2 of being productive in a closed system loop between Windows and Linux.