scalameta / nvim-metals

A Metals plugin for Neovim
https://scalameta.org/metals/
Apache License 2.0
467 stars 75 forks source link

scalafmt format not available #601

Closed dhia-gharsallaoui closed 1 year ago

dhia-gharsallaoui commented 1 year ago

Describe the bug

I am trying to set up the metals.nvim plugin. I have the metals commands available, as well as LSP functions like 'go to definition,' but not the vim.lsp.buf.format().

image

this is my config:

M.config = function()
  local metals_config = require("metals").bare_config()
  metals_config.capabilities = require("cmp_nvim_lsp").default_capabilities()
  metals_config.settings = {
    superMethodLensesEnabled = true,
    showImplicitArguments = true,
    showInferredType = true,
    showImplicitConversionsAndClasses = true,
    excludedPackages = {},
  }
  metals_config.init_options.statusBarProvider = "on"
  return metals_config
end

that is imported here:

  {
    "scalameta/nvim-metals",
    ft = { "scala", "sbt" },
    dependencies = {
      "nvim-lua/plenary.nvim",
    },
    -- stylua: ignore
    keys = require("custom.configs.scala.mappings").keys(),
    init = function()
      local metals_config = require("custom.configs.scala.metals").config()
      vim.api.nvim_create_autocmd("FileType", {
        pattern = { "scala", "sbt" },
        callback = function()
          require("metals").initialize_or_attach(metals_config)
        end,
        group = vim.api.nvim_create_augroup("nvim-metals", { clear = true }),
      })
    end,
  },

I am using Lazyvim via nvchad. Any idea what I am missing? Thank you!

Expected behavior

No response

Operating system

Linux

Version of Metals

v1.0.1

Commit of nvim-metals

idk

ckipp01 commented 1 year ago

Hey @dhia-gharsallaoui, at first glance your config looks correct. However, with that being said, often there is a bunch of stuff going on behind the scenes when using things like nvchad. I'm not sure if it's trying to be smart and potentially set up Metals by itself, which could cause issues and be conflicting with your own setup. That's the first thing I'd check. Metals does support format, so the message you're seeing is definitely an indication that something funky is going on. When you do a :LspInfo do you see that there is a client attached to the buffer? Also what does :MetalsRunDoctor show you?

dhia-gharsallaoui commented 1 year ago

Hello @ckipp01:wave: Thank you for the fast response. As a newbie, from what I've read, nvchad just uses lazy.nvim and doesn't make changes to the custom plugin configuration. Here are the results of running :LspInfo

image and this is :MetalsRunDoctor:

## Metals Info
  - Metals Server version: 1.0.1
  - Metals Java: 17.0.8 from Red Hat, Inc. located at /usr/lib/jvm/java-17-openjdk-17.0.8.0.7-1.fc38.x86_64

Below are listed the build targets for this workspace. One build target corresponds to one classpath. For example, normally one sbt project maps to two build targets: main and test.

## Workspaces

### Workspace: /home/dgharsallaoui/Sources/zen-scala
 - Build definition is coming from sbt.
 - Build server currently being used is Bloop v1.5.8.

## Build Targets

### root
  - target type: Scala 2.13.8
  - goto functionality: metalsDecode:file%3A%2F%2F%2Fzen-scala%2Froot.metals-buildtarget
  - compilation: ❌
  - diagnostics: ✅ 
  - interactive: ✅ 
  - semanticdb: ✅ 
  - debugging: ✅ 
  - java: ✅ 
  - recommendation: Goto definition for Java classes will not work, please install jdk sources in java home. Searched: /usr/lib/jvm/src.zip, /usr/lib/jvm/lib/src.zip, /usr/lib/jvm/java-17-openjdk-17.0.8.0.7-1.fc38.x86_64/src.zip, /usr/lib/jvm/java-17-openjdk-17.0.8.0.7-1.fc38.x86_64/lib/src.zip

### root-test
  - target type: Scala 2.13.8
  - goto functionality: metalsDecode:file%3A%2F%2F%2Fzen-scala%2Froot-test.metals-buildtarget
  - compilation: ✅ 
  - diagnostics: ✅ 
  - interactive: ✅ 
  - semanticdb: ✅ 
  - debugging: ✅ 
  - java: ✅ 
  - recommendation: Goto definition for Java classes will not work, please install jdk sources in java home. Searched: /usr/lib/jvm/src.zip, /usr/lib/jvm/lib/src.zip, /usr/lib/jvm/java-17-openjdk-17.0.8.0.7-1.fc38.x86_64/src.zip, /usr/lib/jvm/java-17-openjdk-17.0.8.0.7-1.fc38.x86_64/lib/src.zip

### zen-scala-build
  - target type: sbt 1.8.2
  - goto functionality: metalsDecode:file%3A%2F%2F%2Fzen-scala%2Fzen-scala-build.metals-buildtarget
  - compilation: ✅ 
  - diagnostics: ⚠️ 
  - interactive: ✅ 
  - semanticdb: ✅ 
  - debugging: ❌
  - java: ✅ 
  - recommendation: Goto definition for Java classes will not work, please install jdk sources in java home. Searched: /usr/lib/jvm/src.zip, /usr/lib/jvm/lib/src.zip, /usr/lib/jvm/java-17-openjdk-17.0.8.0.7-1.fc38.x86_64/src.zip, /usr/lib/jvm/java-17-openjdk-17.0.8.0.7-1.fc38.x86_64/lib/src.zip

I've also noticed that 'go to definition' doesn't work for all functions. It's possible that I might be missing something in how to set up Metals in a project.

This is metals.log

