I love writing with
vim, but — for many valid reasons — some people are averse to it. I think the
steep (–ish) learning curve has something to do with it, but I think some people really don’t want
to give up their IDE. The thing is,
vim isn’t just a text editor. You can extend it to do pretty
much anything, including features that normally show up in IDEs.
I recently started using syntastic, which is a
vim plugin that runs linters or syntax checkers
and displays warnings and errors right in your window. IDEs like Eclipse or Xcode provide this
syntax-checking for a couple of languages, but syntastic supports many languages and linters out of
the box with pluggable support for nearly any language.
If you use pathogen like every sane
vim user does, installing syntastic is just like any other
plugin. Clone the repository or create a submodule in
bundle/syntastic and you’re ready to go.
checking out the syntax checkers in
bundle/syntastic/syntax_checkers/, even if you just look at
the list of files there. You might have to dive into the files to figure out which linters are
actually supported as it’s not clearly documented.
Before we get to configuring individual syntax checkers, syntastic itself has a couple of configuration options. Syntastic has what it refers to as a “mode map”, which is basically just a way to configure which file types are checked. Here is the relevant config option from my vimrc:
1 2 3 4
The ‘mode’ option set to active means that syntastic is on by default, so we can leave the list of ‘active_filetypes’ empty. The ‘passive_filetypes’ names filetypes that syntastic does not attempt to check. I don’t check HTML files because I mainly work with templates that either can’t or won’t validate with most HTML syntax checkers. If templates use non-standard attributes, it’s hard for a syntax checker to do its job.
Setting up syntastic for use with python was extremely easy. Just install pyflakes with
pip install pyflakes and set up some related options. I ignore certain errors regarding
whitespace, indentation, and end-of-line backslashes, but those are all customizable. See the pep8
error code documentation for an explanation of the error codes.
1 2 3
linter, but I decided to use the communtiy-driven JS Hint. JS Hint can be
configured with a jshintrc, which just is a JSON object that contains options. There are two
categories of options: those that enforce stricter rules than the defaults and those that relax
default checks. The options page of the jshint website does a great job of
explaining each option. You can view my jshintrc on my Github page. I added a few
“enforcing” options, but the only “relaxing” option I use is
sub, which allows
subscript notation when accessing properties, e.g.
this['domNode'] as well as
You can tell syntastic to use jshint with the following config option:
By default, syntastic runs your file through the configured filetype’s linter whenever the buffer is
written. If there are errors, they are highlighted inline. When your cursor is on a line with an
error, the description of the error is visible in the status line. You can use the
to open a quickfix window with a list of all errors in the file. Pressing enter on an error will
take you to that line in the file. Syntastic uses vim’s signs, which means that a
gutter with a sign appears on the left side of every line with an error on it, making it easy to
scan the buffer for errors. You can change these symbols with some syntastic options.
1 2 3
You can configure syntastic in many other ways, including telling it to check a buffer whenever it
is opened. I explored the help file (
:help syntastic) when I first started using syntastic, and it
was incredibly helpful. I encourage anyone who uses syntastic to do the same.
Syntastic has already helped me avoid many typos and silly errors that would ordinarily be hard to track down. It’s an invaluable tool in my workflow.