Translating Sublime Text into Vim

Intro

Coming from a Windows world getting into Vim, to me is almost exactly like the struggles I had learning French or Dutch. I spent 10 years learning French growing up and I can’t speak a proper sentence. I then moved from England to the Dutch speaking part of Belgium (Flanders) and I learnt to speak Dutch to a conversational level within 2 years.

If you’re going to learn Vim you need to immerse yourself in it. I suspect the majority of Vim users only ever use it to make minor file modifications via SSH. That’s what I did anyway.

I’ve used lots of editors in Windows but the one I prefer now is Sublime Text (ST). However ST has almost all the exact same commands as other editors, with the one major improvement which is Ctrl+P, we’ll come to that later. ST is free to use with a popup once in a while, its a great tool, you should buy a licence.

So for users of all other editors, all you have to do is learn the elements of Sublime Text I use here and then you should be able to translate them to your own editor. I hear you notepad lovers. So we’ll use ST as the boundary layer between our nice fuzzy Ctrl + N, Ctrl + C, Ctrl + V and :e, y and P.

Why O Why

Is it worth the pain? I have spent in excess of 100 hours doing nothing but learning Vim and getting it set up the way I want.

I mean, the question ‘How to close Vim?’ has a 1000+ up votes on Stack Overflow. That’s insanity.

However, I think that if you master Vim the layer between your thought and your code becomes thinner. So this has nothing to do with linting or plugins this has to do with performing at a higher level with the code that you write.

Also I think Vim is just misunderstood. This is where my analogy of learning a spoken language comes from. Switching between Windows editors is like switching dialects sure some of the Scottish folk sound funny, but you can understand what they say. All of us assume that Vim is just another dialect, but it’s not. It’s like nothing you’ve used before. So there’s nothing for your brain to grab on to and understand.

1. Vim gets you closer to your code. Once performant in Vim you can perform code editing tasks faster and keep up with the speed of your thought. This breaks through the ceiling that you will hit with most other GUI editors.
2. Vim is very fast, I don’t think it’s necessarily faster than ST, but certainly it’s at that level, everything happens instantly. There’s none of the delay that you sometimes have with opening ST or other heavier editors e.g. Netbeans, IntelliJ. Speed is one of the barriers between your thought and your code, slow editors are slowing you down.
3. Vim is ‘hyper’ cross-platform (Windows, Mac, Linux, SSH, Docker, Browser (via WASM), Android, Amiga …) and works via the command line, every benefit you learn on Windows means that you have the multiplied benefit that you can use the exact same instructions on Linux or on Mac. Again so it ST, but Vim works via SSH, it works in Docker, it works everywhere.
4. Once you learn the commands you can do things quicker, deleting a word is just typing dw, once fluent this can be performed faster than using the mouse or Ctrl+Shift+Right-arrow, Delete. These are small 1% improvements, but they add up.
5. Vim has a command history. This is really useful for doing repeated things. Sure your search box in other editors has it plus you’ll have recent files that you’ve opened, but every single command that you type is recorded. My example for this is reformatting code with Regex. Once you’ve closed your regular editor your search and replace history is lost. In Vim it’s there waiting for you.
6. Not only that but anything you did as the last command can be repeated with .. This can be complex things like repeating all the text you just typed in Insert mode. Or if you just cut a line and you want to paste it a few times, now you’re just typing . instead of Ctrl + V.
7. Syntax highlighting! In the DOS prompt, SSH prompt! Seriously, this is amazing. Windows has been around for 30 years and there’s nothing else I know of that can give you this.
8. Less Chrome. Vim is mostly like using the distration free mode of Sublime Text all the time. Less distraction, more thinking.
9. Everything you’ve got in your editor currently: Tabs, Split screen, Projects, Linting, REPL, Plugins, Sidebar file tree. But we’re still in the donkey DOS prompt here.
10. Closer to the command line. Again thinning that barrier between you and your code. In Vim you can type ! and then any command line command, e.g. !mkdir temp or !python will allow you to drop into the python REPL and then come straight back to Vim once you’re done.
11. Vim’s buffers, which are the equivalent of tabs in other editors, are amazing. When you have a regular editor open you’ll typically have 10 or so tabs open, or at least that’s what I had as otherwise it becomes too crammed. With Vim you just keep opening all the files you want into buffers. I regularly now work with 100 buffers open, but then I can very easily switch between them – :b [part of file name] then <Tab> and you switch to the other file, if you have more than one file open with that bit of the name then you just tab through the list, e.g. :b Controller will allow you to tab through all the *Controller* files (buffers) that you have open.
12. Not strictly Vim itself, but it has excellent integration with FZF and Ripgrep, which are Rust commandline tools for fuzzy file finding and ‘find in files’. These tools are ridiculously fast. Having a fuzzy file finder means that you don’t need the folder structure on the left any more. Ripgrep works better on Linux but in any place it will churn through GB of source code. Also once you have the search results you can do more with them, they open up in a standard Vim ‘window’ and so you can search/highlight in your search, can then also run search/replaces on the list that you get back.
13. Vim sessions are what allow Vim to work in a similar way to Sublime Text in that you can save all the open files that you had when you close Vim and open up exactly where you were last time.
14. But Vim sessions are really flexible, the one great thing I’ve found about them is that I can combine all the projects that I’m working on into one. My colleagues use various other IDEs and we have a set of projects each with their own git repo and docker container. My colleagues need to switch projects each time they want to look at code in one project. However I can put all the repos in one folder and then create my Vim session above all of them. Then FZF can find any files amongst them, Ripgrep can search through all of them at the same time. So it means I can jump-to-definition across any project that I have.
15. Combining all you do with other tools in one. Here’s a few things that I now do in Vim that I used to use other tools for: file diffs, git diffs, subversion diffs, todo lists, database connections/commands, git conflicts, subversion conflicts. This is not quite a case of Emacs where you never need to leave it again, but all my development tools work perfectly inside Vim, so I can use the power of the various commands I’ve learnt in Vim across these other tools
16. Git diffs, this is a surprising one, but once you start using Fugitive plugin doing a side by side diff is easy and comes with nice syntax highlighting
17. Git conflicts are handled beautifully with the Fugitive plugin, the majority of developers that I know only know how to use SourceTree or the output from Bitbucket diffs. With Fugitive you can do a 3-way vertical diff (see the Vimcast on Git conflicts), so you have the conflicted file in the middle with the two files you want to merge either side. It is the nicest way possible to do a merge. Even the GUI tools that I’ve seen that do do a 3-way merge are pretty ugly. Meld is quite good one for Linux and Windows, but it’s not fully supported on Mac, but this suffers from being slow. In Vim everything is fast and again I’ve got all my Vim tools handy as the diff windows are just Vim windows.
18. Todo lists is a simple one – but you have things like Org mode in Emacs that you can replicate in Vim, but for the most part Markdown does everything you need.
19. Database connections are always done in a special application. The main one I’ve used is SQL Server Management Studio (SSMS) – but of course that only works for SQL Server. If you work with MySQL either you need to use things like PHPMyAdmin or just use the MySQL command line, there are sometimes closed source tools for connecting to various databases but I’ve never particularly liked one. Tim Pope recently created the dadbod plugin that allows you to connect and run commands on all the major databases. This means that like SSMS I can have my SQL file open with syntax highlighting but then I can highlight a few lines and run those. This is super powerful, you then of course get all the query results in a Vim window and can use all the regular commands to search that and copy paste text from there. I still regard SSMS as the most powerful SQL editor that I used, but now I can have the majority of the functionality that I used there but for any database. I don’t have the things like query optimisations, but it’s rare that I need that.
20. Making a tailored editor… typically all you do with other editors is install a few plugins. With Vim it’s expected that you’ll customise almost everything. People with ST share their list of plugins, where as people with Vim share their .vimrc file which contains all their plugins and all their settings. It’s the difference between an off the peg suit and a tailored suit, other people might not see the difference but you will feel it. You create Vim exactly as you want it.
21. Made by individuals…
22. Fully free and open source, it’s inspired a whole bunch of new editors – neovim, gonvim, AMP…
23. Touch typing becomes more important. Once you use the keys for everything then you encourage yourself to touchtype more. This adds benefits to your coding. And as Joel Spolsky says, fast accurate typing is one of the fundamentals of a developer. I’m still not great at this but using Vim is helping me to improve.
24. Split windows are something that I never bothered with in ST, but recently they’ve become very useful. When I’m trying to implement a new feature based on someone elses code I find it useful to have a side-by-side view of the two files. Further I can have the main code I’m working on in one window and then search throughout the code in the other window. Again you can do things like this in ST but I never really started doing this until I got used to Vim and Vim split windows.

