Adding support the foodcritic linter for Chef files.
Listing all issues as warnings for now
Doesn't get in the way of rubocop linting if ft=ruby.chef
Updated documentation
Closes#127
* Add `javascript/flow` linter
* Add documentation for flow
* Remove a line from the docs that was from eslint
* Only run if flow gives output; Correct link in doc
* Address PR feedback #157
Shellcheck is smart enough to check the shebang in a given file to
determine which dialect to use. Unfortunately this doesn't work for
files without shebangs, even if it might be apparent what dialect should
be used, such as "bashrc" or "foo.bash". Luckily `filetype.vim` defines
specific vars based on which shell dialect is being used based on a huge
list of conditions. With this change we take those into account for all
the types shellcheck supports, otherwise we fallback to letting it try
and decide.
This PR first and formost implements support for dot-seperate filetypes,
a very trivial change.
This closes#132
But more importantly, this PR vastly improves the test quality for
`ale#linter#Get`. It enables us to reset the state of ale's internal
linter cache, to facilitate better testing, as well as making use of
mocked linters instead of depending on linters on disk (which may
change). In addition, a dummy linter is defined to test the autoloading
behavior.
Header guards were removed from all linters as:
* A: ale won't try and load linters if they already exist in memory
* B: we can't reset state for testing if they can't be loaded again
* Add Credo linter for Elixir
* Add requested changes
TODO: check if all message types are covered in `if` chain.
* Add information about Credo linter to README
* Add information about Credo linter to doc
* First pass at optimizing ale to autoload
First off, the structure/function names should be revised a bit,
but I will wait for @w0rp's input before unifying the naming style.
Second off, the docs probably need some more work, I just did some
simple find-and-replace work.
With that said, this pull brings major performance gains for ale. On my
slowest system, fully loading ale and all its code takes around 150ms.
I have moved all of ale's autoload-able code to autoload/, and in
addition, implemented lazy-loading of linters. This brings load time on
that same system down to 5ms.
The only downside of lazy loading is that `g:ale_linters` cannot be
changed at runtime; however, it also speeds up performance at runtime by
simplfying the logic greatly.
Please let me know what you think!
Closes#59
* Address Travis/Vint errors
For some reason, ale isn't running vint for me...
* Incorporate feedback, make fixes
Lazy-loading logic is much improved.
* Add header comments; remove incorrect workaround
* Remove unneeded plugin guards
* Fix lazy-loading linter logic
Set the wrong variable....
* Fix capitialization
* Ensure that php linter pattern does not include spaces:
PHP can return errors with extra spaces like the following:
`PHP Parse error: syntax error, unexpected end of file in t.php on line 4`
* Set option locally to buffer
* Rename noErrors variable according to the project's naming convention
* Make the jsonlint pattern a little better
* Implement an option to configure the echoed message, #48
Via `g:ale_echo_msg_format` where:
- `%s` is the error message itself
- `%linter%` is the linter name
- `%severity` is the severity type
e.g
let g:ale_echo_msg_fomat = '[%linter%] [%severity%] %s'
* Add new options for defining the string used for errors in echoed
message
`g:ale_echo_msg_error_str` and `g:ale_echo_msg_warning_str`
* Change text output of some linters
Now that the echoed message can be customized, no need to add the type
to the text variable.
* Update README & documentation file
* Fix some typos
* Sort the table of options alphabetically (except echo_msg_x_str options)
* Added echo warning str option to the doc
