About half a dozen years ago, I was between jobs and had a whole month of August to invest in whatever I wanted to do. So I decided that some of that time should go into learning some coding tool, some skill that could pay off in the long term. I chose Vim for several reasons, the main one being ergonomics. For me, this is the question of "how is it even possible to consider coding every day for hours?" There are fundamental issues of back and wrist pain that everyone experiences at least once in a while, so finding a good posture that minimizes them seemed a worthwhile investment.
Oh, and when I say "finding a good posture" I already know that "just sit up straight, damn it" doesn't work for me. Does it work for anyone? Inevitably, you slouch and forget where your body should be. Posture is just something you remember at most once a day. The solution I ended up gravitating towards was just putting my keyboard on my lap. This forces my elbows and shoulders down, which is the easiest way to have a straighter back. I also find that it can be a very comfortable focused posture. The challenge is getting it to work when you also need to use a mouse. And that's where Vim comes in. It's kind of like the same idea of not attacking a problem head-on: instead of "just don't use a mouse", you use Vim knowing that, by the way, you also don't need to move the cursor with your mouse. Much like typing with your keyboard in your lap and finding that now your posture is just better.
However, like many web developers, I don't read and write code 100% of the time. I also go through many iterations of web interfaces and have to manage a lot of content. This means I still use a mouse and it's very handy to have a keyboard in my native Portuguese layout. This last point is one that turns the Vim learning curve into a bit of a wall. People say "just use :help" but forget that almost immediately you are greeted with something like "Position the cursor on a tag (e.g. |bars|) and hit CTRL-]". And square brackets don't have their own keys in a lot of keyboard layouts, mine requires Alt+8 or Alt+9 to [ or ] for example. Generally, Vim just assumes you are looking at an US/UK layout when you're learning it and, if you don't, you kind of have to go on your own personal voyage of discovery to set it up just as you like it, more than the usual customization that Vim is already all about. I also am forced to use Windows for work, so I don't get the benefit of having Vim inside its real home, Linux.
This does get tiring after a while. There are Vim features that I haven't really gotten around to leveraging fully because I'm not sure what's the best way to integrate them with my layout. I learn slowly, but it's not that hard to get going, and eventually, you do end up with a fun productive tool at your fingertips. Vim is full of unique perks that I also enjoy besides my main reason for using it. It's nice to have a code editor that's the lightest piece of software you need to keep open for doing your job. It's just always there when you need it. If the machine is running slow, you know it's not Vim.
And I also find it interesting how it's becoming more like a verb than a subject. You can Vim in the command line but also a GUI. You can also Vim in Visual Studio Code and use the same vimrc configuration with VSCodeVim. You can even Vim in a browser to navigate through pages with something like Vimium. Not to mention that you can Vim into pretty much any text area with VimEverywhere or VimAnywhere. Of course, all of these options have some issues if you want to keep your exact configuration, but the thing is that Vim is here to stay. Both as a real tool and an inspiration for many others. It's simply something you can do if you know how to.
The way that I manage to learn Vim is by picking one feature at a time and trying to incorporate it as best as I can into my workflow. In the beginning, this took about two weeks to get the basics down and be almost as productive as when using Sublime Text, for example. After that, it's all about finding the next snag, saying to yourself "there has to be a better way" and going through the many options Vim can have. Usually, you should start with what you can do just with the current version of Vim and then you can look for plugins that address your problem. For example, autocomplete is a feature that can have many facets and the basic ones come with Vim already, especially if you're coding in older languages. However, you do need plugins if you want full IDE-level auto-completion and code hints. Myself, I've yet to find a plugin that works for me to help with Javascript or PHP development, so I still stick to what Vim already has built in. And this can include calling out to the command line from inside Vim.
But that's the thing with more advanced plugins in my experience, about 4 out of 10 error out when starting Vim or just don't seem to do anything. They usually depend on other plugins and/or having something like Python working inside Vim. For example, to have even just basic syntax checking, I think I've tried about half-a-dozen plugins across the years and I still end up just calling php -l or tsc to check the file (by the way, for some weird reason, it seems that the Typescript compiler is the easiest command line tool to just check a .js file for syntax errors). Other options I've debated in my head are learning Vimscript to start understanding why are all these plugins blowing up in my face or just switching to VSCode and getting baked-in IDE features in exchange for a less lightweight experience. Recently, another viable option seems to be using Vim inside the Windows Subsystem for Linux, which might help get some plugins going I guess. Both WSL2 and the new Windows Terminal are still in the early days, but there's considerable momentum for making them viable.
As you can probably gather from all of this, Vim is one of those free awesome tools that you don't pay for with your money but with your time. And about six years using it is not enough, you have to put in the work to fully optimize your workflow and I don't. It's just good enough for me right now, which is marginally better than Sublime Text, but still better where it counts: letting go of the mouse. Yes, it's still all about coding every day and not developing an injury. One other related thing that I'll also mention is having the right keyboard to sit on your lap. I've now settled on a UHK despite the problems of getting it to work for me with my native layout (a recurring theme). It's a small programmable keyboard that much like Vim is all about doing everything from your home row keys. I will probably be sharing more about my love for mechanical keyboards and Vim in future posts. See you soon.
(Originally written on November 14, 2020)
Oh, and when I say "finding a good posture" I already know that "just sit up straight, damn it" doesn't work for me. Does it work for anyone? Inevitably, you slouch and forget where your body should be. Posture is just something you remember at most once a day. The solution I ended up gravitating towards was just putting my keyboard on my lap. This forces my elbows and shoulders down, which is the easiest way to have a straighter back. I also find that it can be a very comfortable focused posture. The challenge is getting it to work when you also need to use a mouse. And that's where Vim comes in. It's kind of like the same idea of not attacking a problem head-on: instead of "just don't use a mouse", you use Vim knowing that, by the way, you also don't need to move the cursor with your mouse. Much like typing with your keyboard in your lap and finding that now your posture is just better.
However, like many web developers, I don't read and write code 100% of the time. I also go through many iterations of web interfaces and have to manage a lot of content. This means I still use a mouse and it's very handy to have a keyboard in my native Portuguese layout. This last point is one that turns the Vim learning curve into a bit of a wall. People say "just use :help" but forget that almost immediately you are greeted with something like "Position the cursor on a tag (e.g. |bars|) and hit CTRL-]". And square brackets don't have their own keys in a lot of keyboard layouts, mine requires Alt+8 or Alt+9 to [ or ] for example. Generally, Vim just assumes you are looking at an US/UK layout when you're learning it and, if you don't, you kind of have to go on your own personal voyage of discovery to set it up just as you like it, more than the usual customization that Vim is already all about. I also am forced to use Windows for work, so I don't get the benefit of having Vim inside its real home, Linux.
This does get tiring after a while. There are Vim features that I haven't really gotten around to leveraging fully because I'm not sure what's the best way to integrate them with my layout. I learn slowly, but it's not that hard to get going, and eventually, you do end up with a fun productive tool at your fingertips. Vim is full of unique perks that I also enjoy besides my main reason for using it. It's nice to have a code editor that's the lightest piece of software you need to keep open for doing your job. It's just always there when you need it. If the machine is running slow, you know it's not Vim.
And I also find it interesting how it's becoming more like a verb than a subject. You can Vim in the command line but also a GUI. You can also Vim in Visual Studio Code and use the same vimrc configuration with VSCodeVim. You can even Vim in a browser to navigate through pages with something like Vimium. Not to mention that you can Vim into pretty much any text area with VimEverywhere or VimAnywhere. Of course, all of these options have some issues if you want to keep your exact configuration, but the thing is that Vim is here to stay. Both as a real tool and an inspiration for many others. It's simply something you can do if you know how to.
The way that I manage to learn Vim is by picking one feature at a time and trying to incorporate it as best as I can into my workflow. In the beginning, this took about two weeks to get the basics down and be almost as productive as when using Sublime Text, for example. After that, it's all about finding the next snag, saying to yourself "there has to be a better way" and going through the many options Vim can have. Usually, you should start with what you can do just with the current version of Vim and then you can look for plugins that address your problem. For example, autocomplete is a feature that can have many facets and the basic ones come with Vim already, especially if you're coding in older languages. However, you do need plugins if you want full IDE-level auto-completion and code hints. Myself, I've yet to find a plugin that works for me to help with Javascript or PHP development, so I still stick to what Vim already has built in. And this can include calling out to the command line from inside Vim.
But that's the thing with more advanced plugins in my experience, about 4 out of 10 error out when starting Vim or just don't seem to do anything. They usually depend on other plugins and/or having something like Python working inside Vim. For example, to have even just basic syntax checking, I think I've tried about half-a-dozen plugins across the years and I still end up just calling php -l or tsc to check the file (by the way, for some weird reason, it seems that the Typescript compiler is the easiest command line tool to just check a .js file for syntax errors). Other options I've debated in my head are learning Vimscript to start understanding why are all these plugins blowing up in my face or just switching to VSCode and getting baked-in IDE features in exchange for a less lightweight experience. Recently, another viable option seems to be using Vim inside the Windows Subsystem for Linux, which might help get some plugins going I guess. Both WSL2 and the new Windows Terminal are still in the early days, but there's considerable momentum for making them viable.
As you can probably gather from all of this, Vim is one of those free awesome tools that you don't pay for with your money but with your time. And about six years using it is not enough, you have to put in the work to fully optimize your workflow and I don't. It's just good enough for me right now, which is marginally better than Sublime Text, but still better where it counts: letting go of the mouse. Yes, it's still all about coding every day and not developing an injury. One other related thing that I'll also mention is having the right keyboard to sit on your lap. I've now settled on a UHK despite the problems of getting it to work for me with my native layout (a recurring theme). It's a small programmable keyboard that much like Vim is all about doing everything from your home row keys. I will probably be sharing more about my love for mechanical keyboards and Vim in future posts. See you soon.
(Originally written on November 14, 2020)