Lesson 1: Install GVim

GVim is by far the best way to get introduced to Vim, it is a much more standardised way of using Vim rather than starting in the terminal and hitting problems. I really want to encourage people to try using Vim in the DOS prompt just because it’s amazing to finally see it there but for anyone starting just use GVim. I still use GVim on Windows as there’s still a frustrating slowness to editing in the DOS prompt but almost all my other gripes with it have disappeared over the last two years – the Windows team changing it are doing an amazing job.

Nevertheless, we’ll start with GVim, as well as being more consistent it allows for discovery as it has a lot of common menu commands at top that typically say what the commands are so that you can slowly familiarise yourself with it.

I suggest installing GVim via Chocolatey, or otherwise you can just download it and install it from the vim.org site (that’s all Chocolatey does behind the scenes).

Hopefully it also means I can help more people, Powershell users can probably translate the DOS commands more easily to Powershell than vice-versa. Linux and Mac users used to using GUI tools should be able to figure it out too. When I write Ctrl + C people will understand, when I write <C-c> users unfamiliar with Vim / Emacs will stare blankly.

Install Vim in DOS (not required)

If you’ve installed GVim then this also installs a command line version of GVim. The good part of this is that it comes with the most recent version of Vim – currently 8.1. There are some very nice things that have been added in the most recent version that improves the colour handling inside the Windows 10 DOS prompt.

Add C:\Program Files\GVim\bin to your PATH.

I love using Vim inside the DOS prompt. I think it is the simplest, purest way of using Vim in Windows.

Vim 7.4 also comes with Git for Windows. You can install this via Chocolatey, or just via the Git website.

> choco install -y git

We then need to add the GNU usr tools to our PATH – add C:\Program Files\Git\usr\bin to your PATH.

This gives you all the loveliness of all the GNU tools e.g., ls, grep as well. If you really want to do yourself a favour install clink and solarized DOS prompt colours too.

Lesson 2: Basic commands

You can skip this if you know the commands. I knew the basics of these for years before I started immersing myself in the rest of Vim.

Inserting code

You go into the INSERT mode by hitting the i key and switch back to NORMAL mode by hitting escape.

Once you’re in edit mode then it’s fairly similar to other editors, you can move left, right, up, down with the arrow keys, then just type and delete stuff with the backspace or delete keys.

Initially to be more familiar with other non-modal editors most users will spend all their time in INSERT mode. I personally think there is nothing wrong with this and this is exactly what I did to be as productive as possible in the beginning.

To be more productive though, it is necessary to learn the other Vim commands, otherwise you’re just taking away all the other features that you’re used to in ST which almost all do exist in Vim, just that they’re more hidden or you need to install a plugin for it.

Searching / moving code

A lot of the Ctrl + ... commands that you expect from other editors are handled in Vim’s NORMAL mode – you should see the word NORMAL in the bottom left-hand corner.

This is the weirdest part of Vim, that you delete words via three or four letter commands.

I actually practiced the commands by installing an Android app with Vim commands and the beginnger free part of shortcutFoo Vim.

After those commands the next most important one is :. This is the most common way of starting the command line typing at the bottom. It’s similar to when you type Ctrl + P into ST.

The first command to type is :help, this shows the first cool thing of Vim – split windows as standard.

The weirdest concept I had (after years of very light usage) is typing :w instead of :x to write the file, because now we actually want to stay in Vim, rather than get the hell out as fast as possible.