How to Configure Syntastic
Syntastic is great. When it’s configured properly, it will highlight warnings and errors inline in the current Vim buffer. Here’s the obligatory Syntastic screenshot:
My experience with Syntastic was that it worked even though I had done nothing to configure it. The default configuration had done its job and, when I saved a buffer, my mistakes would be highlighted.
(I’m going to discuss C, but this applies to any language supported by Syntastic. I picked C because it was the first language that forced me to understand how Syntastic worked due to its vast number of checkers.)
Trying to understand how Syntastic works, I dug into the syntax checkers directory and opened the c subdirectory. Inside I found a bunch of files, each named after the executable used to check the syntax. That made a lot of sense, I could see where this was going.
But which one(s) of these would be used when checking my file? You can find out:
and it might look like this on your system:
Think of it as a funnel:
The first one, “ALL the checkers supported by Syntastic” changes over time; as people contribute more checkers, the list will grow. You can check the syntax checkers subdirectories on Github or the wiki.
The second one, “the checkers installed on your computer”, is self-explanatory :-)
The last one, “the checker(s) Syntastic will use”, is worth discussing. The
logic seems to be the first item from the list from
“Available checkers” filtered through a whitelist.
That’s not the whole story, however, because you can skip this logic and
manually tell Syntastic what to use.
Here’s what I recommend:
- start with seeing what’s possible
- install the checkers you want – make sure the executable names match what Syntastic expects
:SyntasticInfo– if it matches your needs, you are done.
- drop a line in your
.vimrcto specify the checkers
Here’s what that config might look like:
This follows the
g:syntastic_<filetype>_checkers format. If you manually
specify that list, you can put multiple checkers. If you do, each checker will
be called, in order, as long as the previous checkers don’t return an error.
In that case, you might want to list checkers from fastest to slowest, or from
looser to stricter.
I generalized on a few points, a lot of this behavior is customizable. The whole truth can be found in the documentation.