This fixes performance problems in Neovim, where every character results
in spawning a new clipboard-tool process.
Behaviour is not similarly pathological in Vim, but it still results in
an unnecessary amount of register churn.
There is currently a check that tries to prevent c-flags that contain
'-' in them from being unintentionally split and included in the list of
commands. For example, we wouldn't want "-fno-exceptions " to appear as
"-fno" and "-exceptions ". The way this check was done was by making sure
the last character of the split string was a space.
This meant that the very last option to appear in the compile command
was ignored (as it doesn't end with a space). This fix explicitly skips
the ends-with-space check on the last option in the command-line.
This isn't the best fix. Really we should be using the same
argument-processing rules as a shell would rather than just splitting on
'-'. That's a much larger and more complicated change though.
The output format used by older checkstyle versions differs from the one
of new versions. This commit adds a second parsing iteration on the
output lines with a suitable pattern to support both versions in
parallel. Due to the differences in the order of matching groups this is
hard to achieve in a single pass through the output lines.
An appropriate test case is added.
Removed ale_virualtext_prefix from debugging since it's not requried for
the functionality to work.
Sorted debugging info to make the list easier to navigate/diff.
- Add g:ale_virtualtext_cursor boolean to enable/disable it
- Add g:ale_virtualtext_prefix to configure what prefix to use (default:
'> ')
- Requires neovim 0.3.2's unreleased API `nvim_buf_set_virtual_text`
Problem: ocamlformat is configured to format files in-place and thus go
via creating a temporary file for that. Because temporary file resides
in a different directory ocamlformat can't find `.ocamlformat`
configuration files in an original location of source files.
Solution: ocamlformat since version 0.8 can read sources on stdin and
spur result on stdout. We reconfigure ocamlformat to use a simpler
interface.
Previously, elixir-ls would treat each sub-project within an umbrella as
standalone, which isn't desirable from a language server perspective.
Added ale#handlers#elixir#FindMixUmbrellaRoot, which locates the current
project's root and then continues searching upwards for a potential
umbrella project root. This literally looks just two levels up to keep
things simple while keeping in line with Elixir project conventions.
Use this new function to determine elixir-ls's LSP project root.
* Allow configuration of hamllint executable
The hamllint executable was hard-coded, preventing it from being
overridden. Fix the executable to be dynamic to allow custom executable
paths.
This adds generic configuration dictionary support to the elixir-ls
linter. This is useful for disabling its built-in Dialyzer support, for
example, which can improve startup time.
The configuration dictionary is a little verbose. I considered reducing
the user configuration to only the nested settings dictionary (and
having the linter implementation wrap it in the top-level `elixirLS`
dictionary), but leaving it fully configurable simplifies the code and
removes any assumptions about current or future ElixirLS behavior.
Each LSP connection now stores its configuration dictionary. It is
initially empty (`{}`) and is updated each time the LSP connection is
started. When a change is detected, the workspace/didChangeConfiguration
message is sent to the LSP servers with the updated configuration.
This is the callback-based variant of the existing `lsp_config` linter
option. It serves the same purpose but can be used when more complicated
processing is needed.
`lsp_config` and `lsp_config_callback` are mutually exclusive options;
if both an given, a linter preprocessing error will be raised.
The runtime logic has been wrapped in `ale#lsp_linter#GetConfig` for
convenience, similar to `ale#lsp_linter#GetOptions`.
This also adds documentation and an `AssertLSPConfig` test function for
completeness.
* add prolog/swipl linter
* use load_files/2 instead of read_term/2
Because it also checks some semantic warnings / errors
not only syntactic warnings / errors.
e.g.:
* singleton warning
* discontiguous warning
* ...
cf. http://www.swi-prolog.org/pldoc/doc_for?object=style_check/1
* support error messages with no line number
:- module(module_name, [pred/0]).
causes
ERROR: Exported procedure module_name:pred/0 is not defined
* add test for prolog/swipl handler
* cosmetic fixes
* detect timeout using SIGALRM
* rename g:prolog_swipl_goals to g:prolog_swipl_load
* write doc for prolog/swipl linter
* update toc and README
* fix ignore patterns
* Only run stack if a stack.yaml config is found
It is necessary to check for a stack.yaml file to distinguish between
cabal-only projects or stack projects (which are also cabal projects
since stack is built on top of cabal).
* Test that stack is called if stack.yaml exists
ElixirLS (https://github.com/JakeBecker/elixir-ls) is an LSP server for
Elixir. It's distributed as a release package that can be downloaded
from https://github.com/JakeBecker/elixir-ls/releases or built locally.
The easiest way to start it is via Unix- and Win32-specific helper
scripts, so that's the basis of this command integration. Alternatively,
we could implement the contents of those platform-specific scripts in
the linter's command callback in a language-neutral way, but there isn't
any benefit to doing that aside from eliminating the platform check, and
that could prove to be too tight of a coupling going forward.
* FIX: use mix from the project root directory
* Move find root project function to autoloaded handlers
* add tests for #ale#handlers#elixr#FindMixProjectRoot
PMD is currently not working properly for Java classes that use [unnamed
packages](https://docs.oracle.com/javase/specs/jls/se11/html/jls-7.html#jls-7.4.2).
Consider the following Java class that does not contain a `package`
declaration:
```java
public class App {
String getGreeting() {
return "Hello world.";
}
static void main(String... args) {
System.out.println(new App().getGreeting());
}
}
```
Running PMD in the command line agaist the Java class above produces an
output with empty string `""` in the `"Package"` column:
```sh
$ pmd -R category/java/bestpractices.xml -f csv -d './src/main/java/App.java'
Oct 02, 2018 9:10:39 PM net.sourceforge.pmd.PMD processFiles
WARNING: This analysis could be faster, please consider using Incremental Analysis: https://pmd.github.io/pmd-6.7.0/pmd_userdocs_incremental_analysis.html
"Problem","Package","File","Priority","Line","Description","Rule set","Rule"
"1","","/Users/diego/Projects/github.com/dlresende/kata-fizz-buzz/src/main/java/App.java","2","7","System.out.println is used","Best Practices","SystemPrintln"
```
But the pmd.vim handler's current pattern refuses everything coming
from a Java class that does not have a package name (2nd column):
```vim
let l:pattern = '"\(\d\+\)",".\+","\(.\+\)","\(\d\+\)","\(\d\+\)","\(.\+\)","\(.\+\)","\(.\+\)"$'
```
The solution I am proposing is to also accept empty strings as package names.
These test vars were covering up a bug in the hlint linter
implementation. Without these vars we can see the behavior that is
exhibited in `vim` proper.
* Add better support for Haskell stack compiler tools
This commit adds support for `stack` as the executable of a tool. This
follows a pattern that has been implemented for `bundler`'s tool chain.
* Move hlint command to linter file
* Add vader test for stack exec handling
* Update ghc-mod to support stack execution
`ghc-mod` was previously broken into 2 linters.
1. ghc_mod
2. stack_ghc_mod
This additional linter is not necessary with proper support for
executable variables and `stack exec` handling.
* Support stack exec in hfmt
* Support stack in hdevtools
* Don't add newlines when not a control statement for Python
* Add test for accidental newline fix
* Add docstring detection to avoid adding unnecessarily newlines
* Add tests for docstring detection
In a lint context, it's useful to assume that included files sit next to
the current file by default. Users can still further customize this
configuration variable to add more include paths.
When set to true, and the buffer is currently inside a pipenv,
GetExecutable will return "pipenv", which will trigger the existing
functionality to append the correct pipenv arguments to run each linter.
Defaults to false.
I was going to implement ale#python#PipenvPresent by invoking
`pipenv --venv` or `pipenv --where`, but it seemed to be abominably
slow, even to the point where the test suite wasn't even finishing
("Tried to run tests 3 times"). The diff is:
diff --git a/autoload/ale/python.vim b/autoload/ale/python.vim
index 7baae079..8c100d41 100644
--- a/autoload/ale/python.vim
+++ b/autoload/ale/python.vim
@@ -106,5 +106,9 @@ endfunction
" Detects whether a pipenv environment is present.
function! ale#python#PipenvPresent(buffer) abort
- return findfile('Pipfile.lock', expand('#' . a:buffer . ':p:h') . ';') isnot# ''
+ let l:cd_string = ale#path#BufferCdString(a:buffer)
+ let l:output = systemlist(l:cd_string . 'pipenv --where')[0]
+ " `pipenv --where` returns the path to the dir containing the Pipfile
+ " if in a pipenv, or some error text otherwise.
+ return strpart(l:output, 0, 18) !=# "No Pipfile present"
endfunction
Using vim's `findfile` is much faster, behaves correctly in the majority
of situations, and also works reliably when the `pipenv` command doesn't
exist.
Solargraph allows to set configuration options by creating a
.solargraph.yml file at the root of the project using it. Therfore this
file is a good canditate for finding ruby projects root paths.
Initial discussion:
https://github.com/w0rp/ale/issues/1874#issuecomment-418316168
* The project style linter now runs while you type.
* Now the scripts for checking the project require blank lines.
* Many style issues have been found and fixed.
It can be necessary to pass options to the puppet parser validation. The
most glaring example of this is when using Puppet 3, with the
`parser = future` option enabled. This update allows adding
`--parser=future` to the options passed to Puppet.
* Add stylish-haskell as a fixer
`stylish-haskell` is a common formatting tool for the haskell toolchain.
It is not as advanced as `brittany` or `hindent`, but it is commonly
used for formatting of imports and data declarations. This adds it as a
fixer in ALE.
I see no reason to do this? It is just setting the environment to what
it already is?
It was originally added in #297, but that entire PR is not a great idea
in the first place; that PR (together with #270) tried to make the Go do
non-standard and non-supported stuff like compiling packages outside of
GOPATH.
That's not something that works well (I tried), so was eventually
removed in #465, but these "go env" calls remained, for no reason in
particular, as far as I can think of.
This will improve on #1834; you will now no longer get a confusing error
(but still won't get a meaningful error; need to think how to do that).
It wasn't immediately obvious that the `g:ale_fixers` cannot be a list,
and would allow the use of `*` to match all filetypes. I was hoping to
add a bit more detail to the README to make this clearer.
* Adding support for haskell-ide-engine
* Work with the current directory if no stack.yaml file is found
* Added Cabal file detection, updated documentation and added tests
* Updated help
fixes#1738
- Replace previous `hh_client` usage with LSP client
- Add `HHAST` linter
- Split Hack from PHP: Hack is increasingly diverging from PHP:
- Hack tools do not understand PHP
- Most PHP tools do not handle Hack code well (including vim's syntax
highightling files)
- http://github.com/hhvm/vim-hack now sets filetype to `hack`
When dializer isn't a dependency, mix dialyzer recompiles the whole
project because it's not possible to know if this command dialyzer exist
or not until recompilation is done. Then the timestamps of the project
is messed up which results in broken hot-loading. In this case, mix help
dialyzer would return zero which prevents compilation of the whole
project since dialyzer isn't installed, it's help manual doesn't exist.
When dialyzer is a dependency, mix dialyzer would just run the command.
In this case, mix help dialyzer would return 1 which allows mix dialyzer
to run.
* Add kotlin languageserver linter definition
* Added kotlin languageserver references in docs, fix missing !! on other linters
* Added Vader tests for root path detection in Kotlin Language Server
"Pipfile" and "Pipfile.lock" files are also often located in Python module or
package directories and their presence is an okay heuristic for finding project
roots.
Pipenv doesn't do local virtualenvs by default, it uses a special local
directory to store them all.
However, if you run Pipenv with the PIPENV_VENV_IN_PROJECT environment variable
set to 1, it creates the virtual environment in the root of the project, under
the name ".venv". This is why I've added this as a possible virtualenv dir
name.
* 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.
ALE (Asynchronous Lint Engine) is a plugin for providing linting in NeoVim
and Vim 8 while you edit your text files.
0.2.0+ and Vim 8 while you edit your text files, and acts as a Vim
[Language Server Protocol](https://langserver.org/) client.
<img src="img/example.gif?raw=true" alt="A linting example with the darkspectrum color scheme in GVim." title="A linting example with the darkspectrum color scheme in GVim.">
ALE makes use of NeoVim and Vim 8 job control functions and timers to
run linters on the contents of text buffers and return errors as
@@ -15,9 +17,26 @@ back to a filesystem.
In other words, this plugin allows you to lint while you type.
In addition to linting support, ALE offers some support for fixing code with
formatting tools, and completion via Language Server Protocol servers, or
servers with similar enough protocols, like `tsserver`.
ALE offers support for fixing code with command line tools in a non-blocking
manner with the `:ALEFix` feature, supporting tools in many languages, like
`prettier`, `eslint`, `autopep8`, and more.
ALE acts as a "language client" to support a variety of Language Server Protocol
features, including:
* Diagnostics (via Language Server Protocol linters)
* Go To Definition (`:ALEGoToDefinition`)
* Completion (`let g:ale_completion_enabled = 1` before ALE is loaded)
* Finding references (`:ALEFindReferences`)
* Hover information (`:ALEHover`)
* Symbol search (`:ALESymbolSearch`)
If you don't care about Language Server Protocol, ALE won't load any of the code
for working with it unless needed. One of ALE's general missions is that you
won't pay for the features that you don't use.
If you enjoy this plugin, feel free to contribute or check out the author's
other content at [w0rp.com](https://w0rp.com).
## Table of Contents
@@ -26,23 +45,34 @@ servers with similar enough protocols, like `tsserver`.
1. [Linting](#usage-linting)
2. [Fixing](#usage-fixing)
3. [Completion](#usage-completion)
4. [Go To Definition](#usage-go-to-definition)
5. [Find References](#usage-find-references)
6. [Hovering](#usage-hover)
7. [Symbol Search](#usage-symbol-search)
3. [Installation](#installation)
1. [Installation with Vim package management](#standard-installation)
2. [Installation with Pathogen](#installation-with-pathogen)
3. [Installation with Vundle](#installation-with-vundle)
4. [Installation with Vim-Plug](#installation-with-vim-plug)
4. [Contributing](#contributing)
5. [FAQ](#faq)
1. [How do I disable particular linters?](#faq-disable-linters)
2. [How can I keep the sign gutter open?](#faq-keep-signs)
3. [How can I change the signs ALE uses?](#faq-change-signs)
4. [How can I show errors or warnings in my statusline?](#faq-statusline)
5. [How can I change the format for echo messages?](#faq-echo-format)
6. [How can I execute some code when ALE stops linting?](#faq-autocmd)
7. [How can I navigate between errors quickly?](#faq-navigation)
8. [How can I run linters only when I save files?](#faq-lint-on-save)
9. [How can I use the quickfix list instead of the loclist?](#faq-quickfix)
10. [How can I check JSX files with both stylelint and eslint?](#faq-jsx-stylelint-eslint)
11. [Will this plugin eat all of my laptop battery power?](#faq-my-battery-is-sad)
4. [How can I change or disable the highlights ALE uses?](#faq-change-highlights)
5. [How can I show errors or warnings in my statusline?](#faq-statusline)
6. [How can I show errors or warnings in my lightline?](#faq-lightline)
7. [How can I change the format for echo messages?](#faq-echo-format)
8. [How can I execute some code when ALE starts or stops linting?](#faq-autocmd)
9. [How can I navigate between errors quickly?](#faq-navigation)
10. [How can I run linters only when I save files?](#faq-lint-on-save)
11. [How can I use the quickfix list instead of the loclist?](#faq-quickfix)
12. [How can I check JSX files with both stylelint and eslint?](#faq-jsx-stylelint-eslint)
13. [How can I check Vue files with ESLint?](#faq-vue-eslint)
14. [Will this plugin eat all of my laptop battery power?](#faq-my-battery-is-sad)
15. [How can I configure my C or C++ project?](#faq-c-configuration)
16. [How can I configure ALE differently for different buffers?](#faq-buffer-configuration)
17. [How can I configure the height of the list in which ALE displays errors?](#faq-list-window-height)
<a name="supported-languages"></a>
@@ -55,87 +85,128 @@ tools will be run in combination, so they can be complementary.
Keep the table rows sorted alphabetically by the language name,
and the tools in the tools column sorted alphabetically by the tool
name. That seems to be the fairest way to arrange this table.
Remember to also update doc/ale.txt, which has a similar list with different
formatting.
-->
**Notes:**
* *^ No linters for text or Vim help filetypes are enabled by default.*
* *!! These linters check only files on disk. See `:help ale-lint-file-linters`*
" 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,17 +282,62 @@ 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.
" This setting must be set before ALE is loaded.
letg: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.
The information can be displayed in a `balloon` tooltip in Vim or GVim by
hovering your mouse over symbols. Mouse hovering is enabled by default in GVim,
and needs to be configured for Vim 8.1+ in terminals.
See `:help ale-hover` for more information.
<a name="usage-symbol-search"></a>
### 2.vii Symbol Search
ALE supports searching for workspace symbols via Language Server Protocol
linters with the `ALESymbolSearch` command.
Search queries can be performed to find functions, types, and more which are
similar to a given query string.
See `:help ale-symbol-search` for more information.
<a name="installation"></a>
## 3. Installation
@@ -281,6 +421,18 @@ Plugin 'w0rp/ale'
See the Vundle documentation for more information.
<a name="installation-with-vim-plug"></a>
### 3.iiii. Installation with Vim-Plug
You can install this plugin using [Vim-Plug](https://github.com/junegunn/vim-plug)
by adding the GitHub path for this repository to your `~/.vimrc`
and running `:PlugInstall`.
```vim
Plug'w0rp/ale'
```
<a name="contributing"></a>
## 4. Contributing
@@ -306,12 +458,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 +490,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 +533,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 +599,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 +635,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 +678,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 +698,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 +723,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,11 +747,20 @@ 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_linter_aliases= ['css','javascript']
letb:ale_linters= ['stylelint','eslint']
```
Or if you want, you can configure the linters from your vimrc file.
" 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
" file.go:27: missing argument for Printf("%s"): format reads arg 2, have only 1 args
" file.go:53:10: if block ends with a return statement, so drop this else and outdent its block (move short variable declaration to its own line if necessary)
" file.go:5:2: expected declaration, found 'STRING' "log"
" go test returns relative paths so use tail of filename as part of pattern matcher
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.
