Update the contributing guide. Make :SyntasticInfo print version.

CONTRIBUTING.md

@@ -1,49 +1,89 @@
-# Bug reports / Github issues
+# Bug reports / GitHub issues
 
-When reporting a bug make sure you search the existing github issues for the
+Please note that the preferred channel for posting bug reports is the
-same/similar issues. If you find one, feel free to add a `+1` comment with any
+[issue tracker at GitHub][0].  Reports posted elsewhere are less likely
-additional information that may help us solve the issue.
+to be seen by the core team.
+
+When reporting a bug make sure you search the existing GitHub issues
+for the same/similar issues.  If you find one, feel free to add a `+1`
+comment with any additional information that may help us solve the
+issue.
 
 When creating a new issue be sure to state the following:
 
-* Steps to reproduce the bug.
+* steps to reproduce the bug;
-* The version of vim you are using.
+* the version of Vim you are using (run `:ver` to find out);
-* The version of syntastic you are using.
+* the version of syntastic you are using (see `:SyntasticInfo`).
 
-For syntax checker bugs also state the version of the checker executable that you are using.
+For syntax checker bugs also state the version of the checker executable
+that you are using.  Additional debugging information is typically
+useful too:
+
+* open a file handled by your checker;
+* set `g:syntastic_debug` to 1 or 3;
+* run the checker;
+* look at the output of `:mes`.
 
 # Submitting a patch
 
-* Fork the repo on github
+Before you consider adding features to syntastic, _please_ spend a few
-* Make a [topic branch](https://github.com/dchelimsky/rspec/wiki/Topic-Branches#using-topic-branches-when-contributing-patches) and start hacking
+minutes (re-)reading the latest version of the [manual][1].  Syntastic
-* Submit a pull request based off your topic branch
+is changing rapidly at times, and it's quite possible that some of the
+features you want to add exist already.
 
-Small focused patches are preferred.
+To submit a patch:
 
-Large changes to the code should be discussed with the core team first. Create an issue and explain your plan and see what we say.
+* fork the [repo][2] on GitHub;
+* make a [topic branch][3] and start hacking;
+* submit a pull request based off your topic branch.
+
+Small, focused patches are preferred.
+
+Large changes to the code should be discussed with the core team first.
+Create an issue and explain your plan and see what we say.
+
+Also make sure to update the manual whenever applicable.  Nobody can use
+features that aren't documented.
 
 # General style notes
 
-Following the coding conventions/styles used in the syntastic core:
+Follow the coding conventions/styles used in the syntastic core:
 
-* Use 4 space indents.
+* use 4 space indents;
-* Don't use abbreviated keywords - e.g. use `endfunction`, not `endfun` (there's always room for more fun!).
+* don't use abbreviated keywords - e.g. use `endfunction`, not `endfun`
-* Don't use `l:` prefixes for variables unless actually required (i.e. almost never).
+(there's always room for more fun!);
-* Code for maintainability. We would rather a function be a couple of lines longer and have (for example) some [explaining variables](http://www.refactoring.com/catalog/extractVariable.html) to aid readability.
+* don't use `l:` prefixes for variables unless actually required (i.e.
+almost never);
+* code for maintainability; we would rather a function be a couple of
+lines longer and have (for example) some [explaining variables][4] to
+aid readability.
 
-# Syntax checker style notes
+# Syntax checker notes
 
-The preferred style for error format strings is one "clause" per line. E.g.
+Make sure to read the [guide][5] if you plan to add new syntax checkers.
-(from the coffeelint checker):
 
-```viml
+Use the existing checkers as templates, rather than writing everything
-let errorformat = '%E%f:%l:%c: %trror: %m,' .
+from scratch.
-            \ 'Syntax%trror: In %f\, %m on line %l,' .
+
-            \ '%EError: In %f\, Parse error on line %l: %m,' .
+The preferred style for error format strings is one "clause" per line.
-            \ '%EError: In %f\, %m on line %l,' .
+E.g. (from the `coffee` checker):
-            \ '%W%f(%l): lint warning: %m,' .
+
-            \ '%W%f(%l): warning: %m,' .
+```vim
-            \ '%E%f(%l): SyntaxError: %m,' .
+let errorformat =
-            \ '%-Z%p^,' .
+    \ '%E%f:%l:%c: %trror: %m,' .
-            \ '%-G%.%#'
+    \ 'Syntax%trror: In %f\, %m on line %l,' .
+    \ '%EError: In %f\, Parse error on line %l: %m,' .
+    \ '%EError: In %f\, %m on line %l,' .
+    \ '%W%f(%l): lint warning: %m,' .
+    \ '%W%f(%l): warning: %m,' .
+    \ '%E%f(%l): SyntaxError: %m,' .
+    \ '%-Z%p^,' .
+    \ '%-G%.%#'
 ```
+
+[0]: https://github.com/scrooloose/syntastic/issues
+[1]: https://github.com/scrooloose/syntastic/blob/master/doc/syntastic.txt
+[2]: https://github.com/scrooloose/syntastic
+[3]: https://github.com/dchelimsky/rspec/wiki/Topic-Branches#using-topic-branches-when-contributing-patches
+[4]: http://www.refactoring.com/catalog/extractVariable.html
+[5]: https://github.com/scrooloose/syntastic/wiki/Syntax-Checker-Guide

plugin/syntastic.vim

@@ -19,7 +19,7 @@ if has('reltime')
     lockvar! g:syntastic_start
 endif
 
-let g:syntastic_version = '3.4.0-56'
+let g:syntastic_version = '3.4.0-57'
 lockvar g:syntastic_version
 
 " Sanity checks {{{1

plugin/syntastic/registry.vim

@@ -172,7 +172,8 @@ function! g:SyntasticRegistry.getKnownFiletypes() " {{{2
 endfunction " }}}2
 
 function! g:SyntasticRegistry.echoInfoFor(ftalias_list) " {{{2
-    echomsg "Syntastic info for filetype: " . join(a:ftalias_list, '.')
+    echomsg "Syntastic version: " . g:syntastic_version
+    echomsg "Info for filetype: " . join(a:ftalias_list, '.')
 
     let ft_list = syntastic#util#unique(map( copy(a:ftalias_list), 's:normaliseFiletype(v:val)' ))
     if len(ft_list) != 1