You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When I launch a project that sets some1 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"
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
-- In order to pass these options to coursier they need to be prefaced with `-J`
all_opts[i] ="-J" ..opt
end
I am not using coursier but pointing metalsBinaryPath to something like java -jar metals.jar ...
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 else2.
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 some1 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
nvim-metals/lua/metals/config.lua
Lines 369 to 372 in 4f9bf0c
I am not using coursier but pointing
metalsBinaryPath
to something likejava -jar metals.jar ...
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 else2.
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
d90ea43
Footnotes
Memory specific options are filtered out here https://github.com/scalameta/nvim-metals/blob/4f9bf0c821092f20dd34c1a4ea5b07b0500ff089/lua/metals/config.lua#L353-L360 ↩
I am not https://sourcegraph.com/search?q=context%3Aglobal+metalsBinaryPath&patternType=keyword&sm=0 ↩
The text was updated successfully, but these errors were encountered: