The standard linter --fix fails if the file being input is not relative
to the project root (https://github.com/standard/standard/issues/1384).
This MR attempts to fix this by changing the command so the input file
is relative to the project root and the output is to a temporary file.
Preliminary tests with toy javascript projects seem to indicate this
works fine.
If checkstyle is configured with custom options that contain "-c" then
the checkstyle config file option is ignored. This PR modifies the
regular expression when creating the checkstyle command to avoid this.
ESLint errors are contained in an array that can contain different
stuff other than JSON error messages. This patch iterates over the whole
array ignoring any non-json data.
* Use sign-group only on supported vim versions.
The sign-group feature is only available in nvim 0.4.0 and vim 8.1.614.
* Add priority to ALE signs.
This allows users to set a priority to ALE signs to take precedence over
other plugin signs.
This MR adds a new configuration variable `g:ale_java_javalsp_config`
that allows to configure external dependencies and class paths to the
language server.
The variable accepts a dictionary similar to the one supported by the
[vscode/settings.json](https://github.com/georgewfraser/java-language-server#settings)
file.
Deprecates: #2561
Checkstyle xml configuration is mandatory and not providing one causes
the tool to fail with the following error:
Must specify a config XML file.
Checkstyle itself contains a default configuration as part of its
assests named `/google_checks.xml`. Invoking checkstyle with this config
works even if such file does not exists in the file system:
checkstyle -c /google_checks.xml
This should be the default invocation to allow ALE to use checkstyle
with zero configuration.
Also when a user sets `g:ale_java_checkstyle_config` option, ALE should
use it to invoke checkstyle even such file does not exists in the
filesystem. This is because checkstyle is able to use configuration files
within JAR files defined in the CLASSPATH. The default `/google_checks.xml`
is an example of such configuration available within a JAR resource.
The default binary "launcher" is too generic and can get mixed with
other tools. To use this linter user must explicitly set the absolute
path of the launcher path.
The command used to invoke the language server is missing some options
to include additional java modules. Without these modules the server
was not working properly.
The correct command can be found in a `launcher` script on the same
directory the `java` executable for the language server is found.
This commit changes the docs to prefer the launcher script over the java
executable. For backward compatibility it also fixes the command
invocation in case the java executable is configured.
The checkstyle handler is capable of parsing the new and old output
formats. Unfortunately there are some particular output messages that
matched both the new and old regular expressions:
[WARN] whatever:11:7: WhitespaceAround: ''if'' is not followed by whitespace. [WhitespaceAround]
This caused ALE to report extra errors since the message was being
matched twice, once as a warning and another (incorrect) old formatted
error.
This MR fixes this by stopping any parsing using the old format regexp
is any errors of the new format are correcly parsed. There is no reason
to expect checkstyle to output both styles in the same report.
To find the buffer corresponding to URIs reported by LSP the
HandleLSPDiagnostics() method uses the built-in bufnr() function. From
the documentation we learn that the first parameter of bufnr() is
an expression, not a path.
EclipseLSP will report project wide errors (e.g. gradle errors) that are
not related to any actual source file with an URI that corresponds to the
project root folder, e.g:
file:///home/username/Projects/gradle-simple
This URI will match any open buffer of files within the project root
hiearchy, thus project-wide errors appear as part of every file within
the project, e.g:
file:///home/username/Projects/gradle-simple/src/main/java/Hello.java
To fix this, this MR adds '^' to the beginning and '$' at the end of the
URI path to force an exact match. This is how is recommended in vim
help (see :h bufname).
We were setting the -data parameter to the project root but this caused
the language server to fail initialization and synch of gradle
dependencies. As consequence ALE failed to work fully on gradle
projects.
This fix sets the workspace to the parent folder of the project root.
Normally this corresponds to the correct Eclipse workspace path.
When this is not the case, this fix also allows users to explicitly set
the absolute path to the workspace via configuration variable.
- Set default value to $HOME/eclipse.jdt.ls
- Make JAR search regexp more specific.
- Allow to set the VSCode extensions folder as ale_java_eclipselsp_path.
The command used to invoke the LSP process was being escaped wrong.
Also added a new option to set a different java executable and fixed the
documentation.
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