2023.09.01 10:14:26 INFO  Attempting to connect to the build server...
2023.09.01 10:14:26 INFO  Bloop uses /usr/lib/jvm/java-17-openjdk-17.0.8.0.7-1.fc38.x86_64 defined at /home/dgharsallaoui/.bloop/bloop.json
2023.09.01 10:14:26 INFO  skipping build import with status 'Installed'
2023.09.01 10:14:26 INFO  tracing is disabled for protocol BSP, to enable tracing of incoming and outgoing JSON messages create an empty file at /home/dgharsallaoui/Sources/zen-scala/.metals/bsp.trace.json or /home/dgharsallaoui/.cache/metals/bsp.trace.json
2023.09.01 10:14:26 INFO  Attempting to connect to the build server...
2023.09.01 10:14:26 INFO  Bloop uses /usr/lib/jvm/java-17-openjdk-17.0.8.0.7-1.fc38.x86_64 defined at /home/dgharsallaoui/.bloop/bloop.json
2023.09.01 10:14:26 INFO  tracing is disabled for protocol BSP, to enable tracing of incoming and outgoing JSON messages create an empty file at /home/dgharsallaoui/Sources/zen-scala/project/.metals/bsp.trace.json or /home/dgharsallaoui/.cache/metals/bsp.trace.json
2023.09.01 10:14:26 INFO  time: Connected to build server in 0.35s
2023.09.01 10:14:26 INFO  Connected to Build server: Bloop v1.5.8
2023.09.01 10:14:26 INFO  time: Imported build in 0.14s
2023.09.01 10:14:32 WARN  Could not find java sources in /usr/lib/jvm/src.zip, /usr/lib/jvm/lib/src.zip, /usr/lib/jvm/java-17-openjdk-17.0.8.0.7-1.fc38.x86_64/src.zip, /usr/lib/jvm/java-17-openjdk-17.0.8.0.7-1.fc38.x86_64/lib/src.zip. Java symbols will not be available.
2023.09.01 10:14:33 WARN  Could not find java sources in /usr/lib/jvm/src.zip, /usr/lib/jvm/lib/src.zip, /usr/lib/jvm/java-17-openjdk-17.0.8.0.7-1.fc38.x86_64/src.zip, /usr/lib/jvm/java-17-openjdk-17.0.8.0.7-1.fc38.x86_64/lib/src.zip. Java symbols will not be available.
2023.09.01 10:14:33 WARN  Could not find java sources in /usr/lib/jvm/src.zip, /usr/lib/jvm/lib/src.zip, /usr/lib/jvm/java-17-openjdk-17.0.8.0.7-1.fc38.x86_64/src.zip, /usr/lib/jvm/java-17-openjdk-17.0.8.0.7-1.fc38.x86_64/lib/src.zip. Java symbols will not be available.
2023.09.01 10:14:33 INFO  time: indexed workspace in 6.56s
2023.09.01 10:14:33 INFO  compiling root (155 scala sources)
2023.09.01 10:14:36 INFO  time: compiled root in 2.76s
2023.09.01 10:14:36 INFO  compiling root (155 scala sources)
2023.09.01 10:14:38 INFO  time: compiled root in 1.92s
2023.09.01 10:14:49 WARN  Using indexes to guess the definition of get

Thank you !

ckipp01 commented 1 year ago

Here are the results of running :LspInfo

That all looks fine 🤔 When you trigger a format, what mapping are you using? Also I'm assuming the answer is yes, but you're trigger it from within a Scala buffer right?

The only other thing I can think of to debug this would be to go inside of the .metals/ dir that you should have at the root of your workspace and create a .metals/lsp.trace.json. Then restart Metals. This will pipe all of the LSP communication from Neovim and Metals into here. When you trigger the format you should see the request sent to the server. Do you see it? If not, then we can isolate that the issue is client side.

I've also noticed that 'go to definition' doesn't work for all functions. It's possible that I might be missing something in how to set up Metals in a project.

It sort of depends on the exact situation, but looking at the output of your doctor it looks like compilation is failing, which can impact the results of the goto definition.

dhia-gharsallaoui commented 1 year ago

I am using this:

    ["<leader>fm"] = {
      function()
        vim.lsp.buf.format { async = true }
      end,
      "LSP formatting",
    }

I also tried running :lua vim.lsp.buf.format() . In both cases, it was from Scala buffer. After adding .metals/lsp.trace.json there is no trace of format request.

ckipp01 commented 1 year ago

I am using this:

    ["<leader>fm"] = {
      function()
        vim.lsp.buf.format { async = true }
      end,
      "LSP formatting",
    }

I also tried running :lua vim.lsp.buf.format() . In both cases, it was from Scala buffer. After adding .metals/lsp.trace.json there is no trace of format request.

That's very odd. My guess is that the format request then simply isn't being sent to the correct server. Does nvchad override handlers or anything like that? Or would they have any impact on this?

dhia-gharsallaoui commented 1 year ago

After fixing the compile, the 'goto definition' feature works like a charm. I'm a new user of nvchad and don't know exactly what it does in detail. In their code, I can see there is an LSPconfig, which I didn't use; I just used metals.nvim as in lazy.nvim

dhia-gharsallaoui commented 1 year ago

Resolved by adding my custom on_attach instead of using the nvchad default one.

ckipp01 commented 1 year ago

Resolved by adding my custom on_attach instead of using the nvchad default one.

I'm actually a bit confused by this. Why does NvChad override this and set formatting to false in the default capabilities? Neovim by default has this capability, so I'm not sure why this is set to false. Either way, I'm glad you got it working 👍🏼