vim/syntastic
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Update the contributing guide. Make :SyntasticInfo print version.

Browse Source
This commit is contained in:
LCD 47 2014-05-04 13:58:25 +03:00
parent 43e8cb955e
commit dc02d66648
3 changed files with 74 additions and 33 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

102
CONTRIBUTING.md
View File

@ -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
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.
Please note that the preferred channel for posting bug reports is the
[issue tracker at GitHub][0]. Reports posted elsewhere are less likely
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.
* The version of vim you are using.
* The version of syntastic you are using.
* steps to reproduce the bug;
* the version of Vim you are using (run `:ver` to find out);
* 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
* Make a [topic branch](https://github.com/dchelimsky/rspec/wiki/Topic-Branches#using-topic-branches-when-contributing-patches) and start hacking
* Submit a pull request based off your topic branch
Before you consider adding features to syntastic, _please_ spend a few
minutes (re-)reading the latest version of the [manual][1]. Syntastic
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.
* Don't use abbreviated keywords - e.g. use `endfunction`, not `endfun` (there's always room for more fun!).
* 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](http://www.refactoring.com/catalog/extractVariable.html) to aid readability.
* 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 `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.
(from the coffeelint checker):
Make sure to read the [guide][5] if you plan to add new syntax checkers.
```viml
let errorformat = '%E%f:%l:%c: %trror: %m,' .
\ '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%.%#'
Use the existing checkers as templates, rather than writing everything
from scratch.
The preferred style for error format strings is one "clause" per line.
E.g. (from the `coffee` checker):
```vim
let errorformat =
\ '%E%f:%l:%c: %trror: %m,' .
\ '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

2
plugin/syntastic.vim
View File

@ -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

3
plugin/syntastic/registry.vim
View File

@ -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