* 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.
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).
- 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.
* Added filename keys to gobuild and gometalinter
* Removed skipping files not in current package
* Removed `--include` for gometalinter
* Fixed the tests
The real fix was not using absolute paths anymore (so not expanding with the `:p` option). The regex was correct and should at least include the `^` character to make sure the string starts with the given path/filename and not references the path/filename in some error description.
They changed their logic to use related paths instead of absoluut paths (see [here](https://github.com/alecthomas/gometalinter/commit/a04df08be5899be3c7ad69aa379858dcb660c709#diff-04424ed7c660c10495a54e8d11be89eaR253))
This fixes the linter by also using relative paths…
* Improve performance when using gometalinter
Before this change when I opened a big project that had 6000+ warnings/errors it took ages to get the actual warnings/errors and it caused my CPU to be busy for quite some time. The call to gometalinter alone took about 24 seconds, but after that vim was struggling as well.
After this change the gometalinter call just takes 2 seconds and nothing noticable happens with the CPU and/or vim.
* Removed obsolete test
This logic is no longer done by the `ale` plugin, but by `gometalinter` itself.
Linter is disabled by default (see g:ale_go_gometalinter_enabled) as it
conflicts with a number of established ALE linters (golint, govet,
gosimple, staticcheck, etc).
Martin Tournoij