When I launch a project that sets some[^1] jvm options in .jvmopts nvim-metals fails to start metals language server with a following message:
[ERROR][2024-03-24 14:50:05] .../vim/lsp/rpc.lua:734 "rpc" "/nix/store/n02limb87mpqrw80pra80rwyyvzg28a3-metals-1.2.1/bin/metals" "stderr" "Unrecognized option: -J-XX:ReservedCodeCacheSize=1024m\nError: Could not create the Java Virtual Machine.\nError: A fatal exception has occurred. Program will exit.\n"
I understand why it is that way. Coursier is the most popular, recommended and also the option of nvim-metals choice when it comes to installing metals.
I wouldn't be surprised if I was the only one person passing there something else[^2].
I know that as a workaround I can override metals_config.cmd instead of metalsBinaryPath and then I will be in charge of crafting the full command, but I wanted to avoid having to duplicate some of the nvim-metals code (like reading the jvmopts etc).
~I am not sure what should be done here. I think that it would be a good idea to at least mention this in the documentation. Wdyt?~
Update: I think that the ideal way would be to apply the jvm flags transformation only if metals is installed via coursier, otherwise flags should not be adjusted. The question is what to do with memory parameters in such approach.
Describe the bug
When I launch a project that sets some[^1] jvm options in
.jvmopts
nvim-metals fails to start metals language server with a following message:This is because nvim-metals assumes that
metalsBinaryPath
will point to a metals through coursier (or some other wrapper) and prefixes certain options with-J
https://github.com/scalameta/nvim-metals/blob/4f9bf0c821092f20dd34c1a4ea5b07b0500ff089/lua/metals/config.lua#L369-L372I am not using coursier but pointing
metalsBinaryPath
to something likejava -jar metals.jar ...
[^1]: Memory specific options are filtered out here https://github.com/scalameta/nvim-metals/blob/4f9bf0c821092f20dd34c1a4ea5b07b0500ff089/lua/metals/config.lua#L353-L360
Expected behavior
I understand why it is that way. Coursier is the most popular, recommended and also the option of nvim-metals choice when it comes to installing metals.
I wouldn't be surprised if I was the only one person passing there something else[^2].
[^2]: I am not https://sourcegraph.com/search?q=context%3Aglobal+metalsBinaryPath&patternType=keyword&sm=0
I know that as a workaround I can override
metals_config.cmd
instead ofmetalsBinaryPath
and then I will be in charge of crafting the full command, but I wanted to avoid having to duplicate some of the nvim-metals code (like reading the jvmopts etc).~I am not sure what should be done here. I think that it would be a good idea to at least mention this in the documentation. Wdyt?~
Update: I think that the ideal way would be to apply the jvm flags transformation only if metals is installed via coursier, otherwise flags should not be adjusted. The question is what to do with memory parameters in such approach.
Operating system
Linux
Version of Metals
1.2.1
Commit of nvim-metals
d90ea43ded7ec651606b0a533ae9740083436e58