Discussing software, the web, politics, sexuality and the unending supply of human stupidity.

Some notes on Vim and Visual Studio Code

I’ve recently been playing with text editors a bit. I’ve been trying out Microsoft’s excellent Visual Studio Code and I have found it to be perhaps the best editor for both a language I love (Python) and a language I have to occasionally write (JavaScript, or one of its many spinoffs). I like it so much that I ported over a TextMate bundle for handling Mako templates.1

Visual Studio Code really is great, but my one true love is and probably always will be Vim. I recently upgraded to Vim 8.0 which came out in September. The async I/O and channels support should make it so things like linters can be adapted to not block the editing thread on save. This is good.

Today, I finally cleared up my .vimrc, refactored it out into some separate files, and took a position on the Vundle vs Pathogen debate. I’ve used Pathogen in the past, but Vundle seems preferable. Git submodules are an unending source of pain and confusion. Vundle lets me just specify a list of plugins and have that list stored in version control, much like a Gemfile or a requirements.txt or bundle.json or whatever Node is doing this week to download left-pad.

These are the packages I actually use lots in Vim:

  • editorconfig-vim: this is grade A amazing. The idea of EditorConfig is you create a file called .editorconfig and you put it in the root of your project. It specifies all the editor settings: character set, indent style, indent spacing, end-of-line coding, final newline etc.
  • vim-gitgutter: once set up right, it shows you what you have changed in the editor’s gutter (that is, margin) of your files
  • ctrlp: a pretty good fuzzy file finder. The only thing I wish it did was integrate with EditorConfig so that “don’t peek inside that stupidly large node_modules folder that the front-end guys use” could be specified in a shared config file.
  • vim-endwise: because if you find yourself writing Ruby, you may as well set up ways to spend less time actually writing Ruby.
  • vim-commentary: comment and uncomment things.

I have a bunch of other stuff installed in Vim including fugitive (Git integration), ack.vim (which gives you integration with the ack/ag search tools, which are basically faster versions of grep) and vim-rails (no prizes for guessing what that does). I don’t tend to use them. Two reasons. One is that I will often just use the command line. I don’t really feel like I need to use Vim as a command line replacement. 2 For something like Git, I either use the command line, or I use SourceTree. I don’t really feel like I need it baked into my editor.

The second reason I don’t use plugins I have downloaded: I don’t use them just because I don’t use them. They haven’t stuck in my head. They are quite likely to be useful but I haven’t burned the commands into my mind like I have with Vim itself and with the other plugins I use. One of the things that Visual Studio Code, Sublime Text 23 and TextMate before it did was make commands discoverable quite a bit easier by having a commands “palette” you could use. I should probably have a personal Vim cheatsheet. I already know the basic functionality of Vim well enough but each plugin brings some potentially powerful new stuff that you don’t really bother using until you actually learn how to use it.

There’s a few things I want to try soon. One is setting up ale, the asynchronous linting engine for Vim, which will asynchronously run your code through a whole variety of linters for different languages. The most useful for me being flake8 and whatever the least awful JavaScript one is when I next write JavaScript.

Oh, and while we are talking about linters, let’s talk about Proselint. Proselint is an actually useful linter for English prose. It isn’t a grammar checker. There are too many of those. I recently saw a grammar-checker-as-a-service called Grammarly being advertised at me during a YouTube video. The ad featured a rather clueless social media strategist needing a Chrome plugin to correctly spell basic words. The premium edition of Grammarly costs $139.95 a year. Jesus. Proselint is designed for people who are generally able to write in English but want the sort of thing one would consult a style guide over checked. I have a Proselint plugin setup in Visual Studio Code. Once I set up the ale plugin, I hope I will get the same in Vim.

I also tried vim-devicons and Powerline/Airline, but having to install custom fonts just wasn’t something I really felt like bothering with long term, so I stopped. I’m going to give Gundo a try soon.

  1. Mako templates aren’t such a good idea, but Pyramid seems to use them. I tend to normally use either Jinja or Django templates, or ERb in Rails land (because HAML annoys me, and “logic-less templates” are a lie).

  2. Try Emacs for that. It has a surprisingly pretty website for something hosted on!

  3. I’m told. I have never really used any version of Sublime Text. After TextMate was left without updates for such a long time, I lost interest in ever using an editor that wasn’t both free-as-in-beer and free-as-in-Stallman.