* Rust Cargo linter: Improve workspace support
When using Cargo workspaces [1], there is a 'Cargo.toml' directory in a
top level directory, listing all the crates in the project. If we are
currently editing one of the crates, 'cargo build' should execute in
that directory for that crate's separate `Cargo.toml`, otherwise Cargo
may spend more time possibly rebuilding the entire workspace, and maybe
failing on one of the other crates, instead of succeeding on the current.
[1] https://doc.rust-lang.org/book/second-edition/ch14-03-cargo-workspaces.html
Like many other linters, use variables for the executable and options
used by the linter.
By default, the linter now report every warnings as errors with
`--warning-errors`.
Also add include directory and set working directory to file directory.
* Set `--parser` option in Prettier's fixer
* Add expected `--parser` option to tests
* Disable Prettier `--parser` detection if file extension exists
* Manually default Prettier `--parser` to "babylon"
* Add `--parser` test for TypeScript
* Add tests for Prettier `--parser`
* Add JSON5 to the suggested fixer for Prettier
* Guard the ballooneval settings
* Mark main objectives to do to get nice Hover
* Make tweaks to make the tooltip work - See " XXX: comments
* Guard balloon_show call
* Use return instead of finish for functions
* ale#hover#show : Add optional arguments to specify arbtirary position
This change is requested to be able to call the function with mouse
position to enable hover information in vim's balloon
* ale#ballon#Disable : Remove feature guards
* ale#balloon : Show 'ALEHover' output on balloon if no diagnostic found
* ale#hover#HandleLSPResponse : remove the check for cursor position
This check prevented the 'ALEHover in balloon' feature, since mouse
position is almost never cursor position.
* ale#balloon#MessageForPos : Change the return of balloonexpr
balloonexpr evaluation now works even without balloon_show for basic
diagnostics, leaving the balloon_show call to ale#hover#Show, which can
then feature guard the call to avoid errors
* ale#hover#Response : Feature guard balloon_show calls
* ale#hover : always display 'Hover' information in messages
Also add a small comment to warn readers the different outputs the
ale#hover#Show will write to
* {LSP,TS}Response : use only variables from the Response
It is clearer that we only rely on l:options to get the relevant data to
build the LSP Response string
* hover#ShowDetails : fix an issue where not having focus broke balloons
The issue was caused by not using a buffer-specific version of getline()
to cap the value of the column sent in the message to LSP. Therefore a
cursor on column 10 in an inactive window could send a message with
column=0, if the active window had a buffer with too few lines
* {LSP,TS}Response : Remove redundant checks for balloon_show call
With the upcoming change in ale_set_balloons default value (see Pull
Request w0rp/ale#1565), this check will be useless
* balloonexpr? : Add a flag to separate hover#Show() calls
The goal of this flag is to make `:ALEHover` calls not pop a balloon
under the cursor, since the user has probably no interest in their
cursor while typing the command
The flag is a default argument which is overridden only in ballonexpr
call of ale#hover#Show, and stays set in the hover_map until the
callback for the LSP handles it.
There are no automated tests for this feature right now, and the nature
of the addition (one optional argument in the API) should make it
transparent to existing tests.
Since the differentiation is now possible, the check for moved cursor
has been put back in ale#hover#HandleLSPResponse
* ale#hover#hover_map : Protect accesses to hover_map
Using get() is safer than trying to access directly with ., as the tests
show.
* Raise timeout to try to get Appveyor happy
* Review : Fix comments
* Review : pass the optional argument 'called_from_balloonexpr' in a Dict
This optional dictionary has documentation just before the function
using it, ale#hover#Show, and allows easier extension in the future.
* Update section 5.viii in the README with ALEJobStarted and re-format
the example.
* Add an extra line after documentation update to ensure consistency
with the rest of the doc.
Adding a couple of tests to demonstrate how IsCheckingBuffer behaves
during specific autocommand hooks:
* At ALELintPre, no linters have actually executed yet, hence
IsCheckingBuffer should be returning false.
* ALEJobStarted, fires as early as reasonably possible after a job has
successfully started, and hence hooking into IsCheckingBuffer here
should return true.
This distinction is important when using these two events during things
like statusline refreshes, namely for "linter running" indicators.
The ALELintPre and ALELintPost autocommand events are currently being
used by lightline-ale to refresh the status line and check the linter
status for a current buffer. One of the plugin's checks looks to see if
linters are currently running, via ale#engine#IsCheckingBuffer(). This
currently only works partially in certain situations. In my particular
case, working with Go files, this only seems to function properly when a
file is initially opened. Saving a file does not correctly update the
status.
This seems to be due to the fact that ALELintPre actually runs before
any jobs are carried out, making it plausible that hooking into
ALELintPre for the purpose of checking to see if there are any currently
running linters for a buffer is unreliable as it would be prone to
pretty obvious race conditions.
This adds a new User autocommand, ALEJobStarted, that gets fired at the
start of every new job that is successfully run. This allows a better
point to hook into checking the linter status of a buffer using
ale#engine#IsCheckingBuffer() by ensuring that at least one job has
started by the time IsCheckingBuffer is run.
For now, it only detects undefined steps. The nearest `features` dir
above the buffer file is loaded, so step definitions should be found
correctly.
Tested only with Cucumber for Ruby, but it should work for any cucumber
that follows a substantially similar directory structure.
This removes the argument if the specified toolchain is empty.
As far as I can tell there is no +nighly (or similar) option [1] leading to
the termination of the server. But since people needed this option and
have yet to complain about it it stays the default for now.
[1] https://github.com/rust-lang-nursery/rls/blob/master/src/main.rs#L87
* Add first qmlfmt support
* Add GetCommand() function
- pass --error/-e option
* Add handle unittest
- fix pattern regex
- store col as integer
* Update docs
* Add command callback unit test
* Add fsc as a Scala linter
* Pull reused code into `autoload/ale/` directory
* Include fsc into the README
* Add unit test for testing the scala handler
* Add unit test for scala's fsc linter
* Rename scala unit tests for clarity
* Fix typo in README
* Fix typos in doc/ale.txt
* Fix author headline
* Put methods for fsc commands back into fsc.vim
* Move command_callback tests to correct location
* Rewrite handler test so it actually tests handler
* Clarify description of test in test_scala_handler
* handle multibyte string when linting text with redpen
* fix error when no string is provided, fix test's expect value
* remove ambiguious `==` operator
* Fixed (g)awk linter
* Made it secure, albeit less useful.
* Added gawk handler; the cpplint one was not working?
* Added gawk handler test.
* added warning to gawk handler.
* added gawk command callback test
* added comment about --source
* added back optional commandline option
* Handle flawfinder severity level
* Reverted code allowing Flawfinder to piggyback off of gcc's format handler
* Gave Flawfinder its own format handler and made requested changes.
Support for elm-format as a fixer has existed since Sept 2017, but it's not
easy to discover because the fixer was named `format`. This breaks the
convention of the other fixers that use the full name in the registry.
I've gone ahead and fixed this discrepancy, but I left the existing registry
entry in place. We should move people towards using `elm-format` as the fixer
name, but I'd hate to break existing setups.
* If a Perl script compiles, there are only warnings and no errors
* Let the first Perl error or warning win.
Take the following example:
***
sub foo {
my $thing;
***
This might have the following messages when we compile it:
Missing right curly or square bracket at warning.pl line 7, at end of
line
syntax error at warning.pl line 7, at EOF
warning.pl had compilation errors.
With the current behaviour, we just get a "syntax error" message, which
isn't all that helpful. With this patch we get "Missing right curly or
square bracket".
* Fix variable scope and pattern matching syntax
* Use named variable to enhance clarity when matching Perl output
* Add more tests for Perl linter
* Remove unnecessary parens
* Simplify check for pattern match
* Add configuration option to open lists vertically
* Add tests, clean up vertical list config
* Vertical list option cleanup
* Use is# for tests
* Order properties in documentation alphabetically
* Flawfinder support added for C and C++
A minor modification to gcc handler was made to support flawfinder's
single-line output format that does not have a space following the
colon denoting the warning level. gcc handler still passes its
Vader tests after this modification.
* Documentation fixes
* Revert documentation regression
* Added Flawfinder to table of contents
* Removed trailing whitespace
* Follow ALE conventions better
Added additional documentation and Vader tests
* Add Elixir linter for dialyxir
* Update doc/ale.txt with dialyxir
* Keep elixir tools alphabetically ordered in README
* Add a missing entry for dialyxir to the main documentation file.
Erubi is yet another parser for eRuby. This is the default parser in
Rails as of version 5.1. It supports some additional syntax with similar
behavior to Rails' extensions to the language, though incompatible.
Rails currently still recommends their own syntax, so GetCommand still
has to do the translation introduced in
https://github.com/w0rp/ale/pull/1114 .
Erubi does not supply an executable—It is intended to be invoked only
from within a Ruby program. In this case, a one-liner on the command
line.
* When working on rust/cargo projects of varying sizes, it may be useful
to either build all possible features (i.e. lint all possible
conditionally compiled code), or even turn off other features for a
quicker edit-lint cycle (e.g. for large projects with large build times)
* Added a g:ale_rust_cargo_default_feature_behavior flag for instructing
cargo to not build any features at all (via `--no-default-features`),
building default features (via no extra flags), or building all possible
features (via `--all-features`)
* Also added a g:ale_rust_cargo_include_features flag for including
arbitrary features to be checked by cargo. When coupled with
g:ale_rust_cargo_default_feature_behavior this allows for full
customization of what features are checked and which ones are ignored
Typically proto files depend on and make use of proto definitions in
other files. When invoking protoc user can supply paths to inspect for
dependencies.
This patch makes it possible to configure flags passed to protoc. This
makes it e.g., possible to change include paths of the linter's protoc
invocation.
The test already handled arbitrary paths reasonably well, but setting
the directory interfered via leakage with others tests for some reason.
This patch removes the call to `SetDirectory` in the fixture setup and
the subsequent cleanup in the teardown as they are not required.
On macOS, Apple's command line toolchain installs very old `tidy`
command (It was released on 31 Oct 2006). It does not consider new specs
such as HTML5 so we should avoid it.
rustfmt normally acts on a file in place, and applies configuration
from rustfmt.toml files according to the path of the file.
Using a temporary file for rustfmt breaks this functionality, so
removing the '%t' from the rustfmt command.
Switches all vale instances to JSON output and provides an appropriate
handler for that. Without JSON, no end_col is provided and text
highlighting only catches the first character of every result.
In Go you can "vendor" packages by putting them in the `vendor/`
directory for a project. Adding the `-srcdir` argument makes `goimports`
pick up these packages, in addition to what you have in GOPATH.
Without this, `goimports` is not very useful, since most projects vendor
their packages.
This grew out of my work in #1193; to ensure the statusline was being
updated I had to add:
fun! s:redraw(timer)
redrawstatus
endfun
augroup ALEProgress
autocmd!
autocmd BufWritePost * call timer_start(100, function('s:redraw'))
autocmd User ALELint redrawstatus
augroup end
Which kind of works, but is ugly. With this, I can replace the
`BufWritePost` with:
autocmd User ALEStartLint redrawstatus
Which is much better, IMHO.
Actually, this patch actually replaces adding a function, since you can
do:
augroup ALEProgress
autocmd!
autocmd User ALEStartLint hi Statusline ctermfg=darkgrey
autocmd User ALELint hi Statusline ctermfg=NONE
augroup end
or:
let s:ale_running = 0
let l:stl .= '%{s:ale_running ? "[linting]" : ""}'
augroup ALEProgress
autocmd!
autocmd User ALEStartLint let s:ale_running = 1 | redrawstatus
autocmd User ALELint let s:ale_running = 0 | redrawstatus
augroup end
Both seem to work very well in my testing.
No need to `ale#Statusline#IsRunning()` anymore, I think?
* puppet: add test for puppet parser validate
* puppet: handle where parser validate doesn't supply the column
* puppet: add test for when parser validate doesn't supply column
* Fix puppet regex to handle Windows paths
- Re: f224ce8a37
- The issues that prompted the above commit which reverted changes made to `go build` and
`gometalinter` seemed to suggest that the main issue was with gometalinter and that
changes should be put into different commits so they are independent of each other
- This commit reinstates the changes to the `go build` linter which seem to be uncontested
and it also seems absolutely necessary to show errors from all files in the package which
may have caused a build failure.
The previous version relied on a zsh-specific behavior where
`<filename` after a pipe could redirect to the first command. This
is the standard way to do it.
* Added filename keys to gobuild and gometalinter
* Removed skipping files not in current package
* Removed `--include` for gometalinter
* Fixed the tests
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.
Ale saves a temporary file (%t) which does not share the same path as
the original file, breaking import statements with relative URLs.
This fix sends content to `lessc` over stdin and adds
the current file (%s) as one of the included paths, so statements like
`@import '../utils' will correctly resolve based on the current file path.
There were a couple of issues
- `paste` requires a file argument
- `mktemp` requires a pattern argument
- `sort` doesn't support `-h`, but `-n` is enough for sorting on numbers, and `-s` was introduced to perform a stable sort instead.
The main issues were that BSD `sed` does not support:
- Alternation (`\|`) - solved by splitting to multiple patterns
- Bound shortcuts (`x\+`, `x\?`) - solved by replacing with `xx*` and `x\{0,1\}` respectively
- Lower-casing (`\L`) - solved by piping through `tr` instead (this will lowercase everything and not only the integration names, but I assumed that wasn't too much of an issue, as a portable alternative for the selective downcasing would be much more involved).
Looks like elm-make only respects /dev/null, even on Windows. The person
who wrote this linter maybe did not test it on Windows, and wrote the
code in the way you would expect to be solid by using NUL on Windows.
However it seems elm-make is not actually making use of /dev/null but
rather using it as a form of flag. Ironically this seems to be what is
already described in the comments; I added some clarification.
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
The existing c-charp linter used the --syntax check mode of the mono mcs
compiler only. The new mcsc linter tries to compile the files located in
a directory tree located bejond the specified source directory or the
current one if no source is explicitly specified. The resulting module
target is placed in a temporary file managed by ale.
The existing c-charp linter used the --syntax check mode of the mono mcs
compiler only. The new mcsc linter tries to compile the files located in
a directory tree located bejond the specified source directory or the
current one if no source is explicitly specified. The resulting module
target is placed in a temporary file managed by ale.
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
* Add prettier fixer support for typescript
* Add prettier fixer support for css and scss
* Add prettier fixer support for json
* Use getbufvar() to get &filetype
* Detect and use CM files for smlnj
* Split into two checkers
- one for CM projects
- one for single SML files
* Fix some typos
* Fix error caught by writing tests
We want to actually use `glob` to search in paths upwards from us.
(Previously we were just searching in the current directory every time!)
* Fix errors from former test run
* Write tests for GetCmFile and GetExecutableSmlnj
* Typo in 'smlnj/' fixture filenames
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.
* Add support for prettier configuration file.
As of version 1.6.0, prettier allows passing a `--config` argument with
a path to a configuration file.
* Add test prettier configuration file.
* Add option to use local prettier configuration.
* Add description for new prettier option.
* Also check if the config is present before using it.
A limited number of clang-tidy checks can be used with C, too. I pretty much
copied and refactored the C++ clang-tidy linter, and added some documentation
about C-compatible checks.
You can also configure your fixers from vimrc using `g:ale_fixers`, before
or after ALE has been loaded.
```vim
" In ~/.vim/vimrc, or somewhere similar.
letg:ale_fixers= {
\ 'javascript': ['eslint'],
\}
```
" Set this setting in vimrc if you want to fix files automatically on save.
" This is off by default.
If you want to automatically fix files when you save them, you need to turn
a setting on in vimrc.
```vim
" Set this variable to 1 to fix files when you save them.
letg:ale_fix_on_save=1
```
The `:ALEFixSuggest` command will suggest some supported tools for fixing code,
but fixers can be also implemented with functions, including lambda functions
too. See `:help ale-fix` for detailed information.
The `:ALEFixSuggest` command will suggest some supported tools for fixing code.
Both `g:ale_fixers` and `b:ale_fixers` can also accept functions, including
lambda functions, as fixers, for fixing files with custom tools.
See `:help ale-fix` for complete information on how to fix files with ALE.
<a name="usage-completion"></a>
@@ -187,9 +258,7 @@ too. See `:help ale-fix` for detailed information.
ALE offers some support for completion via hijacking of omnicompletion while you
type. All of ALE's completion information must come from Language Server
Protocol linters, or similar protocols. At the moment, completion is only
supported for TypeScript code with `tsserver`, when `tsserver` is enabled. You
can enable completion like so:
Protocol linters, or from `tsserver` for TypeScript.
```vim
" Enable completion where available.
@@ -198,6 +267,39 @@ let g:ale_completion_enabled = 1
See `:help ale-completion` for more information.
<a name="usage-go-to-definition"></a>
### 2.iv Go To Definition
ALE supports jumping to the definition of words under your cursor with the
`:ALEGoToDefinition` command using any enabled Language Server Protocol linters
and `tsserver`.
See `:help ale-go-to-definition` for more information.
<a name="usage-find-references"></a>
### 2.v Find References
ALE supports finding references for words under your cursor with the
`:ALEFindReferences` command using any enabled Language Server Protocol linters
and `tsserver`.
See `:help ale-find-references` for more information.
<a name="usage-hover"></a>
### 2.vi Hovering
ALE supports "hover" information for printing brief information about symbols at
the cursor taken from Language Server Protocol linters and `tsserver` with the
`ALEHover` command.
On vim/gvim with `balloon` support you can see the information in a tooltip
that appears under the mouse when you mouseover a symbol.
See `:help ale-hover` for more information.
<a name="installation"></a>
## 3. Installation
@@ -306,12 +408,28 @@ on Freenode. Web chat is available [here](https://webchat.freenode.net/?channels
### 5.i. How do I disable particular linters?
By default, all available tools for all supported languages will be run.
If you want to only select a subset of the tools, simply create a
`g:ale_linters` dictionary in your vimrc file mapping filetypes
to lists of linters to run.
By default, all available tools for all supported languages will be run. If you
want to only select a subset of the tools, you can define `b:ale_linters` for a
single buffer, or `g:ale_linters` globally.
The recommended way to configure linters is to define a List in an ftplugin
file.
```vim
" In ~/.vim/ftplugin/javascript.vim, or somewhere similar.
" Enable ESLint only for JavaScript.
letb:ale_linters= ['eslint']
" Equivalent to the above.
letb:ale_linters= {'javascript': ['eslint']}
```
You can also declare which linters you want to run in your vimrc file, before or
after ALE has been loaded.
```vim
" In ~/.vim/vimrc, or somewhere similar.
letg:ale_linters= {
\ 'javascript': ['eslint'],
\}
@@ -322,6 +440,14 @@ be run for those languages, just as when the dictionary is not defined.
Running many linters should not typically obstruct editing in Vim,
as they will all be executed in separate processes simultaneously.
If you don't want ALE to run anything other than what you've explicitly asked
for, you can set `g:ale_linters_explicit` to `1`.
```vim
" Only run linters named in ale_linters settings.
letg:ale_linters_explicit=1
```
This plugin will look for linters in the [`ale_linters`](ale_linters) directory.
Each directory within corresponds to a particular filetype in Vim, and each file
in each directory corresponds to the name of a particular linter.
@@ -357,9 +483,35 @@ highlight clear ALEErrorSign
highlightclearALEWarningSign
```
<a name="faq-change-highlights"></a>
### 5.iv. How can I change or disable the highlights ALE uses?
ALE's highlights problems with highlight groups which link to `SpellBad`,
`SpellCap`, `error`, and `todo` groups by default. The characters that are
highlighted depend on the linters being used, and the information provided to
ALE.
Highlighting can be disabled completely by setting `g:ale_set_highlights` to
`0`.
```vim
" Set this in your vimrc file to disabling highlighting
letg:ale_set_highlights=0
```
You can control all of the highlights ALE uses, say if you are using a different
color scheme which produces ugly highlights. For example:
```vim
highlightALEWarningctermbg=DarkMagenta
```
See `:help ale-highlights` for more information.
<a name="faq-statusline"></a>
### 5.iv. How can I show errors or warnings in my statusline?
### 5.v. How can I show errors or warnings in my statusline?
[vim-airline](https://github.com/vim-airline/vim-airline) integrates with ALE
for displaying error information in the status bar. If you want to see the
@@ -397,14 +549,25 @@ set statusline=%{LinterStatus()}
See `:help ale#statusline#Count()` for more information.
<a name="faq-lightline"></a>
### 5.vi. How can I show errors or warnings in my lightline?
[lightline](https://github.com/itchyny/lightline.vim) does not have built-in
support for ALE, nevertheless there is a plugin that adds this functionality: [maximbaz/lightline-ale](https://github.com/maximbaz/lightline-ale).
For more information, check out the sources of that plugin, `:help ale#statusline#Count()` and [lightline documentation](https://github.com/itchyny/lightline.vim#advanced-configuration).
<a name="faq-echo-format"></a>
### 5.v. How can I change the format for echo messages?
### 5.vii. How can I change the format for echo messages?
There are 3 global options that allow customizing the echoed message.
-`g:ale_echo_msg_format` where:
*`%s` is the error message itself
*`%...code...%` is an optional error code, and most characters can be
written between the `%` characters.
*`%linter%` is the linter name
*`%severity` is the severity type
-`g:ale_echo_msg_error_str` is the string used for error severity.
@@ -422,24 +585,34 @@ Will give you:

See `:help g:ale_echo_msg_format` for more information.
<a name="faq-autocmd"></a>
### 5.vi. How can I execute some code when ALE stops linting?
### 5.viii. How can I execute some code when ALE starts or stops linting?
ALE runs its own [autocmd](http://vimdoc.sourceforge.net/htmldoc/autocmd.html)
event whenever has a linter has been successfully executed and processed. This
autocmd event can be used to call arbitrary functions after ALE stops linting.
events when a lint or fix cycle are started and stopped. There is also an event
that runs when a linter job has been successfully started. These events can be
used to call arbitrary functions during these respective parts of the ALE's
operation.
```vim
augroupYourGroup
autocmd!
autocmdUserALELintcallYourFunction()
autocmdUserALELintPrecallYourFunction()
autocmdUserALELintPostcallYourFunction()
autocmdUserALEJobStartedcallYourFunction()
autocmdUserALEFixPrecallYourFunction()
autocmdUserALEFixPostcallYourFunction()
augroupEND
```
<a name="faq-navigation"></a>
### 5.vii. How can I navigate between errors quickly?
### 5.ix. How can I navigate between errors quickly?
ALE offers some commands with `<Plug>` keybinds for moving between warnings and
errors quickly. You can map the keys Ctrl+j and Ctrl+k to moving between errors
@@ -455,7 +628,7 @@ For more information, consult the online documentation with
<a name="faq-lint-on-save"></a>
### 5.viii. How can I run linters only when I save files?
### 5.x. How can I run linters only when I save files?
ALE offers an option `g:ale_lint_on_save` for enabling running the linters
when files are saved. This option is enabled by default. If you only
@@ -475,7 +648,7 @@ files, you can set `g:ale_lint_on_save` to `0`.
<a name="faq-quickfix"></a>
### 5.ix. How can I use the quickfix list instead of the loclist?
### 5.xi. How can I use the quickfix list instead of the loclist?
The quickfix list can be enabled by turning the `g:ale_set_quickfix`
option on. If you wish to also disable the loclist, you can disable
@@ -500,9 +673,12 @@ let g:ale_open_list = 1
letg:ale_keep_list_window_open=1
```
You can also set `let g:ale_list_vertical = 1` to open the windows vertically
instead of the default horizontally.
<a name="faq-jsx-stylelint-eslint"></a>
### 5.x. How can I check JSX files with both stylelint and eslint?
### 5.xii. How can I check JSX files with both stylelint and eslint?
If you configure ALE options correctly in your vimrc file, and install
the right tools, you can check JSX files with stylelint and eslint.
@@ -521,9 +697,18 @@ augroup END
```
Supposing the filetype has been set correctly, you can set the following
options in your vimrc file:
options in a jsx.vim ftplugin file.
```vim
" In ~/.vim/ftplugin/jsx.vim, or somewhere similar.
letb:ale_linters= ['stylelint','eslint']
letb:ale_linter_aliases= ['css']
```
Or if you want, you can configure the linters from your vimrc file.
```vim
" In ~/.vim/vimrc, or somewhere similar.
letg:ale_linters= {'jsx': ['stylelint','eslint']}
letg:ale_linter_aliases= {'jsx': 'css'}
```
@@ -535,7 +720,7 @@ no linter will be run twice for the same file.
<a name="faq-my-battery-is-sad"></a>
### 5.xi. Will this plugin eat all of my laptop battery power?
### 5.xiii. Will this plugin eat all of my laptop battery power?
ALE takes advantage of the power of various tools to check your code. This of
course means that CPU time will be used to continuously check your code. If you
@@ -557,3 +742,76 @@ still be an advantage.
If you are still concerned, you can turn the automatic linting off altogether,
including the option `g:ale_lint_on_enter`, and you can run ALE manually with
`:ALELint`.
<a name="faq-c-configuration"></a>
### 5.xiv. How can I configure my C or C++ project?
The structure of C and C++ projects varies wildly from project to project, with
many different build tools being used for building them, and many different
formats for project configuration files. ALE can run compilers easily, but
ALE cannot easily detect which compiler flags to use.
" warning: (3) unable to parse response signature, expected 'response [<HTTP status code>] [(<media type>)]'; line 4, column 3k - line 4, column 22
" warning: (10) message-body asset is expected to be a pre-formatted code block, separate it by a newline and indent every of its line by 12 spaces or 3 tabs; line 30, column 5 - line 30, column 9; line 31, column 9 - line 31, column 14; line 32, column 9 - line 32, column 14
letl:pattern='\(^.*\): (\d\+) \(.\{-\}\); line \(\d\+\), column \(\d\+\) - line \d\+, column \d\+\(.*; line \d\+, column \d\+ - line \(\d\+\), column \(\d\+\)\)\{-\}$'
" ** (CompileError) apps/sim/lib/sim/server.ex:87: undefined function update_in/4
"
" TODO: Warning format
" warning: variable "foobar" does not exist and is being expanded to "foobar()", please use parentheses to remove the ambiguity or change the variable name
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.