Open drybalka opened 1 year ago
Hey @drybalka, so there is actually a few different relevant things at play here. In theory, metals can already do this. For example this is how the VS Code extension works. nvim-metals can utilize some of the same features from metals if you set this in your settings table:
testUserInterface = "Test Explorer",
Then instead of using the code lenses it will use the test explorer which you have a couple commands to use to find your tests like :MetalsSelectTestCase
. This brings up a picker of your tests in that file. Under the hood in theory this could be used to instead find the lines that the tests are on, and then show icons in the gutter for what tests are there. I want to say that last time I looked into this I wanted to re-use another plugin that offered some of the frameworks for this, and we'd just need to provide the middle layer that makes the requests to metals and then hands the results off to the plugin. But I don't remember what plugin it is.
One other option could be that instead of just the code lens Metals could return an icon to go along with it. For example it's not on by default but you can also set
metals_config.init_options = {
icons = "unicode"
}
which will return icons in various places like the super method code lenses. This isn't done for main/test code lenses but I suppose it could.
All that to say, if someone was to work on this I'd explore integrating with the test explorer since Metals can already return all the info you need, you'd just need to capture it, display it, and provide a way for the user to execute it.
Hi @ckipp01, thanks for the reply! Setting testUserInterface
indeed hides the virtual text, which is already probably good enough for me.
I tried running the :MetalsSelectTestCase
command and I think it worked, but I did not see any output anywhere (neither for green, nor for red tests). This maybe due to my (mis-)configuration for nvim-dap though.
I am actually not sure what the best way of running tests is (or what is your vision for it). On the one hand nvim-metals provides test parsing and integrates with nvim-dap. On the other hand there is "nvim-neotest" plugin that kinda specializes on detecting/running tests and printing their results in convenient format. In the first case I get lsp support for test parsing (which is quite nice and works out of the box with multiple build tools and testing frameworks). In the second case I have to rely on tree-sitter and different heuristics (like whether build.sbt is present to determine the build tool), but I get a unified testing interface for scala and other languages.
I tried running the :MetalsSelectTestCase command and I think it worked, but I did not see any output anywhere
Did you select a test? or did it not show you any tests? By default nothing will show, you need to open the dap repl to see anything.
For your second question, it really depends on your workflow. My opinion and preference leans towards relying on nvim-dap in order to not shell out to something else. This could be made even better if we did https://github.com/scalameta/nvim-metals/issues/522 which would speed things up and still utilize some of the nvim-dap features.
Describe the feature
I like how in Intellij tests are marked with a small green triangular "run button" icon to the left. In a similar fashion if there is a super method it is marked with a small arrow icon. I personally find it much less distracting a pleasant than a quite large and identical virtual text "test case | debug test case" printed on every test. It would be cool if we could somehow modify the behavior of the virtual text generated by metals, like position (left or right), content (text or icon), or visibility (shown or hidden).
Potential ways to implement
I may be wrong but I think the relevant feature is called "code lens" and is part of metals itself, rather than this plugin in particular. My guess the solution would be to modify the code responsible for parsing this code lens and displaying the virtual text. I could even try a PR if you are interested and/or busy with other stuff.