Working directories are now set seperately from the commands so they
can later be swapped out when running linters over projects is
supported, and also better support filename mapping for running linters
on other machines in future.
* 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
* 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
* 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
Right now ghc-mod linter check temp file instead of current buffer,
which cause the problem that it can't detect cabal file and raise
missing package error.
To fix that we need to run ghc-mod check with actual path of the current
file and with ghc-mod option `--map-file` to redirect temp file source
code to actual one
* Vim scripts shouldn't have hyphens
Especially not ones that will be autoloaded. You can't have a hyphen in
a function name, so autoloading functions based on filename will fail.
* Add g:haskell_stack_build_options, default: --fast
If we're going to use the --fast option, we may as well go the whole 9
yards and let the user configure the 'stack build' flags.
* Create documentation for stack-build options
* Add stack-build linter for Haskell
The stack-build linter works better than the other two linters when
you're working with an entire Haskell project. It builds the project
entirely and reports any errors.
The other two Haskell GHC linters only work on single files, which can
result in spurious errors (for example, not being able to find imports).
* Document all available Haskell linters
* Split GHC checkers into separate files
* Remove 'col' from linters where it is hardcoded to 1
When 'col' is 1, the first column will get highlighted for no reason. It
should be 0 (which is the default).
In the scalac linter there was also a check about the outcome of
`stridx`. It would set l:col to 0 if it was -1, and then it uses
`'col': l:col + 1` to convert the outcome of `stridx` to the actual
column number. This will make 'col' equals 1 when there is no match. We
can remove the check because `-1 + 1 = 0`.
* Remove outdated comments about vcol
vcol was added as a default, and the loclists that follow these comments
do not contain 'vcol' anymore
This adds support for the hdevtools haskell linter
https://github.com/hdevtools/hdevtools
The output for hdevtools is near identical to the ghc output so this
also extracts the ghc handler into the handle file and adds tests
* Add testing for previous major release of ghc
This adds support for the hdevtools haskell linter
https://github.com/hdevtools/hdevtools
The output for hdevtools is near identical to the ghc output so this
also extracts the ghc handler into the handle file and adds tests
For ghc, it seemed that the conditional
```
if l:corrected_lines[-1] =~# ': error:$'
let l:line = substitute(l:line, '\v^\s+', ' ', '')
endif
```
was never being reached. It's actually better to unconditionally
collapse whitespace anyway and so I simply removed the conditional
check.
For hlint I added more information about the error. This changes the
reported error from `Error:` to something like:
` Error: Avoid lambda. Found: \ x -> foo x Why not: foo`
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
* 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
