GetCommand conditionally adds a filter (implemented as inline Ruby code
in the command line) to transform some of the problematic
Rails-specific eRuby syntax. Specifically, <%= tags are replaced with
<%.
This does not reduce the effectiveness of the linter, because the
transformed code is still evaluated.
This solution was suggested by @rgo at
https://github.com/w0rp/ale/issues/580#issuecomment-337676607.
GetCommand conditionally adds a filter (implemented as inline Ruby code
in the command line) to transform some of the problematic
Rails-specific eRuby syntax. Specifically, <%= tags are replaced with
<%.
This does not reduce the effectiveness of the linter, because the
transformed code is still evaluated.
This solution was suggested by @rgo at
https://github.com/w0rp/ale/issues/580#issuecomment-337676607.
Implements suggestions and recommendations suggested by the first review
of the "Advance C# linter based on mcs -t:module (#952)" pull request.
- Clarifies and simplifies description of linters and options
- Added links to help file and marked the mcsc linter as to be run only
when file in buffer is saved or loaded.
- Added comments to the mcsc.vim file to clarify code
- removed type checks considered not necessary be reviewer.
- addresses findings by vader
- removed call to getcwd and cd in vim script
- handler expands file names relative to route of source tree into
absolute pathes. Fixes errors not being marked when vim is started
from subdirectory of source tree.
- implements tests for mcs.vim and mcsc.vim linter
This fixes slim-lint not honoring a `.rubocop.yml` in the file's or
parent directory. Due to the way slim-lint calls rubocop, it requires
the special `SLIM_LINT_RUBUCOP_CONF` env var to pick up the
`.rubocop.yml` if it is not run on the real file (which is the case
here).
See https://github.com/sds/slim-lint/blob/master/lib/slim_lint/linter/README.md#rubocop
This linter works by invoking the `thrift` compiler with the buffer
contents and reporting any parser and code generation issues.
The handler rolls its own output-matching loop because we have the
(unfortunate) requirement of handling error output that spans multiple
lines.
Unit tests cover both the command callback and handler, and there is
initial documentation for all of the option variables.
