Closed ghostbuster91 closed 1 year ago
Thanks for the report @ghostbuster91! I just tried playing around with this and the behavior seems a little bit different from me when I do it for the first time vs when I do it a second time. For example the first time I followed you instructions and opened UserValidatorSpec.scala
directly I got no lenses when the indexing finished. Once I saved the file, I got them at the class level. After saving again I got them at the individual test level. After closing and doing this all again, I got them all right away. The third time I only got the class level ones without doing anything, and then I got the individual ones.
Some of this seems like a little bit of ordering here with when things are being indexed, test being discovered, etc. It might just be that at the moment that the lens request goes to Metals it only has the class ones, and then once it's triggered again, you'll get everything. I'll need to dig in a bit more on this or maybe someone else knows a bit more about the order that tests are discovered in Metals.
O, and one more things. What you have in your config will matter here as well. For example if you have what I have with:
api.nvim_create_autocmd({ "BufEnter", "BufWritePost" }, {
callback = vim.lsp.codelens.refresh,
buffer = bufnr,
group = lsp_group,
})
Then what you wrote sort of makes sense. Right when you open the file the BufEnter
is called and the response from Metals at that time may just not have any code lenses for you. However if would have entered that file later, then the autocmd is triggered at a later time, when Metals has that info.
Thanks for taking a look at it.
Some of this seems like a little bit of ordering here with when things are being indexed, test being discovered, etc. It might just be that at the moment that the lens request goes to Metals it only has the class ones, and then once it's triggered again, you'll get everything.
Right, that makes a lot of sense.
What you have in your config will matter here as well.
Totally, however to my surprise I discovered that I don't have anything like that. My config is sort of a mess at that point but fwiw here is the link: https://github.com/ghostbuster91/dot-files/blob/master/programs/neovim/init.lua#L272 Could it be that neovim is triggering that refresh on its own?
Totally, however to my surprise I discovered that I don't have anything like that. My config is sort of a mess at that point but fwiw here is the link: https://github.com/ghostbuster91/dot-files/blob/master/programs/neovim/init.lua#L272 Could it be that neovim is triggering that refresh on its own?
Ooooo, the plot thickens! This one confused me for a bit because no, by default nvim shouldn't do this. However, I think what is actually triggering it is this:
My guess is that Metals is sending a metals-model-refresh
which is then calling lsp.codelens.refresh()
and giving you code lenses. This could in theory be why you're experiencing somewhat unexpected or odd results with code lenses since the only time the client is every requesting them is only when the model refresh comes in. My expectation is that if you added an autocmd for the code lens, then everything might be much closer to what you'd expect. Could you give that a try? I moved this over to Metals ha, but I think this might end up being nvim-metals specific after all.
I think I've seen similar behaviour to what's described, but with Emacs, at least with test case lenses.
I've had some success calling client.refreshModel
here (workspace/codeLens/refresh
), since it doesn't otherwise appear clients are asked to refresh lenses when tests have been discovered and added to the index.
I'll test a bit further and maybe open a PR :+1:
Edit: Opened a PR here: https://github.com/scalameta/metals/pull/5124, any comments or testing welcome :slightly_smiling_face:
Thanks for looking at this @LaurenceWarne! Now that #5124 is merged if you also add the autocmd to your config @ghostbuster91 I think you should see what you'd expect. I'm going to close this for now, but after trying the latest snapshot feel free to report back if something still isn't working as expected.
Describe the bug
I noticed that if I open neovim and go straight to a scalatest file code lenses appear only on the class level until the file gets reloaded (e.g. due to some change). On the other hand, opening first a different scala file (that initializes metals) and navigating then to the scalatest file shows complete code lenses (for both the class and all the tests).
Reproduction steps:
UserValidatorSpec.scala
Part 2:
UserValidator.scala
UserValidatorSpec.scala
Full code lenses can be obtained when make a change in the test fail and saving it like in the gif:
Expected behavior
The same complete code lenses should be shown regardless of when metals was attached.
Operating system
ubuntu
Version of Metals
v0.11.11
Commit of nvim-metals
51e88e4f5eeadbd92a75cae71c5cbb75f3cb6765
Additional info
Incomplete response:
Complete response: